必须用 strong 而不是 b 当文字承载「不可省略的重要性」时，如表单错误提示、关键金额、法律风险文案等，因 strong 提供语义权重、读屏器强调、SEO 识别及工具链解析能力，而 b 仅为纯视觉加粗且无语义。
什么时候必须用 strong 而不是 b
当文字承载「不可省略的重要性」时，strong 是唯一合理选择。比如表单校验失败提示里的 邮箱格式错误、支付页的 ¥12,800.00、权限弹窗中的 删除后不可恢复——这些内容一旦被屏幕阅读器忽略或搜索引擎降权，会直接导致可访问性失败或关键信息丢失。
常见错误现象：b 被用于错误提示，NVDA/VoiceOver 完全不加重语气，用户听不出这是风险；CMS 富文本编辑器默认输出 b，上线后无障碍测试卡在 WCAG 1.3.1（信息与关系）项。
-
strong会触发原生role="strong"（部分浏览器），读屏器自动提升音调或插入停顿 - SEO 工具能识别
strong包裹的关键词为页面高权重信号，但整段滥用会触发关键词堆砌判定 - 自动化文档解析（如 API 提取工具）依赖
strong标记必填字段，b对这类工具完全透明
b 的合法使用场景其实非常有限
b 不是废弃标签，但它在 HTML5 中已被明确定义为“纯视觉加粗且无语义意图”的实体标签。它的存在空间极小，且多数情况下 CSS 更合适。
真正能接受 b 的场景包括：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 品牌名或产品型号首次出现（如段落中第一次提
React），但更推荐用class="font-weight-600"控制 - 代码块内突出某个无语义的命令词（如
<pre>git <b>commit</b> -m "fix"</pre>），此时用strong反而暗示“这个命令很重要”，造成语义误导 - 传统排版需求（如古籍中与
i配合的章节标题），但现代项目几乎不涉及
注意：b 不该出现在表单提示、错误文案、法律条款、金额数字等任何含逻辑权重的位置——这不是“写法偏好”，而是语义污染。
CSS 覆盖 strong 时容易踩的坑
很多团队重置了全局 font-weight: 400，结果发现 strong 看起来没加粗，误以为标签失效，转而乱加 !important 或换回 b。
- 浏览器默认给
strong设font-weight: bold，但该值依赖 UA 样式；一旦全局重置，它就失效——这不是 bug，是 CSS 层叠规则生效 - 稳妥做法是显式声明
strong { font-weight: 600; }，避免依赖 UA 默认值 - 别用
strong { font-weight: inherit; }——等于主动放弃语义对应的视觉反馈 - 若项目用 Design Token，确保
strong映射到font-weight-emphasistoken，而非随意指派为 heading 级字重
框架中动态渲染 strong 的边界问题
React/Vue 模板里写 <strong>{msg}</strong> 很自然，但 msg 是空字符串、null 或 undefined 时，SSR 下可能生成空标签甚至报错，破坏 DOM 结构。
- React 建议写成
{msg && <strong>{msg}</strong>}或三元判断兜底 - 服务端渲染时，空
<strong></strong>会导致父元素样式计算异常（尤其依赖:has(> strong)的 CSS） - 嵌套
strong（如<strong><strong>双重强调</strong></strong>）虽合法，但部分读屏工具会重复播报 “strong”，反而干扰理解
最常被忽略的一点：加粗只是视觉线索之一。真正重要的内容，往往还需要配合颜色、图标、间距甚至 ARIA 属性来强化传达——单靠标签本身远远不够。
