优先使用，因其具语义重要性；仅用于无语义的视觉加粗，如产品名、术语等，误用会损害可访问性与SEO。
直接说结论：<b></b> 标签能加粗，但仅限纯视觉需求；误用它替代 <strong></strong> 会导致可访问性断裂、SEO 权重丢失，且现代项目中几乎无不可替代场景。
什么时候该用 <b></b> 而不是 <strong></strong>
HTML5 明确定义了 <b></b> 的用途：不传达重要性，只把读者注意力“拉到某段文字上”。它不是 <strong></strong> 的简化版，而是语义完全不同的标签。
- 适用场景举例：
<b>Python</b>（技术文档中首次出现的术语）、<b>用户协议</b>（条款标题中的关键词）、词典页面里的词条名 - 不适用场景：价格（
<b>¥299</b>）、错误提示（<b>密码错误</b>）、操作按钮文字（<b>确认提交</b>）——这些必须用<strong></strong> - 关键判断标准：删掉加粗后，用户是否会误解或忽略关键信息？如果是，就不能用
<b></b>
<b></b> 和 CSS font-weight 的实际差异在哪
表面上三者都能让字变粗，但渲染机制和维护成本不同。
-
<b></b>是 HTML 元素，自带默认样式（font-weight: bold），但无法控制粗细梯度；若设计要求“比 bold 稍细一点”，它做不到 -
font-weight: 700或font-weight: bold是样式层控制，可统一收口在 CSS 类里，也支持响应式覆盖（比如小屏下取消加粗） - 混用风险：写
<b style="font-weight: 600">文本</b>容易引发样式优先级混乱，尤其在组件化框架中 - 兼容性提醒：所有现代浏览器对
<b></b>渲染一致，但部分老旧读屏软件可能完全忽略它，而<strong></strong>至少有基础语义识别
常见错误现象与调试线索
很多加粗失效或行为异常，并非语法写错，而是语义错配引发的连锁反应。
- 屏幕阅读器念出“b 开始”“b 结束”，而不是内容本身 → 检查是否误用
<b></b>包裹关键信息，应换<strong></strong> - SEO 工具报“重要内容未使用语义化标签” → 搜索页面中所有
<b></b>，逐个判断是否本该是<strong></strong> - 加粗在某些字体下不明显（如思源黑体 Light）→
<b></b>依赖字体是否提供 bold 字重，此时font-weight: 700也一样受限，需换字体或改用图像/伪元素方案 - React/Vue 组件中大量硬编码
<b></b>→ 后期团队推行语义化规范时，替换成本高，建议从组件 API 层就约束为emphasis="strong"或类似抽象
真正难的不是怎么加粗，而是每次敲下 <b></b> 前，得想清楚：这段文字，到底值不值得被听见、被索引、被理解为重要——否则，它只是看起来粗了一点而已。
