用 samp 标签不是为了“让文字变等宽”，而是为了明确告诉浏览器和辅助技术：“这段文本是程序真实跑出来的输出结果”。错用它，屏幕阅读器会读错、SEO 会抓偏、可访问性直接打折。
什么时候必须用 samp？看三个硬条件
只有同时满足以下三点，samp 才是语义合法的选择：
- 内容是程序或 CLI 工具**执行后直接生成的原始文本**（比如
git status的输出，不是你手写的模拟字符串） - 这段文本**真实出现在终端、浏览器控制台、GUI 弹窗里**（用户眼睛实际看到的那串字符）
- 上下文清晰指向“这是输出”，而非输入、代码、解释或 UI 提示（例如表单校验文案
邮箱格式不正确就不该套samp）
samp 为啥没变等宽？别怪标签，怪样式链
samp 是语义标签，不是样式开关。浏览器默认用 font-family: monospace 渲染，但这个行为极易被覆盖：
- 全局 CSS 重置（如
body { font-family: sans-serif }）会干掉默认字体 - 父容器设置了
font-family且未显式继承，samp就跟着变 - 某些 CSS 框架（如 Tailwind 的
prose）会重置内联元素字体
实操建议：
检查开发者工具中 samp 元素的「Computed」面板，确认 font-family 是否为 monospace；
稳定方案是统一加 CSS：samp { font-family: ui-monospace, 'SFMono-Regular', Consolas, 'Liberation Mono', monospace; }
立即学习“前端免费学习笔记（深入）”；
多行输出必须配 pre，但别嵌套 code
samp 是内联元素，天然不换行。遇到堆栈跟踪、ls -l 输出这类多行内容，必须用 pre 包裹：
<pre class="brush:php;toolbar:false;"><samp>Traceback (most recent call last):<br> File "test.py", line 1, in <module><br> 1/0<br>ZeroDivisionError: division by zero</samp>
注意两点：
- 允许
pre > samp，也允许samp内含kbd或strong（如强调错误类型），但禁止code > samp—— 那等于说“输出里还嵌着一段代码”，语义冲突 - 不要写成
<pre class="brush:php;toolbar:false;"><code><samp>...</samp></code></pre>，code和samp语义互斥，嵌套会让解析器困惑
和 code、kbd 混用时，最容易踩的坑是什么？
核心混淆点在于：三者都常出现在技术文档里，但代表完全不同的“角色”：
-
code：表示**源代码本身**，比如fetch("/api")、user_id -
samp：表示**这段代码跑完吐出来的东西**，比如{"status":"ok"}或error: connection refused -
kbd：表示**用户按下的物理按键**，比如<kbd>Ctrl+C</kbd>，不是命令名，也不是输出
典型误用：
把 API 响应 JSON 直接包进 code → 错，那是输出，该用 samp；
把 npm install 命令写成 <samp>npm install</samp> → 错，那是用户输入，该用 kbd 或普通文本；
在错误提示里写 <samp>请检查网络连接</samp> → 错，这是 UI 层文案，不是程序 stderr 输出。
最常被忽略的一点：语义一旦写错，就无法靠 CSS 补救。屏幕阅读器不会因为你加了等宽字体就自动理解这是输出——它只认标签。写之前先问自己：这串字，是不是用户真正在终端里一模一样看到的那几行？
