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 权重计算。把它当通用斜体工具，等于主动丢掉语义控制权。

html-to-pptx

将多页 HTML 演示文稿转换为美化的 PPTX 文件，便于分享和分发。

下载

典型误用：<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 都是斜体，根本分不出差别。但一旦接入读屏软件、搜索引擎爬虫、静态站点生成器或语音交互链路，错位的语义就会立刻暴露——而那时修复已不是改个标签那么简单，可能牵扯整套内容策略和无障碍合规流程。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！