em标签的核心作用是语义强调而非视觉斜体，它向辅助技术传递语气重音信号；i标签仅用于惯用斜体文本（如外文、学名），无强调含义；纯样式需求应直接用css的font-style。
em 标签不是“加斜体”，是告诉浏览器“这段话语气要重”
em 的核心作用不是视觉样式，而是语义信号：它明确表示内容在上下文中需要被强调——比如纠正、转折、反语、紧迫提醒。浏览器默认用斜体呈现，只是历史惯例；真正关键的是辅助技术（如读屏软件）会改变语调、停顿或音量来朗读 em 内容，搜索引擎也可能据此提升关键词权重。
常见误用现象：
– 把 em 当作“快捷斜体按钮”，在纯排版场景（如菜单项、标题副标）里滥用
– 嵌套过深（如 em 里再套 em），导致读屏器语调混乱或跳过
– CSS 重置了 font-style 后以为 em “失效”，其实语义仍在，只是视觉没反馈
实操建议：
– 仅当某词/短语在口语中你会提高声调、拉长音或加重读时，才用 em
– 首次出现技术术语且需强调其重要性时可用，例如“DOM 是页面结构的核心” → “DOM 是页面结构的核心”
– 不要依赖 em 实现图标、装饰性斜体或统一字体风格
i 标签只负责“按惯例该斜体”，不传递任何语气或重要性
i 的语义非常窄：W3C 明确定义为 idiomatic text（惯用语文本），即那些因行业惯例、语言习惯或出版规范而必须用斜体、但本身无强调意图的内容。它对读屏器、SEO、可访问性工具完全透明——既不加重，也不加权，更不改变朗读逻辑。
典型合法用例：
– 外文短语：<i>et al.</i>、<i>raison d'etre</i>
– 生物学名：<i>Homo sapiens</i>
– 船舶、书籍、电影标题：<i>Titanic</i>、<i>The Great Gatsby</i>
– 技术术语缩写首次出现（需配合 title）：<i title="Application Programming Interface">API</i>
禁止行为：
– <i class="icon-user"></i> 这类图标字体用法，属于语义污染，应改用 svg 或带 ARIA 的 span
– 用 i 包裹警告文案、操作提示、错误说明等需要用户注意的内容
– 在响应式设计中假设 i 比 em “更稳定”，其实两者都受 CSS 控制，稳定性取决于你是否重置了 font-style
想单纯让文字变斜？别碰标签，直接上 CSS
如果目标只是“让某段文字看起来是斜体”，最干净、最可控的方式是用 CSS：font-style: italic。这彻底剥离了语义与样式的耦合，避免误用 em 或 i 带来的可访问性风险。
为什么不用标签凑合：
– em 会向读屏器广播“强调”信号，干扰真实语义流
– i 的合法使用范围极小，多数“想斜体”的场景其实不符合规范
– 样式统一难：不同组件用不同标签，CSS 重置时容易漏掉某一种
– 未来维护成本高：别人接手代码时，得逐个判断每个 i 是否真属“生物学名”级别
推荐写法：
– 给需要斜体的元素加 class：<span class="term">integer</span>
– 全局控制：.term { font-style: italic; }
– 若需兼容旧浏览器，可加 font-style: oblique 回退
检查你有没有踩坑：开发者工具里看 role 属性
打开浏览器开发者工具，选中一个 em 元素，在 Accessibility 面板里能看到 role="emphasis"；而 i 元素没有对应 role。这个差异不是理论，是实际影响读屏行为的关键指标。
容易被忽略的点：
– 某些 CMS 或富文本编辑器会把“点击斜体按钮”直接转成 i，但用户本意可能是强调，结果语义错位
– SSR 渲染时若服务端未注入完整 ARIA 信息，em 的 role 可能丢失，需确认 hydration 后是否恢复
– 测试可访问性不能只看视觉，必须用真实读屏器（如 NVDA、VoiceOver）听一遍，尤其关注嵌套和连续 em 的语调变化
一句话判断标准：删掉所有样式后，这段文字是否仍需被“说出来不一样”？如果是，用 em；如果只是“印出来 traditionally 斜着”，用 i；如果连这个都不需要，就用 CSS。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
