应优先用强调语义重要性，如警告、法律条款；仅用于无语义的视觉加粗，如人名、产品名；错误混用会削弱屏幕阅读器表现和seo效果。
什么时候该用 <strong></strong> 而不是 <b></b>
语义优先。如果你强调的是内容重要性（比如警告、关键参数、法律条款中的强制项），必须用 <strong></strong>；<b></b> 只适合纯视觉加粗且无额外语义的场景，比如人名、产品名在段落中需要突出但不改变含义时。
常见错误是把所有加粗都写成 <b></b>，结果屏幕阅读器读不出语气变化，SEO 也弱化了关键词权重。浏览器默认样式两者看起来一样，但语义层完全不同。
-
<strong></strong>会被屏幕阅读器加重朗读 -
<b></b>不触发任何辅助技术行为 - 搜索引擎会把
<strong></strong>内文本视作更高相关性信号
<pre class="brush:php;toolbar:false;"></pre> 和 <code> 混用时的排版陷阱
<pre class="brush:php;toolbar:false;"></pre> 保留所有空白符和换行，<code> 只是语义标记——它本身不控制换行或空格。很多人嵌套写成 <pre class="brush:php;toolbar:false;"><code>...</code></pre>，以为能“安全展示代码”，但漏掉了关键点：CSS 默认会给 <pre class="brush:php;toolbar:false;"></pre> 设定固定宽字体和 white-space: pre，而 <code> 单独使用时依赖父容器样式。
真正可靠的组合是：<pre class="brush:php;toolbar:false;"><code></code> + 显式 CSS 重置 <code>white-space: pre-wrap</code> 或 <code>pre-line</code>，否则长代码行会溢出容器或被截断。</pre>
- 只用
<code>：适合行内代码片段，如console.log() - 只用
<pre class="brush:php;toolbar:false;"></pre>：适合保留缩进的多行文本（非代码也可） - 二者嵌套：必须加 CSS 控制换行行为，否则移动端极易出问题
上标/下标与单位符号混排时的对齐问题
写 <sup>2</sup> 表示平方米（m²）看着没问题，但实际渲染中，<sup></sup> 的 baseline 偏移量由浏览器决定，和紧邻的普通字符（如 “m”）垂直对齐常有像素级偏差，尤其在小字号或非等宽字体下明显。
更稳妥的做法是：单位统一用 Unicode 上标字符（如 ²、³、₁、₂），它们和基字同属一个字体 glyph，对齐天然一致；仅当内容动态生成、无法预知上标值时，才用 <sup></sup>，并配合 vertical-align: top 微调。
- 静态单位（如 cm²、kg·m/s²）优先用 Unicode 字符
- 动态公式（如用户输入的 x
<sup>n</sup>）必须用<sup></sup>，但需测试不同字体下的 baseline 一致性 - 避免
<sup></sup>套<sup></sup>，会导致嵌套偏移放大
格式化标签嵌套顺序影响可访问性
HTML 规范明确禁止某些嵌套，比如 <strong><em><u>...</u></em></strong> 看似层层强调，但屏幕阅读器可能跳过中间层，或按错误顺序播报。真正有效的组合只有两类：
- 语义叠加：如
<strong><em>紧急操作</em></strong>（既重要又需强调语气） - 格式+语义：如
<code><var>username</var>（变量名以代码字体显示） - 禁止混合装饰型标签：
<b><i><u></u></i></b>这类纯样式堆叠，既不可访问，也不利于维护
最易被忽略的是：嵌套后若未通过无障碍工具（如 axe 或 Lighthouse）验证，很可能在真实辅助设备上完全失效——视觉效果正常 ≠ 语义可用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
