<p>、<strong>、<em>、<code>、<pre> 五个标签覆盖90%日常文本需求；<b>/<i>无语义，应优先用 <strong>/<em>；<code>用于行内代码，<pre>用于多行代码；<p>内不可嵌套块级元素。
直接说结论：<p>、<strong>、<em>、<code>、<pre> 这五个标签覆盖了 90% 的日常文本表达需求，其余标签要么语义模糊（如 <b>、<i>），要么使用场景极窄（如 <var>、<sub>）。别被“常用标签列表”带偏，先吃透这五个，再谈扩展。
为什么不用 <b> 和 <i>？
浏览器确实会把 <b> 渲染为粗体、<i> 渲染为斜体，但它们**没有语义**——只是“我要这样显示”，而 <strong> 表示“这段内容很重要”，<em> 表示“这里需要重读”。屏幕阅读器会据此调整语调，SEO 也会识别权重差异。
常见错误现象：
- 用
<b>包裹价格数字（应改用<strong>） - 用
<i>标注外文术语（应改用<em>或更准确的<cite>） - 在 CMS 导出 HTML 中批量出现
<b>，导致无障碍检测失败
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有强调/重要性判断，优先选
<strong>或<em> - 仅当明确需要“纯样式、无语义”时（例如 UI 图标文字、品牌 slogan 排版），才考虑
<b>/<i>，且必须加注释说明原因 - 用 CSS 的
font-weight和font-style能实现同样视觉效果，语义更干净
<code> 和 <pre> 别混用
<code> 是行内标签，只包裹单个函数名、变量名或命令；<pre> 是块级标签，保留空格与换行，适合多行代码片段。混用会导致格式错乱、缩进丢失、复制粘贴异常。
典型误用场景：
- 把整段 JS 代码塞进一个
<code>标签里（应套<pre><code>） - 在 Markdown 渲染器中未正确嵌套，导致
<pre>内部的<code>失去语法高亮上下文 - 用
<pre>显示单个路径（如/etc/nginx/conf.d/），结果前后多出大段空白
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 单个技术名词：用
<code>fetch</code>、<code>process.env.NODE_ENV</code> - 多行代码块：用
<pre><code class="js">...</code></pre>，并配合 Prism.js 或 highlight.js - 路径、命令、配置项等短文本，仍用
<code>，不升级为<pre>
<p> 不是万能容器，别往里塞块级元素
<p> 的设计初衷是“一段连续文字”，W3C 规范明确禁止在其中嵌套 <div>、<h2>、<ul> 等块级元素。虽然现代浏览器大多会容错渲染，但会触发 DOM 修复逻辑（比如自动闭合 <p>），导致结构意外断裂。
容易踩的坑：
- CMS 编辑器导出时把标题和段落全塞进
<p>，结果<h3>被挤到段落外面 - 用
<p>包裹按钮组（<button>是行内元素，但组合后实际需要块级流） - 在表单中用
<p>包<label>+<input>，影响可访问性（label 应显式关联 input）
实操建议：
立即学习“前端免费学习笔记（深入）”；
-
<p>内只放纯文本、<strong>、<em>、<a>、<code>等行内容器 - 需要布局控制时，用
<div>或语义化容器（<section>、<article>） - 表单控件组合请用
<fieldset>+<legend>，而非<p>
真正难的不是记住标签名，而是每次敲下 < 时，先问一句：“这段内容在逻辑上属于什么？”——是独立段落？是程序输出？是用户必须注意的关键值？答案决定了该用哪个标签，而不是哪个看着顺眼。
