标签用于语音重读而非标术语，其斜体是默认样式非目的；专业术语应优先用或，仅在需语调对比时才用。
em 标签不是用来强调「重要性」而是表达「语义重音」
很多人一看到 <em></em> 就默认它是“加粗”或“高亮”的替代品，尤其在写专业文档时，会用它包裹术语如 <em>API</em> 或 <em>TCP/IP</em>。这其实违背了 HTML 语义初衷：<em></em> 表示该词在当前语境中需被**语音重读**（比如对比、转折、反讽），而非单纯标出术语。浏览器默认斜体只是呈现结果，不是设计目的。
专业术语排版真正需要的是**可预测、可复用、无障碍友好的标记方式**，<em></em> 在以下情况反而会干扰屏幕阅读器或 CSS 主题切换：
- 术语首次出现时加
<em></em>，后续不再加——导致语义不一致，AT（辅助技术）无法识别这是术语而非临时强调 - 与
<strong></strong>混用，比如<strong>HTTP</strong> status code <code><em>404</em>——语义层级混乱，既非强调也非重音 - 依赖默认斜体样式做术语标识，但用户启用高对比度模式或自定义 CSS 后，斜体消失，术语失去视觉锚点
专业术语该用什么标签？优先考虑 dfn 和自定义 span 类
<dfn></dfn> 是 HTML 原生语义标签，专为“定义术语”设计，适用于术语首次出现并附带解释的场景。它自带隐含语义（definition），对 SEO 和屏幕阅读器更友好。
如果只是统一标识术语（不带解释），用带语义类名的 <span></span> 更可控：
立即学习“前端免费学习笔记（深入）”；
<span class="term">OAuth 2.0</span> <span class="term">JWT</span>
这样做的好处：
- CSS 可统一控制样式（斜体/颜色/下划线），且不影响语义流
- 通过
aria-label或title补充发音或缩写全称（如<span class="term" title="JavaScript Object Notation">JSON</span>） - 避免与
<em></em>、<i></i>的历史歧义纠缠（<i></i>在 HTML5 中已明确用于“非本质性斜体”，如外文、船名、术语等，但需配合lang或注释才稳妥）
什么时候真该用 em？看上下文是否需要语音重读
只有当术语出现在需要**改变语调以传递意图**的句子中，<em></em> 才合适。例如：
<p>Don’t use <em>GET</em> for state-changing operations — use <em>POST</em> instead.</p>
这里 <em>GET</em> 和 <em>POST</em> 不是标术语，而是强调对比关系，语音上会重读这两个词。换成 <span class="term">GET</span> 就丢失了这个修辞意图。
容易误用的边界情况：
- “The
<em>response</em> body must be JSON.” —— 错。这里 <code>response是普通名词，无对比或转折，不该用<em></em> - “This is a
<em>RESTful</em>API.” —— 错。除非你在反驳“这不是 RESTful”，否则只是描述属性，应统一用class="term" - 嵌套使用如
<em><code>fetch()—— 语义冲突：<code>已表示字面量，再套<em></em>会让 AT 重复播报“emphasis”和“code”两层信息
兼容性与工具链注意事项
现代浏览器对 <dfn></dfn> 和 <em></em> 渲染差异极小，但真实影响在构建流程里：
- 部分 Markdown 解析器（如 remark）默认把
*term*渲染为<em></em>，需配置插件改写为<dfn></dfn>或<span class="term"></span> - 静态站点生成器（如 Hugo、Jekyll）若启用了语法高亮，可能把
<em></em>误识别为内联格式标记而破坏嵌套结构 - 无障碍测试工具（如 axe、WAVE）会对高频
<em></em>报告“语义滥用”，尤其当页面中超过 5% 的文本被包裹时
真正麻烦的不是怎么写，而是团队协作时没人校验语义——一个 <em></em> 被当成样式钩子反复复用，三年后重构时才发现它本意是“这句话请重读”。
