应优先用而非或css加粗：当文本需向用户和机器传达内容重要性（如安全警告、必填字段、法律主体）时，提供语义信号；仅纯视觉加粗，css只控制外观。
什么时候该用 <strong></strong>，而不是 <b></b> 或 CSS 加粗？
当一段文本需要向人（尤其是屏幕阅读器用户）和机器（如搜索引擎）传达「内容重要性」时，才用 <strong></strong>。它不是“让字变粗”的快捷方式，而是语义信号：这部分信息漏掉会影响理解或引发风险。
常见误用场景包括：标题里套 <strong></strong>、导航菜单项加粗、纯视觉装饰性加粗文字。这些应该用 CSS 的 font-weight 控制样式，而非 <strong></strong>。
-
<strong></strong>适合：安全警告（“<strong>禁止断电操作</strong>”）、必填字段说明（“<strong>姓名</strong>为必填项”）、法律条款中的责任主体
<b> 仅用于无语义的文体突出，比如产品名在评测中（“这款<code><b>iPhone 16</b>……”），不表示重要性- CSS 加粗（
font-weight: bold）只负责外观，对辅助技术、SEO、DOM 结构无影响
<strong></strong> 嵌套与层级是否允许？
允许嵌套，但必须有明确语义理由。浏览器和屏幕阅读器会逐层加重语气，过度嵌套反而削弱重点，甚至触发可访问性检测工具告警。
例如：<strong>请立即<strong>关闭电源</strong>并撤离</strong> —— 外层强调动作紧迫性，内层强调关键操作，逻辑成立；但 <strong><strong><strong>错误</strong></strong></strong> 这类堆砌毫无意义。
- 嵌套深度建议 ≤ 2 层，且每层都应能用自然语言解释其强调意图
- 不要用嵌套替代 CSS 样式控制（比如想让某段更粗，直接改 CSS，别靠多套
<strong></strong>） - 若需差异化强调（如“严重” vs “警告”），优先用 class 区分，而非靠嵌套层级
与 <em></em> 混用是否合理？
合理，但分工必须清晰：<em></em> 改变句子语义重心（类似说话时重读某个词），<strong></strong> 表达内容重要性（类似拍桌子说“这事必须办！”）。两者语义不同，不可互换。
典型正确用法：<p>你<em>真的</em>确定要删除<strong>所有备份</strong>？</p> —— “真的”是语气强调（怀疑对方是否认真），而“所有备份”是后果强调（删错无法恢复）。
- 避免把
<em></em>当斜体样式标签、<strong></strong>当加粗样式标签，否则语义丢失 - 同一短语不用同时包裹
<em></em>和<strong></strong>（如<em><strong>危险</strong></em>），这会让辅助技术困惑 - 如果只是想让某词既斜又粗，用 CSS 控制，不要靠标签组合
实际项目中容易被忽略的兼容性与质量点
现代浏览器对 <strong></strong> 渲染一致，但问题常出在工具链和协作规范上：Lighthouse 可能因滥用 <strong></strong> 降低可访问性评分；某些 CMS 导出 HTML 会把富文本加粗一键转成 <strong></strong>，不管语义；团队成员若缺乏语义意识，会把它当成“加粗按钮”来用。
- CI 流程中可加入 HTMLHint 规则
semantic-elements，拦截无意义的<strong></strong>使用 - 设计系统文档里应明确标注：哪些文案场景必须用
<strong></strong>，哪些只能用 class - 审查 PR 时，重点看
<strong></strong>是否出现在用户可能跳过的区域（如 footer、aside），这类位置即使加粗也难被感知，语义价值极低
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
