samp标签专用于语义化标记程序真实生成并由用户代理（如终端、控制台）原样呈现的原始输出文本，必须同时满足来源真实、场景明确、角色为“输出”三条件；多行输出须用pre包裹samp，不可仅靠默认样式或br实现换行。
samp 标签不是“模拟”输出，而是语义上声明「这就是程序实际吐出来的原始文本」——用错就等于告诉屏幕阅读器“这行字是可执行代码”，但其实它只是个错误提示。
什么时候必须用 samp，而不是 code 或纯文本
只在你明确知道这段文字是用户代理（终端、浏览器控制台、CLI 工具）**真实渲染出的输出结果**时才用。比如：
-
samp适合：sampFile not found: config.json/samp、sampHTTP/2 200/samp、sampv20.11.1/samp -
code才适合：codels -l/code、codefetch()/code、code/etc/passwd/code - 纯文本或
span适合说明性内容，比如“该命令用于列出文件”——这些不该加任何语义标签
samp 本身不换行，多行输出必须配 pre
samp 是内联元素，HTML 默认会把换行符和多余空格压成单个空格。直接写 sampLine1\nLine2/samp 在页面上就是一行。
- 正确做法：用
pre包裹samp，保留原始格式：presampTraceback (most recent call last):
File "main.py", line 3, in <module>
NameError: name 'x' is not defined/samp/pre - 错误做法：多个
samp拼接、或在samp里硬塞br（虽能显示换行，但语义断裂，且部分读屏工具会把每行当成独立输出） - 注意：
pre>samp是合法嵌套；反过来samp>pre是 HTML 规范禁止的
特殊字符必须实体化，否则会被当标签解析
如果输出里含 <、>、&（比如日志中出现 <div> 或 XML 片段），不转义就会被浏览器当作 HTML 标签处理，导致截断或 XSS 风险。
- 服务端渲染时，必须对内容做 HTML 实体编码：
<替代，<code>>替代>，&替代& - 前端 JS 动态插入时，别用
innerHTML直接写入原始字符串，改用textContent或先转义 - 常见陷阱：把
console.log('<script>')的输出原样塞进samp，没转义就等于执行脚本
样式不能只靠默认，但别破坏语义
浏览器只给 samp 设了等宽字体，没背景、没边距、不保留空格——光靠默认样式根本看不出这是输出。
- 基础修复 CSS：
samp{font-family: ui-monospace, 'SFMono-Regular', Consolas, monospace;white-space: pre-wrap;background-color: #f6f6f6;padding: 0.1em 0.3em;border-radius: 3px; } - 不要加
font-weight: bold——输出文本本身不含强调语义；加粗反而让读屏工具误判重点 - 移动端慎用
font-size< 14px，NVDA 等工具可能跳过朗读 - 颜色信息（如红字错误）不能只靠
color传达，必须配文字说明：“错误以红色高亮显示”
最难的从来不是怎么写 samp 标签，而是判断“这段文字到底算不算程序输出”——同一串 JSON，在调试日志里可能是 samp，在接口文档里就必须是 pre + code。语义边界模糊时，优先看它是否被终端或控制台原样打印出来。
