等宽字体必须显式指定，如"SFMono-Regular", "Consolas", "Liberation Mono", Menlo, monospace；monospace仅为通用族名，不可单独依赖，需前置系统等宽字体并真机验证跨平台一致性。
用 font-family 指定等宽字体最直接
浏览器默认的中文字体（如“PingFang SC”“Microsoft YaHei”）和西文字体（如“Helvetica”“Segoe UI”）都不是等宽的，英文字母宽度各不相同（i 窄、m 宽），要实现等宽排版，必须显式指定一个等宽字体族。常见可靠选择包括："SFMono-Regular", "Consolas", "Liberation Mono", "Menlo", "monospace"。
推荐写法是把系统自带的高质量等宽字体放前面，最后兜底 monospace：
body {
font-family: "SFMono-Regular", "Consolas", "Liberation Mono", Menlo, monospace;
}注意：monospace 是通用字体族名，不是具体字体，不同系统渲染效果差异大（Windows 的 Courier New 字形偏老，macOS 的 Menlo 更清晰），不能单独依赖它。
避免 <pre> 标签误用导致意外换行和缩进
<pre> 确实默认等宽且保留空格，但它会把所有空白符（换行、缩进、多个空格）原样渲染，这在普通段落里极易破坏布局。比如写一段代码说明文字，一不小心多敲了两个空格或回车，页面就错位了。
立即学习“前端免费学习笔记（深入）”；
正确做法是：只在真正需要保留格式的场景（如代码块、日志输出）用 <pre>；其他地方统一用 CSS 控制字体，保持语义清晰：
- 用
<code>包裹内联代码（如函数名console.log），它默认有font-family: monospace - 用
<div class="mono-text">或<span class="mono">自定义样式，更可控 - 别为了“看起来像等宽”而给普通
<p>套<pre>—— 语义错、可访问性差、响应式难调
英文内容混排中文时，font-family 要兼顾中西文 fallback
如果网页同时显示英文和中文（比如技术文档里夹着中文说明和英文命令），只写 monospace 会导致中文被强制渲染成等宽但丑陋的字体（如 Windows 下的“Courier New”显示汉字极难读）。
稳妥方案是分层声明字体族，让中英文各自走合适的 fallback 链：
p.code-context {
font-family:
"SFMono-Regular", "Consolas", "Liberation Mono", Menlo, /* 英文优先 */
"PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif; /* 中文兜底 */
}但这样英文部分可能被中文字体覆盖（某些浏览器按字符匹配）。更稳的做法是用 @font-face 或 CSS unicode-range 分离，不过对多数项目过于重——直接用 <code> 包英文片段，正文用常规字体，反而更轻量可靠。
移动端 Safari 对等宽字体的支持有隐藏限制
iOS 15+ 之前，Safari 不支持 "SFMono-Regular"（它是 macOS 独占字体），也不加载远程等宽字体（如 Google Fonts 的 Fira Code）用于 <code> 元素，除非显式设置 font-weight 或触发重绘。
实测有效的兼容写法：
- 始终在等宽样式里加
font-weight: 400（哪怕默认就是） - 避免只用 Web 字体（如
"Fira Code"）而无本地 fallback - 在 iOS 上测试时，重点看
console.log("test")这类内联代码是否真等宽，别只信桌面预览
等宽排版真正的难点不在写法，而在字体链的跨平台一致性——同一段 CSS，在 Chrome、Firefox、Safari、Edge 渲染出的字母间距可能差 0.5px，这对对齐敏感的 CLI 截图或 ASCII 图影响明显。动手前先在目标设备上真机验证。
