应优先使用语义化标签：表重要强调（屏幕阅读器加重、seo加权），仅视觉加粗；表语义重读，用于术语/外文等斜体场景；受限于html5语义，非拼写错误等场景须用css实现下划线；专指法律旁注类次要但需保留文本，非单纯缩小字号。
<strong></strong> 和 <em></em> 应该优先于 <b></b> 与 <i></i> 使用；<u></u> 已被 HTML5 明确限制语义，纯视觉下划线请用 CSS 实现。
什么时候该用 <strong></strong> 而不是 <b></b>
关键区别不在“是否加粗”，而在“浏览器和辅助技术是否理解其重要性”。<strong></strong> 会被屏幕阅读器加重语气朗读，搜索引擎也会赋予更高权重；<b></b> 只是视觉加粗，无语义信号。
- 用户协议中的“不得擅自修改配置”这类强制条款，用
<strong></strong> - 商品页的“限时特价”若仅为营销强调、无法律/操作约束力，可用
<b></b> - 同一段落中嵌套多层强调时，
<strong><strong>最高优先级</strong></strong>是合法且可读的 - 不要为了“统一加粗样式”而放弃语义——CSS 可以让
<strong></strong>不加粗，也能让<span></span>加粗
<em></em> 和 <i></i> 的实际分工场景
<em></em> 表示语义重读，比如“我**没**说错”里的“没”；<i></i> 则用于术语、外文名、船名、作品名等需斜体但不强调语气的内容。
- 数学公式中变量
<var>x</var>比<i>x</i>更准确，但若仅作排版且无 JS 交互，<i></i>仍可接受 - 中文网页里写“《红楼梦》”不用
<i></i>，书名号本身已具标识作用；但“Veni, vidi, vici”必须用<i></i> - 避免用
<em></em>包裹整段话——它本意是“某几个词需要重读”，不是“这段很重要”
为什么 <u></u> 现在基本不该直接用
HTML5 明确定义 <u></u> 仅适用于拼写错误、专有名词标注（如中文专名号）、或人工审核标记，**不是通用下划线工具**。浏览器默认下划线与超链接高度混淆，对无障碍访问极不友好。
- 想给关键词加下划线？写 CSS：
span.underline { text-decoration: underline; } - 需要标记错别字？用
<u class="spelling-error">制序</u>并配合 ARIA 属性 - 旧项目里大量
<u></u>标签，迁移时建议批量替换为带类名的<span></span> - 部分 CMS 导出 HTML 仍默认用
<u></u>，需在解析层拦截并转换
<small></small> 不只是“字号小”，它有明确法律语义
<small></small> 在规范中特指“旁注、版权信息、免责声明、法律条文”等次要但需保留的文本，不是排版意义上的“缩小字体”。滥用会导致语义污染和 SEO 权重稀释。
- 页脚的 ©2026 Company Inc. —— 合法使用
<small></small> - 按钮旁的“*点击即代表同意条款” —— 若属于法律约束内容，可用；若只是提示，用普通
<span></span>+ CSS 更稳妥 - 响应式设计中用
<small></small>控制移动端字体大小？错。应通过媒体查询控制font-size - Chrome 和 Safari 对
<small></small>的默认字号缩放比例不一致，依赖它做 UI 尺寸控制风险高
<b></b> 成 <strong></strong> 看似微小，但可能影响屏幕阅读器用户的操作路径，也可能改变搜索结果摘要的高亮逻辑。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
