em用于语义强调，传达重读语气并被读屏器和搜索引擎识别；i仅表示类型区别，如外文词或学名，不传递语气。误用i替代em会损害无障碍访问与SEO效果。
em 是语义强调，不是“加斜体”的快捷键
浏览器默认把 em 渲染成斜体，但它的作用远不止视觉效果。它明确告诉屏幕阅读器：“这个词在说话时被重读了”，也会被搜索引擎识别为语气重点或关键词强化。误用 em 当斜体开关，会导致辅助技术误判语调节奏，甚至稀释真正关键信息的语义信号。
常见错误现象：<i>必须</i>保存后退出 —— “必须”是强制语气，该用 em；用 i 就等于放弃语义，读屏软件会平读，用户可能漏掉约束条件。
- 适合用
em的场景：反讽（“这真是完美的方案”）、操作提醒（“请立即保存配置”）、术语首次引入（“DOM是文档对象模型”） -
em支持嵌套，双层<em><em>绝对</em></em>会被主流读屏器（NVDA/VoiceOver）识别为更强语气层级，可能延长停顿或升调 - CSS 覆盖样式（如
em { font-style: normal; }）不影响其语义——爬虫和读屏器只看标签名，不看最终渲染
i 标签只标记“类型不同”，不传递语气
i 的本职是标注那些“在语境中本就该区别呈现”的文字，比如外文词、生物学名、船名、未翻译短语。它不暗示重音、不触发读屏变调、也不参与 SEO 权重计算。把它当通用斜体工具，等于主动丢掉语义控制权。
典型误用：<i>API</i> 接口文档 —— “API”已是通用术语，无需额外语义隔离；若需强调，应改用 em；若纯为视觉区分，更稳妥做法是用 span + CSS font-style: italic。
立即学习“前端免费学习笔记（深入）”；
- 正确用
i的场景：拉丁学名（<i>Canis lupus</i>）、外文短语（She said <i>je ne sais pas</i>）、作品标题（<i>The Great Gatsby</i>） -
i嵌套无意义：<i><i>café</i></i>和单层效果一样，读屏器仍按普通文本处理 - HTML5 规范明确要求：当斜体仅用于排版目的时，
i是唯一合规选择；但只要涉及语气、重点、反语，就必须用em
React/Vue 中写错标签不会报错，但 a11y 工具会立刻标红
JSX 或模板里混用 em 和 i，页面照样渲染，开发者也看不出异常。问题出在自动化测试环节：eslint-plugin-jsx-a11y 会报 jsx-a11y/no-distracting-elements，axe 扫描会将 i 包裹的操作指令（如“点击<i>此处</i>上传”）标为 color-contrast 风险——因为 i 被归类为“装饰性内容”，其颜色对比度不被强制校验。
- 团队协作中，错用
i写强调，QA 或无障碍测试直接标为 bug，返工成本远高于写代码时多想一秒 - SEO 工具（如 Siteimprove）会把
i标记为“低语义密度区域”，影响整体可访问性评分 - 语音交互设备（如智能音箱读网页）依赖标签语义做语调决策，
i不触发任何变化，em则可能改变停顿与重音
真正容易被忽略的是：语义错误从不报错，却在关键场景失效
光看浏览器渲染效果，em 和 i 都是斜体，根本分不出差别。但一旦接入读屏软件、搜索引擎爬虫、静态站点生成器或语音交互链路，错位的语义就会立刻暴露——而那时修复已不是改个标签那么简单，可能牵扯整套内容策略和无障碍合规流程。
