应仅用 <code> 标记单行内联技术标识符，如函数名、参数名等；需转义 HTML 字符，配合 <var> 等提升语义，避免误用于 UI 描述或多行代码。
什么时候该用 而不是 <pre class="brush:php;toolbar:false;"> 或普通文本</H3>
<p>在 API 文档里，<code> 只用于标记**单行、内联的技术标识符**：函数名、参数名、返回值类型、HTTP 方法、属性名、CSS 关键字等。它不是装饰性标签，也不该用来包裹多行代码或解释性文字。</p>
<p>常见误用现象：<code>fetch()
写成 fetch() { ... }；把整个 JSON 响应体塞进 ；用 <code> 包裹“点击按钮”这类 UI 描述。</p>
<ul>
<li><code>fetch
、response.status、GET、application/json ✅
function handleSuccess(data) { ... } ❌（应套 <pre class="brush:php;toolbar:false;">）</li> <li><code>点击【提交】按钮❌（这是 UI 文本，用
{"id":1,"name":"test"} ❌（JSON 块需转义后放 <pre class="brush:php;toolbar:false;">）</li> </ul> <H3>嵌套规则与字符转义必须做</H3> <p><code> 标签内容里的 HTML 字符（如 <、>、&）必须手动转义，否则浏览器会解析为真实标签，导致 DOM 错乱或内容截断。这不是可选项，是解析安全底线。</p> <p>比如想显示 <code>element.innerHTML，不能直接写
element.innerHTML，因为点号后紧接的 会被当成开始标签解析。立即学习“前端免费学习笔记（深入）”；
- 正确写法：
element.innerHTML→ 实际 HTML 应为<code>element.innerHTML</code></li> <li>错误写法：<code>element.innerHTML
→ 浏览器尝试解析 ，后续内容可能丢失 - 工具建议：用模板引擎时启用自动转义（如 Handlebars 的
{{{raw}}}要慎用），手写 HTML 必须查表替换：<、>>、&&
和 、、 配合提升语义准确性
API 文档里不同角色的技术词，用不同语义标签组合，能帮屏幕阅读器、搜索引擎和开发者快速区分上下文。单独用
是基础，但不够精准。</p> <ul> <li>变量/参数名：用 <var> 包裹，再套 <code>，如 <code><var>url</var>（表示这是一个可变占位符）
</li> <li>程序输出示例：用 <samp>，如 <samp>404 Not Found</samp>，也不放进 <code></li> <li>函数调用本身：纯 <code>fetch()即可；带参数的调用如
JSON.parse(<var>text</var>) 更清晰
样式与可访问性容易被忽略的细节
浏览器默认给
加等宽字体，但很多团队 CSS 重置时会覆盖 font-family，导致技术词失去视觉辨识度。更隐蔽的问题是：屏幕阅读器对 <code> 的朗读语调依赖内容准确性，而非样式。</p>
<ul>
<li>CSS 建议显式声明：<code>code { font-family: ui-monospace, 'SFMono-Regular', Consolas, monospace; }
里塞冗余符号：如 <code>`fetch()` 中的反引号是 Markdown 残留，HTML 里不该出现
替代 ARIA：比如 <code aria-label="关闭弹窗">✕ 是错的——✕ 是 UI 符号，不是代码，应改用
不影响渲染性能，但若文档页含数百个未转义的 <code>，可能导致 HTML 解析卡顿或静默截断
最常被跳过的其实是转义和语义组合——写完 API 文档后，用浏览器 DevTools 查看渲染出的实际 DOM 结构，比对着规范检查更快发现漏转义或错嵌套。
