应使用标签仅作纯视觉加粗且无语义需求的场景，如产品名、关键词等；它不传达重要性，与语义不同，且不可包裹块级元素，CSS控制更可控但需注意字体兼容性。
HTML中<b>标签的语义定位很明确
<b>不是“强调”也不是“重要”，它只做一件事：让文字在视觉上更醒目，且不向屏幕阅读器、搜索引擎或辅助技术传递任何额外权重。比如产品名、关键词、UI控件名这类需要突出但本身不构成内容重点的文本，才是它的合理使用场景。
常见错误是把它当<strong>用——比如写<p>请务必<b>立即付款</b></p>。这会让屏幕阅读器读出来毫无语气变化，用户感知不到紧迫性；SEO 侧也收不到“此处为关键动作”的信号。
嵌套位置必须符合HTML流式结构规则
<b>是行内元素，不能直接放在<div>、<p>之外，也不能包裹块级元素（如<h2>、<ul>）。否则浏览器会自动修复 DOM，导致渲染不可控，甚至影响 CSS 选择器匹配。
- ✅ 正确：
<p>支持<b>HTML5</b>和<b>CSS3</b>标准</p> - ❌ 错误：
<b><div>整块加粗</div></b>或<div><b><p>段落里再包段落</p></b></div>
<b>与font-weight的样式控制差异直接影响可维护性
浏览器默认把<b>渲染为font-weight: bold，但这个映射不是硬编码的。一旦你写了style="font-weight: normal"或全局 CSS 覆盖了b { font-weight: 600 }，<b>就可能失效或变成非预期粗细。
立即学习“前端免费学习笔记（深入）”；
而纯 CSS 方式（如给类加font-weight: bolder）完全可控，还能配合变量、媒体查询动态调整。但要注意：font-weight数值不是线性的，bold通常对应700，但不同字体族实际渲染效果可能差异很大。
容易被忽略的一点：某些中文字体（如“思源黑体”）没有真正的900字重，强行设font-weight: 900会被降级到700，此时<b>反而更稳定——因为它依赖的是浏览器对标签的默认映射逻辑，而非字体文件是否支持。
现代项目中<b>的真实存在价值在于语义洁癖与历史兼容的平衡点
如果你在维护一个老系统，或者团队明确要求“所有纯视觉加粗统一用<b>”，那它就是合理的工具。但新项目里，优先考虑：<strong>用于真正需传达重要性的内容；CSS 类用于样式化加粗；仅当需要快速标记关键词又不想引入新类名时，才用<b>。
最常被漏掉的细节是可访问性测试：JAWS/NVDA 不会为<b>添加语音语调变化，也不会提升其在 ARIA 树中的层级。如果设计稿里某处加粗是为了引导用户操作（比如按钮文字），那就该用<strong> + 合适的 role，而不是靠视觉侥幸。
