HTML中b和i标签作用 b标签纯视觉加粗解析

应使用 <strong> 而非 <b> 实现语义化强调，因 <strong> 传达逻辑重要性，支持可访问性、SEO 和辅助技术，而 <b> 仅保留视觉加粗且语义缺失。

为什么不是“加粗就完事”的快捷键

很多人把 <b> 当成排版快捷键，点一下富文本编辑器的「B」按钮就输出 <b>，结果整页都是视觉加粗但语义全无。它确实会让文字变粗，但浏览器、屏幕阅读器、搜索引擎看到的只是一个「没意义的粗体」——<b> 不会改变语音语调，不提升 SEO 权重，也不参与可访问性树的结构构建。

常见错误现象：<b> 被塞进表单标签（如 <label><b>用户名</b></label>）、错误提示（<p><b>不能为空</b></p>）、甚至整段说明文字。这些地方真正需要的是语义强调，而不是纯样式。

• <b> 的合法用途极窄：产品名首次出现（<b>iPhone 15</b>）、技术术语（<b>JSON</b>）、字典条目中的词头
• 它不触发任何辅助技术行为，NVDA 或 VoiceOver 读到 <b> 内容时，音调、节奏、停顿完全不变
• CSS 失效时，<b> 还能保底显示为粗体；但若你本意是强调，这层“保底”毫无信息价值

什么时候该用而不是

用 <strong> 的唯一判断标准是：这段文字是否在逻辑或信息层级上必须被用户（尤其是依赖辅助技术的用户）识别为「重要内容」？不是“看起来重要”，而是“确实重要”。

典型使用场景：

立即学习“前端免费学习笔记（深入）”；

• 表单校验失败时的关键字段名：<p>请确认 <strong>邮箱地址</strong> 格式正确</p>（只包字段，不包整句）
• 高风险操作警告：<p>点击 <strong>删除</strong> 将永久移除所有数据</p>
• 法律条款中的责任限定词：<p>本公司 <strong>不承担间接损失</strong> 责任</p>

嵌套 <strong> 没有意义——<strong><strong>双重强调</strong></strong> 不会让屏幕阅读器读两遍，也不会让字体更粗，反而可能干扰解析。

font-weight: bold 和 标签根本不是一回事

CSS 的 font-weight 是纯样式控制，而 <b> 是一个 HTML 元素。两者目标不同，不能互相替代，也不该混用。

容易踩的坑：

• 全局重置了 * { font-weight: 400; }，结果所有 <strong> 看起来没加粗，于是开发者手动给每个 <strong> 加 style="font-weight: bold"——这属于用样式补语义缺陷
• 写 b { font-weight: 700; } 合理，但写 strong { font-weight: normal; } 虽然技术可行，却等于主动放弃语义对应的视觉反馈，违背设计初衷
• 用 <b> 包裹变量名（如 <b>user</b>）不如用 <strong>user</strong>，因变量名在代码上下文中具有明确角色语义

CMS 或编辑器默认输出是个隐患

多数富文本编辑器（包括 WordPress 默认编辑器、TinyMCE、Quill）点「加粗」按钮，后台默认生成 <b>。这不是 bug，是历史兼容性妥协。但如果你的页面需通过 WCAG 2.1 AA 认证，或要适配企业级 SEO 规范，这就成了真实风险点。

实操建议：

• 检查 CMS 富文本配置项，看是否支持将「加粗」映射为 <strong>（WordPress 可通过 tiny_mce_before_init 钩子修改）
• 服务端渲染前做一次正则替换：<b>(.+?)</b> → <strong>$1</strong>，但注意避开已有的 <code> 或 <pre> 块
• 前端 JS 注入方案风险高，不推荐；SSR 或构建时处理更稳妥

真正容易被忽略的是：加粗只是信息分层的第一步。一段文字是否加粗，和它是否配色、是否有图标、是否在焦点顺序中可抵达、是否在暗色模式下仍清晰——这些从来不是单靠选对 <b> 或 <strong> 就能解决的。