应使用 <samp> 标记程序实际输出内容,如终端回显、错误堆栈、API 返回体;它语义明确、不可嵌套、需配合 CSS 保留格式,并专用于屏幕阅读器识别为“样本输出”。

什么时候该用 而不是 或 <pre class="brush:php;toolbar:false;"></H3>
<p>当你要标记一段**程序实际跑出来的输出内容**(比如终端回显、错误堆栈、API 返回体),就该用 <samp>。它不是用来包裹代码逻辑,也不是单纯为了换行或等宽显示。</p>
<p>常见误用:<code>console.log("done") 的结果 done 才是 ;而 console.log("done") 本身必须用 或 <pre class="brush:php;toolbar:false;"><code>。</p>
<ul>
<li><samp> 只能包含纯文本或短语级内联标签(<strong>、<em>、<var>),不能嵌套 <div>、<p>、<pre class="brush:php;toolbar:false;"></li>
<li>它不自动保留空格和换行——得靠 CSS 配合 <code>white-space: pre
或 pre-wrap
浏览器默认不给 加等宽字体,尤其旧版 Safari 对 <samp> 的字体继承不可靠,建议显式写 <code>style="font-family: monospace;"</code></li>
<li>如果你只是想“看起来像终端输出”,但没语义需求,用 <pre class="brush:php;toolbar:false;"> + CSS 更轻量;只有需要被屏幕阅读器识别为“程序输出”时,才值得上 <samp></li>
</ul>
<H3><var> 不是变量高亮工具,而是占位符语义标签</H3>
<p><var> 的作用不是让你在代码里标出变量名,而是告诉读者:“这里是个要你替换的值”。它出现在文档说明、CLI 帮助、HTTP 请求示例中,而不是运行时代码里。</p>
<ul>
<li>正确:<code>curl -X GET https://api.example.com/users/<var>user-id</var>
—— user-id 是你要填的实际 ID
错误:let <var>count</var> = 0 —— 这是 JS 语法, 在这里毫无语义,应全用 </li>
<li><var> 通常需配合斜体样式(<code>font-style: italic
)增强可读性,但加样式不能替代语义
别把 JSON 字面量包进 ,比如 {"key":"value"} —— 除非你在写示意性请求体,且上下文明确这是待替换模板
混用 、、 会破坏可访问性
三者语义完全不同,屏幕阅读器会据此播报不同提示: 读作 “keyboard input”, 读作 “sample output”, 则可能跳过或读作 “variable”。混用会让辅助技术用户困惑。
anything-to-html
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
下载
立即学习“前端免费学习笔记(深入)”;
- 用户敲的命令用 :比如 git commit -m "init";命令执行后打印的 [main 123abc] init 才是
- 提示符(如
$ 或 >)不属于用户输入,不该包进 ;更合理的写法是 $</kbd> <kbd>ls -la</kbd></li>
<li>权限错误 <samp>Permission denied</samp> 不能写成 <kbd>Permission denied</kbd> —— 这是系统输出,不是你按下的键</li>
<li><var> 不能脱离上下文独立存在;单独写 <var>filename</var> 没意义,必须出现在类似 “请运行 <code>cat <var>filename</var>
” 这样的句子里
为什么 很少被看见,但不该被忽略
它不像
或 <pre class="brush:php;toolbar:false;"> 那样高频出现,因为大多数开发者只关心“怎么让文字看起来像终端”,而忽略“这段文字在语义上是不是程序输出”。但一旦涉及 SEO、文档自动化提取、无障碍支持或静态站点生成器的语义解析,<samp> 就成了关键信号。</p>
<p>最容易被跳过的细节:它不支持交互,<code>contenteditable
、tabindex 在它身上基本无效;也不能靠 JS 直接绑定事件来模拟复制行为——真要加交互,得在外层套 div 或用 pre 包裹后再处理。
<samp> 的字体继承不可靠,建议显式写 <code>style="font-family: monospace;"</code></li> <li>如果你只是想“看起来像终端输出”,但没语义需求,用 <pre class="brush:php;toolbar:false;"> + CSS 更轻量;只有需要被屏幕阅读器识别为“程序输出”时,才值得上 <samp></li> </ul> <H3><var> 不是变量高亮工具,而是占位符语义标签</H3> <p><var> 的作用不是让你在代码里标出变量名,而是告诉读者:“这里是个要你替换的值”。它出现在文档说明、CLI 帮助、HTTP 请求示例中,而不是运行时代码里。</p> <ul> <li>正确:<code>curl -X GET https://api.example.com/users/<var>user-id</var>—— user-id 是你要填的实际 ID
let <var>count</var> = 0 —— 这是 JS 语法, 在这里毫无语义,应全用 </li> <li><var> 通常需配合斜体样式(<code>font-style: italic)增强可读性,但加样式不能替代语义
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
$ 或 >)不属于用户输入,不该包进 ;更合理的写法是 $</kbd> <kbd>ls -la</kbd></li> <li>权限错误 <samp>Permission denied</samp> 不能写成 <kbd>Permission denied</kbd> —— 这是系统输出,不是你按下的键</li> <li><var> 不能脱离上下文独立存在;单独写 <var>filename</var> 没意义,必须出现在类似 “请运行 <code>cat <var>filename</var>” 这样的句子里


















