em标签触发读屏语调变化，i标签不会；em用于强调需改变语调的内容，i仅用于外文词、术语等非主叙述流文本，二者语义不可互换且不可仅凭CSS模拟。
em标签触发读屏语调变化，i标签不会
屏幕阅读器（如 NVDA、VoiceOver）遇到 em 会抬高音调、稍作停顿，明确传递“此处被刻意重读”；而 i 被当作普通文本平读，完全不改变语音节奏。这意味着：用 i 包裹“必须保存”，读屏用户听不出强制语气，可能跳过关键操作约束。
常见错误现象：<i>请立即备份</i> → 读屏软件读得和“今天天气不错”一样平淡；正确写法应为 <em>请立即备份</em>。
实操建议：
- 只要朗读时需要改变语调（升调、拖长、加重），就该用
em -
i不是“斜体开关”，它没有语调响应能力，别指望靠它传达紧急、否定或反讽 - 自动化无障碍扫描工具（如 axe）会把
i用于操作提示标为 WCAG 1.3.1 违规
i标签只适用于特定文本类型，不是通用斜体容器
i 的本职是标记“不属于主叙述流”的内容：外文词、生物学名、船名、作品名、术语缩写、内心独白等。它不暗示重要性，也不参与 SEO 权重计算。W3C 明确警告：“不要仅仅为了斜体效果而用它”。
立即学习“前端免费学习笔记（深入）”；
常见误用场景：
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
-
<i>API</i>或<i>JSON</i>—— 这些已是中文技术文档通用词，无需额外语义隔离；若需强调，该用em -
<i class="icon-home"></i>—— 图标字体属于历史写法，现代应改用<span aria-hidden="true"></span>或原生<svg> - 按钮文字写成
<i>提交</i>—— 操作指令必须可感知，应改用<button>或带 CSS 的<span>
正确用法示例：<p>参见 RFC <i>9110</i> 第 4.2 节</p>，这里 i 表示标准编号惯例，与强调无关。
嵌套em有意义，嵌套i纯属冗余
em 支持合法嵌套，用于表达多级语气强度。比如引述中再强调某个词：“他说‘绝对不能’”，其中 绝对 可以再套一层 em，主流读屏软件会识别为更强语气（延长停顿+更明显升调）。
但 i 没有层级概念：<i><i>café</i></i> 和单层 <i>café</i> 效果完全一致，只是多写了几个字符，还可能被 linter 报告为冗余嵌套。
实操建议：
- 嵌套
em仅在真实存在语气层级时使用（如对话引述中的再强调） - 别为“看起来更斜”嵌套
em——那是font-style: italic的事 - React/Vue 中 JSX 模板若误写
<i><em>...</em></i>，eslint-plugin-jsx-a11y 会直接报jsx-a11y/no-distracting-elements
真正容易被忽略的是语义污染的滞后成本
开发阶段用错 em 和 i 几乎零成本，但上线后问题才集中爆发：无障碍审计标红、SEO 权重下降、读屏用户理解偏差。修复成本远高于写对一个标签——因为语义一旦混用，后续维护者很难靠肉眼分辨哪处斜体是强调、哪处是术语、哪处只是历史遗留。
最常被忽略的一点：em 和 i 在 HTML5 规范里是强制分工，不是风格偏好。它们不共享语义，也不能靠 CSS “假装”对方。哪怕你用 CSS 把 em 设成正常字体，它的语义角色依然存在；同理，给 i 加粗加红，它还是没强调意图。
