应优先用 <strong> 表示语义强调，如错误提示关键词；仅视觉加粗用 CSS（font-weight:700）；禁用 <b> 伪装语义或整段包裹 <strong>。
HTML 里写粗体，别用 <b> 当默认答案，它只是“视觉加粗”，不带语义；真要强调内容重要性，该用 <strong>。
什么时候该用 <strong> 而不是 <b>
<strong> 表示内容有强重要性，浏览器和读屏软件会据此调整行为（比如语音语调加重）；<b> 只是“想让它看起来粗一点”，没有语义权重。
常见错误现象：<b> 被大量用于标题、标签名、UI 文字——这些其实不需要语义强调，但也不该滥用 <b> 来“假装有重点”。
- 用
<strong>：错误提示中的关键词（如“<strong>密码长度不足</strong>”） - 用
<b>：纯样式需求，比如菜单项里把“New”标粗（无语义，仅视觉区分） - 都不该用：整段文字套
<strong>来“加粗排版”，这是 CSS 的活儿
<strong> 的嵌套和可访问性影响
可以嵌套，但嵌套两层以上时，部分读屏工具会重复播报“strong”，造成干扰；视觉上也不会更粗——浏览器对多重 <strong> 不叠加粗细。
立即学习“前端免费学习笔记（深入）”；
使用场景中容易被忽略的一点：<strong> 在表单错误消息里如果包裹整个句子，不如只包关键字段名，例如：
<p>请检查 <strong>邮箱地址</strong> 和 <strong>验证码</strong> 是否正确</p>
而不是：
<p><strong>请检查邮箱地址和验证码是否正确</strong></p>
后者让辅助技术难以定位具体出错项。
CSS 替代方案：什么时候干脆别用标签
如果你只是想让某段文字变粗，且不涉及语义或可访问性需求，直接用 CSS 更干净：
-
font-weight: bold或font-weight: 700（推荐数值，兼容性更稳） - 避免用
<b>+ CSS 覆盖样式，既冗余又增加 DOM 复杂度 - 组件库中常见反模式：封装一个
<BoldText>组件却内部用<b>，结果语义全丢
性能影响极小，但维护成本上升——多一层标签，就多一个可能被误读的语义节点。
真正麻烦的不是选 <b> 还是 <strong>，而是根本没想过这段粗体文字在键盘导航时怎么读、在暗色模式下是否还清晰、被翻译工具提取时会不会连带把“strong”语义一起错译。这些细节，改一行 CSS 解决不了。
