em标签表示语义强调，影响读屏语气和seo权重；i标签仅作视觉区分，用于术语、外文等无强调场景，二者语义不可互换。
em 和 i 标签的语义本质完全不同
不是“都能斜体所以随便选”，而是浏览器、读屏软件、搜索引擎看到 em 会认为“这句话里这个词被刻意重读了”，看到 i 则只当“这词需要和上下文区分开，但不重要”。视觉上都斜，但语义层完全不互通。
常见错误现象：<i>必须</i>立即提交——“必须”是反讽或强调重点，用 i 就等于告诉屏幕阅读器：“平读，别加重”，用户可能错过关键约束。
- 用
em的场景：语气变化能改变句意，比如“<em>你</em>不能删库” vs “你<code><em>不能</em>删库” - 用
i的场景：术语（<i>Promise</i>）、学名（<i>Homo sapiens</i>）、船名（<i>Queen Mary 2</i>）、外文短语（<i>et al.</i>） - 禁用
i的场景：按钮文字、表单提示、错误信息、任何带操作意图的文本——应改用 CSS + 语义中性标签（如span）
嵌套 em 会改变语音合成行为，但不会叠加视觉效果
连续写 <em><em>真的</em></em>，浏览器不会让字更斜，但主流读屏软件（NVDA、VoiceOver）会识别为更强语气层级：可能延长停顿、加重音调、甚至降速。这不是 bug，是 W3C 明确规定的语义强度传递机制。
而 <i><i>café</i></i> 嵌套毫无意义，纯属冗余；i 没有层级概念，只标记“这是个外来词”，嵌套两次还是“这是个外来词”。
- 嵌套
em仅在需多级强调时有意义，比如引述中再强调某个词：“他说‘<em>绝对</em>不能’，而我强调的是‘<code><em><em>绝对</em></em>’” - 不要为“看起来更斜”而嵌套
em——CSS 的font-style: italic才管样式，em只管语义 - React/Vue 中 JSX 模板里写错嵌套，linter（如
eslint-plugin-jsx-a11y）会直接报jsx-a11y/no-distracting-elements
SEO 和无障碍工具对 em 和 i 的处理差异真实存在
Google 等主流搜索引擎会把 em 内容纳入关键词权重计算，尤其在标题、摘要、段首位置；而 i 几乎不参与语义索引。这不是玄学，是爬虫解析 DOM 时读取元素 role 和隐含 aria-level 的结果。
更实际的影响在无障碍测试中：axe 工具扫描时，若发现 i 包裹了操作指令（如“点击<i>此处</i>上传”），会标为 color-contrast 风险——因为 i 被归类为“装饰性内容”，其颜色对比度不被强制校验，但用户真需要它可读。
-
em触发读屏软件语调变化，i多数情况下被忽略样式、按普通文本朗读 - 某些企业级 a11y 自动化平台（如 Siteimprove）会把
i标记为“低语义密度区域”，影响整体可访问性评分 - 用 CSS 强制让
em不斜（em { font-style: normal; }）没问题，语义仍在；但把i改成加粗（i { font-weight: bold; }）就彻底混淆用途
什么时候该放弃标签，直接用 CSS
如果你只是想让某段文字“看起来斜一点”，且它既不承载语气强调，也不属于术语/外来语等规范场景，那就别碰 em 或 i。直接用 span + font-style: italic，干净利落。
真正容易被忽略的点是字体支持：很多自定义字体（尤其是中文 WebFont）没提供真实斜体变体，浏览器会 fallback 到 oblique 合成倾斜，导致字形模糊、间距异常。这不是标签问题，但常被误归因于 i 或 em。
- 优先指定含真实斜体的字体栈，例如：
font-family: "Segoe UI", "PingFang SC", sans-serif; - 显式声明
font-style: italic，避免依赖浏览器默认行为 - 禁用合成倾斜：
font-synthesis: none;（注意：若字体本身无斜体，此属性会让文字回退到正体）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
