<strong>和<b>语义不同：<strong>表强调，屏幕阅读器会重读；<b>仅加粗，无语义。<i>用于外语词等，非斜体样式。<u>纯样式，易与链接混淆；<ins>表新增内容，支持datetime。<del>需重置CSS且防DOMPurify误删。
<strong> 和 <b> 不是“都能加粗就随便用”，语义错位会直接影响屏幕阅读器行为和 SEO 权重分配。
为什么 <b> 和 <i> 会破坏可访问性
它们只描述外观，不传递意图。当屏幕阅读器遇到 <b>，通常静默跳过；而 <strong> 会被读作“强调”，语速变慢、音调升高。
- 用户写
<b>重要通知</b>，实际语义是“这句需要被重视”，但用了<b>就等于没说 -
<i>本意是外语词、术语或船名（如<i>Titanic</i>），不是“想斜着就上” - 在 Vue 或 React 模板中混用
<b>和<strong>，会导致 Lighthouse 可访问性审计失败（aria-label冗余、role冲突等）
<u> 和 <ins> 的视觉一致但语义天差地别
<u> 是纯样式标签，现代浏览器默认禁用下划线（因易与链接混淆），必须手动加 text-decoration: underline 才可见；<ins> 则明确表示“此处新增内容”，自带语义且支持 datetime 属性。
- 表单提交后展示修改记录：
<ins datetime="2026-10-01T14:22">已更新邮箱</ins>—— 这个时间戳能被辅助技术识别 - 误用
<u>做高亮：不仅视觉不可靠（可能被 CSS 重置），还会让键盘用户无法区分是否为可点击链接 - 部分 CMS 导出 HTML 时自动把“高亮文本”转成
<u>，需在构建流程中用 PostHTML 插件批量替换
<del> 被忽略的兼容性陷阱
<del> 在 IE11 及更早版本中不支持 datetime，且所有浏览器对 <del> 的默认样式（虚线删除线）不统一；若依赖它做“价格对比”，必须显式重置样式。
立即学习“前端免费学习笔记（深入）”；
- CSS 必须覆盖：
del { text-decoration: line-through; color: #999; }，否则 Safari 可能显示实线，Firefox 显示点划线 - 服务端渲染（SSR）场景下，若
<del>包裹的是动态数据，需确保innerHTML解析时不被 DOMPurify 清洗掉（默认会删<del>） - 不要嵌套
<del><span>xxx</span></del>：某些旧版 Android WebView 会丢失内联样式继承
真正容易被忽略的，是格式化标签和 ARIA 属性的组合使用——比如 <strong> 已含语义，再加 aria-label 反而造成重复播报；而 <b> 加 aria-strong 并不存在，属于无效写法。
