应使用 而非 实现语义化强调，因 传达逻辑重要性，支持可访问性、SEO 和辅助技术，而 仅保留视觉加粗且语义缺失。
为什么不是“加粗就完事”的快捷键
很多人把 <b></b> 当成排版快捷键，点一下富文本编辑器的「B」按钮就输出 <b></b>，结果整页都是视觉加粗但语义全无。它确实会让文字变粗，但浏览器、屏幕阅读器、搜索引擎看到的只是一个「没意义的粗体」——<b></b> 不会改变语音语调，不提升 SEO 权重，也不参与可访问性树的结构构建。
常见错误现象：<b></b> 被塞进表单标签（如 <label><b>用户名</b></label>）、错误提示（<p><b>不能为空</b></p>）、甚至整段说明文字。这些地方真正需要的是语义强调，而不是纯样式。
-
<b></b>的合法用途极窄：产品名首次出现（<b>iPhone 15</b>）、技术术语（<b>JSON</b>）、字典条目中的词头 - 它不触发任何辅助技术行为，
NVDA或VoiceOver读到<b></b>内容时，音调、节奏、停顿完全不变 - CSS 失效时，
<b></b>还能保底显示为粗体；但若你本意是强调，这层“保底”毫无信息价值
什么时候该用而不是
用 <strong></strong> 的唯一判断标准是：这段文字是否在逻辑或信息层级上必须被用户（尤其是依赖辅助技术的用户）识别为「重要内容」？不是“看起来重要”，而是“确实重要”。
典型使用场景：
立即学习“前端免费学习笔记（深入）”；
- 表单校验失败时的关键字段名：
<p>请确认 <strong>邮箱地址</strong> 格式正确</p>（只包字段，不包整句） - 高风险操作警告：
<p>点击 <strong>删除</strong> 将永久移除所有数据</p><div class="aritcle_card flexRow"> <div class="artcardd flexRow"> <a class="aritcle_card_img" href="/xiazai/skill10828" title="财经HTML高端海报生成"><img src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="财经HTML高端海报生成" ></a> <div class="aritcle_card_info flexColumn"> <a href="/xiazai/skill10828" title="财经HTML高端海报生成">财经HTML高端海报生成</a> <p>复杂得财经如何变成清晰，适合手机看的海报？如何加上你的IP</p> </div> <a href="/xiazai/skill10828" title="财经HTML高端海报生成" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div> - 法律条款中的责任限定词：
<p>本公司 <strong>不承担间接损失</strong> 责任</p>
嵌套 <strong></strong> 没有意义——<strong><strong>双重强调</strong></strong> 不会让屏幕阅读器读两遍，也不会让字体更粗，反而可能干扰解析。
font-weight: bold 和 标签根本不是一回事
CSS 的 font-weight 是纯样式控制，而 <b></b> 是一个 HTML 元素。两者目标不同，不能互相替代，也不该混用。
容易踩的坑：
- 全局重置了
* { font-weight: 400; }，结果所有<strong></strong>看起来没加粗，于是开发者手动给每个<strong></strong>加style="font-weight: bold"——这属于用样式补语义缺陷 - 写
b { font-weight: 700; }合理，但写strong { font-weight: normal; }虽然技术可行，却等于主动放弃语义对应的视觉反馈，违背设计初衷 - 用
<b></b>包裹变量名（如<b>user</b>）不如用<strong>user</strong>，因变量名在代码上下文中具有明确角色语义
CMS 或编辑器默认输出是个隐患
多数富文本编辑器（包括 WordPress 默认编辑器、TinyMCE、Quill）点「加粗」按钮，后台默认生成 <b></b>。这不是 bug，是历史兼容性妥协。但如果你的页面需通过 WCAG 2.1 AA 认证，或要适配企业级 SEO 规范，这就成了真实风险点。
实操建议：
- 检查 CMS 富文本配置项，看是否支持将「加粗」映射为
<strong></strong>（WordPress 可通过tiny_mce_before_init钩子修改） - 服务端渲染前做一次正则替换：
<b>(.+?)</b>→<strong>$1</strong>，但注意避开已有的<code>或<pre class="brush:php;toolbar:false;"></pre>块 - 前端 JS 注入方案风险高，不推荐；SSR 或构建时处理更稳妥
真正容易被忽略的是：加粗只是信息分层的第一步。一段文字是否加粗，和它是否配色、是否有图标、是否在焦点顺序中可抵达、是否在暗色模式下仍清晰——这些从来不是单靠选对 <b></b> 或 <strong></strong> 就能解决的。
