samp 标签专用于标记程序或系统生成的输出样本，仅提供语义而非样式，需配合 CSS（如 font-family: monospace 和 white-space: pre）及 pre 元素才能正确呈现格式与语义；它区别于 code（代码）和 var（变量），不可嵌套块级元素，且应按行粒度使用以保障可访问性。
用 <samp> 标签展示程序输出时，它只负责语义，不控制样式
<samp> 是 HTML 中的短语元素，专用于标记「程序或系统生成的输出样本」，比如命令行返回、日志片段、API 响应体。它的核心作用是告诉浏览器和辅助技术“这是输出结果”，而非“这里要加等宽字体”——后者得靠 CSS 实现。
常见错误是以为写上 <samp>hello world</samp> 就自动变等宽、带背景、换行对齐。实际上默认渲染跟 <span> 几乎一样，尤其在现代框架或重置样式（如 normalize.css）后更不明显。
- 必须配合 CSS 设置
font-family: monospace才能体现代码输出感 - 若内容含空格、缩进或换行，
<samp>本身不保留空白；需加white-space: pre或pre-wrap - 不要嵌套
<div>或块级元素——<samp>是内联元素，非法嵌套会触发浏览器纠错，可能意外折行或丢失语义
真实场景中如何正确包裹多行命令输出
比如你想展示 git status 的终端输出，直接写换行文本会被压缩成一行。正确做法是：用 <pre> 包裹 <samp>，既保语义又保格式。
<pre><samp>On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean</samp></pre>
这里 <pre> 负责保留缩进与换行，<samp> 负责声明语义。两者组合是 W3C 推荐模式，比单用 <pre> 更准确——因为 <pre> 可用于任意预格式化文本（如诗歌），而 <samp> 明确指向“程序输出”。
立即学习“前端免费学习笔记（深入）”；
- 避免只用
<pre>替代<samp>，否则屏幕阅读器无法区分“诗”和“报错信息” - 如果输出里有用户输入部分（如 shell 提示符
$ git status），输入内容建议用<kbd>，输出用<samp>，例如：<kbd>$ git status</kbd><br><samp>On branch main</samp> - 不要给
<samp>加display: block来强行换行——破坏内联语义，且可能干扰可访问性树
与 <code>、<var> 的关键区别在哪
<samp> 不是 <code> 的简化版，三者语义不可互换：
-
<code>表示「一段计算机代码」（如函数调用、HTML 片段），强调“可执行/可编写” -
<samp>表示「这段文字是程序运行后吐出来的结果」，强调“已执行/已生成” -
<var>表示「变量占位符」（如<var>filename</var>），不是实际值，也不代表输出
典型混淆点：把 console.log("user_id: 123") 的输出 user_id: 123 写成 <code>user_id: 123</code> —— 这错了，它不是代码，是运行结果，该用 <samp>user_id: 123</samp>。
兼容性与可访问性注意事项
所有现代浏览器都支持 <samp>，但旧版 IE（≤8）不识别，不过它会降级为普通内联元素，不影响内容显示，只是丢失语义。真正影响大的是可访问性工具：
- 主流屏幕阅读器（NVDA、VoiceOver）会将
<samp>读作“sample output”，帮助视障用户快速判断这是“结果”而非“说明”或“命令” - 如果输出含颜色（如红字报错），仅靠颜色传达信息是失败的——需额外加文字提示，如
<samp><span aria-label="error">Error: file not found</span></samp> - 避免在
<samp>里放交互控件（按钮、链接），它本意是静态输出；真有交互需求，应在外层容器处理
最常被忽略的是语义粒度：一行输出用一个 <samp>，不要把整个终端 session 塞进一个标签里——这会让辅助技术难以定位具体哪行出错。
