必须显式设置 font-family 字体栈，因 <code> 默认仅设 monospace 泛称，各系统映射差异大，中文字体前置或漏引号会导致错位；推荐英文等宽优先+中文备选+monospace兜底，并用 tabular-nums 保数字对齐。
<code> 标签本身不保证等宽字体渲染，浏览器 fallback 到 Courier New 或系统默认字体时，很可能不是真正等宽，尤其在 Windows 旧环境或中文字体混排场景下。必须显式设置 font-family 字体栈，并注意顺序、引号和兜底逻辑。
为什么直接用 <code> 渲染会错位
常见错误现象：中文混排时数字/字母列不对齐、console.log() 看起来“差不多”，但复制粘贴后缩进错乱、表格内 <code> 内容挤成一团。
- 浏览器对
<code>的默认样式极简，只设了font-family: monospace，而monospace是个泛称，不同系统映射的字体差异极大（Windows 常 fallback 到Courier New，它对中文支持差且非全等宽） - 中文字体放在字体栈前面（如
"Microsoft YaHei", monospace）会导致英文代码全部走中文字体——而Microsoft YaHei不是等宽字体，1和0宽度不同，对齐立刻崩坏 - 含空格的字体名漏引号（如
SFMono-Regular写成SFMono-Regular而非"SFMono-Regular"），整条声明失效
推荐字体栈写法（2026 年实测可用）
核心原则：英文主力等宽字体优先 + 中文友好备选 + 可靠兜底。以下为跨平台兼容性较好的写法：
code {
font-family: "SFMono-Regular", "Fira Code", "Cascadia Code", "Consolas", "Liberation Mono", "Menlo", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", monospace;
font-size: 0.875em;
background-color: #f6f6f6;
padding: 0.2em 0.4em;
border-radius: 3px;
}
-
"SFMono-Regular"：macOS 原生等宽字体，无连字、渲染快，适合纯技术文档 -
"Fira Code"和"Cascadia Code"：支持编程连字（如!=、=>），但需确认页面未禁用连字（font-feature-settings: "calt" 0可关） - 中文字体必须放在英文等宽字体之后，且仅作中文字符 fallback；
"PingFang SC"在 macOS 上比"Hiragino Sans GB"更轻，"Microsoft YaHei"是 Windows 下较稳妥选择 - 末尾的
monospace不可省——它是终极兜底，确保即使所有指定字体加载失败，仍保持基本等宽语义
中英文混排与数字对齐的额外控制
如果页面含大量数字表格或需要严格纵向对齐（比如日志时间戳、十六进制值），光靠字体栈还不够：
立即学习“前端免费学习笔记（深入）”；
- 加
font-variant-numeric: tabular-nums：强制数字使用等宽数字变体，1、0、9宽度一致。注意 IE 完全不支持，现代浏览器需搭配支持该特性的字体（"Fira Code"、"Cascadia Code"均支持） - 避免用
letter-spacing微调——它会破坏等宽前提下的字符间距逻辑，反而导致错位 - 不要给
<code>设white-space: pre-wrap：它是行内元素，pre-wrap对换行无效，还可能干扰父容器布局；多行代码请用<pre><code>嵌套
容易被忽略的细节
字体加载失败时，浏览器不会报错，但你会看到代码突然“变胖”或“缩窄”，尤其是 1 和 i 混排时明显失衡。这种问题往往在线上环境才暴露，因为本地开发时恰好装了某款字体，而用户没装。
- 务必在 CSS 中显式声明字体栈，不要依赖浏览器默认
- 中文字体名必须带引号，哪怕看起来“没空格”（如
"Noto Sans CJK"） -
<code>是行内元素，padding 和 background 可以加，但别指望它自动换行或撑开容器高度——那是<pre>的事 - 如果用 Web Font（如从 Google Fonts 引入
Fira Code），记得检查@font-face是否包含font-weight和font-style全集，否则font-weight: bold可能 fallback 到模拟加粗，模糊失真
