应优先用<strong>而非<b>，因其承载语义重要性而非仅视觉加粗；<strong>适用于必填项、错误警告等质变场景，<b>仅用于类型标识如代码、学名；二者朗读语调与语义角色不同，不可混用或替代CSS样式。
什么时候该用 而不是
语义边界最常崩坏的地方，就是把 <strong></strong> 当成“加粗开关”来用。它真正该出现的场景，是内容重要性发生质变时——比如表单必填项、错误警告、法律条款关键句。
常见错误现象：<strong></strong> 被套在按钮文字里（<button><strong>提交</strong></button>），或用于纯视觉分隔（<strong>—— 分割线 ——</strong>）。这些都不该用 <strong></strong>，因为没提升内容重要性，只是换了种粗细。
- 用
<strong></strong>：「<strong>密码必须包含大小写字母和数字</strong>」——这是用户必须遵守的规则 - 用
<b></b>：「<b>注意：</b>当前为测试环境」——只是视觉提示，无强制语义</li> <li>禁用场景：不要用 <code><strong>
包裹图标文字（如<strong>ⓘ</strong>）、纯装饰性符号、或仅为了匹配 UI 设计稿的字体粗细
和 的语气差异在哪
<em></em> 是有明确朗读语义的：屏幕阅读器会改变语调，像人说话时重读某个词；<i></i> 则只是标记“这段文本在语境中身份不同”，不触发语气变化。
使用场景上，<em></em> 适合强调句子中的逻辑重心（比如否定、转折、对比），而 <i></i> 更偏向类型标识。
立即学习“前端免费学习笔记（深入）”；
-
<em></em>：「你不能跳过验证步骤」——“不能”是语气焦点 -
<i></i>：「函数签名：<i>fetchData</i>(url: string)」——这是代码术语，不是强调 -
<i></i>还适用于拉丁学名（<i>Homo sapiens</i>）、船名（<i>Titanic</i>）、音标（<i>/ˈkæt.ə.lɒɡ/</i>）
为什么 不能替代 CSS 高亮背景
<mark></mark> 不是“给文字加黄色底色”的快捷方式，它表示的是“该文本与当前上下文强相关”——典型如搜索结果中匹配的关键词、文档中被临时标注的引用段落。
一旦脱离这个语义前提，比如用 <mark></mark> 给导航菜单当前项着色，就等于向辅助技术传递错误信号：告诉屏幕阅读器“这段文字此刻特别相关”，但它其实只是个 UI 状态。
- 该用
<mark></mark>：搜索页显示「找到<mark>React</mark> 相关文档 12 篇」</li> <li>不该用 <code><mark>
：侧边栏中「<mark>仪表盘</mark>」作为当前激活项 - 替代方案：用 class + CSS 控制视觉高亮，保持 HTML 语义干净
的边界：附属细则 ≠ 小号字体
<small></small> 的语义是“附属细则”，不是“我要让这段字变小”。它的默认样式只是浏览器实现，你可以用 CSS 改掉字号，但只要它还在 <small></small> 里，语义就是“这是次要补充信息”。
容易踩的坑是把它当成通用缩放工具：比如用 <small></small> 做页脚版权、用 <small></small> 压缩表格内说明文字、甚至嵌套在 <strong></strong> 里试图“又重要又小”——这直接冲突：重要性高的内容不该被降级为附属细则。
- 合理用法：
<small>© 2026 Example Corp. 保留所有权利。</small> - 不合理用法：
<strong><small>立即购买</small></strong>（重要动作 + 附属细则 = 语义矛盾） - 性能影响：过度嵌套
<small></small>不影响渲染，但会让可访问性树混乱，AT 工具可能跳过或误读
语义边界不是靠记住标签列表划出来的，而是每次写标签前问一句：我是在描述“这是什么”，还是在指挥“让它看起来像什么”。后者该交给 CSS，前者才轮到 HTML 标签开口。
