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