优先用 <strong>，次选用 font-weight: bold，慎用 <b>；因<strong>具语义重要性，提升可访问性与SEO，而<b>仅表视觉加粗、无含义。
直接说结论：优先用 <strong>，次选用 font-weight: bold，慎用 <b> —— 不是所有加粗都该用 <b>，语义错位会导致可访问性与 SEO 问题。
什么时候该用 <strong> 而不是 <b>
浏览器渲染效果一样，但语义完全不同：<strong> 告诉屏幕阅读器“这段内容重要”，搜索引擎也会加权；<b> 只是“看起来粗一点”，没含义。比如产品页中价格、警告文案、关键操作按钮文字，必须用 <strong>。
常见错误现象：
- 用
<b>包裹“¥99.00”，结果读屏软件念成“b 九十九点零零 / b 结束”，而非“价格九十九点零零” - SEO 工具提示“重要内容未使用语义化标签”，实际就是该用
<strong>的地方用了<b>
使用场景明确：强调信息重要性、需被辅助技术识别、内容本身有逻辑权重。
立即学习“前端免费学习笔记（深入）”；
font-weight 的数值值 vs 关键字怎么选
font-weight 支持关键字（如 normal、bold）和数字（100–900），但不是所有字体都支持全部数值。多数 Web 字体只提供 400（normal）和 700（bold）两档。
实操建议：
- 通用场景直接写
font-weight: bold或font-weight: 700，兼容性最好 - 想微调粗细（比如比
bold稍细一点），可用600，但要确认字体文件真包含这一档，否则会回退到最近可用值 - 避免写
font-weight: bolder，它依赖父元素值计算，行为不可控，尤其嵌套深时容易失控 - 内联样式写法：
<p style="font-weight: bold">加粗段落</p>；类写法：.highlight { font-weight: 700; }
为什么 <b> 没被废弃，但不该乱用
<b> 在 HTML5 中已不再是“废弃标签”，而是被重新定义为“无语义的粗体呈现”，适用场景非常窄：比如词典条目中的词条名、小说中角色名字首次出现、或纯装饰性加粗（且无法用 CSS 实现时）。
容易踩的坑：
- 把
<b>当作“CSS 替代方案”来规避样式表加载失败——现代项目基本不用这种降级思路 - 在 React/Vue 组件中硬编码
<b>，结果团队统一要求语义化，批量替换成本高 - 误以为
<b>比<strong>“更轻量”，其实 DOM 节点开销几乎一致，差别在语义解释层
简单判断：如果删掉加粗，用户会不会漏掉关键信息？会 → 用 <strong>；不会 → 才考虑 <b> 或 CSS。
真正复杂的点不在语法，而在语义边界的判断——比如“限时优惠”四个字，是促销文案的一部分，还是独立的重要提示？前者可能只需 CSS 加粗，后者必须用 <strong> 并配 aria-live 提示。别只盯着怎么“变粗”，先想清楚“为什么必须粗”。
