中英文混排时letter-spacing对中文无效，因中文字体将汉字视为不可分割单元；推荐用薄空格 手动分隔、font-feature-settings启用lnum/tnum/pwid、text-rendering:optimizeLegibility触发自动字距优化。
中英文混排时 letter-spacing 为什么失效
直接给中英文混合文本加 letter-spacing，往往只对英文字母起作用，中文字符几乎没变化——因为浏览器对中文字体默认不响应该属性，尤其在 Chrome 和 Safari 中更明显。这不是 bug，而是字体渲染机制决定的：letter-spacing 作用于字符（glyph）之间的“字距”，而中文字体通常把每个汉字视为一个不可分割的渲染单元，不参与字母级间距调整。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别依赖
letter-spacing统一调控中英文混排；它在中文语境下行为不稳定，且不同字体（如"PingFang SC"vs"Microsoft YaHei"）响应差异大 - 若必须用，仅对纯英文片段包裹
<span class="eng"></span>单独设置，避免污染中文段落 - 注意：设置负值（如
letter-spacing: -0.05em）可能让英文挤在一起，但中文完全无感，反而造成视觉割裂
用 font-feature-settings 启用 OpenType 的字距优化
现代中文字体（如 "HarmonyOS Sans"、"OPPO Sans"、部分版本的 "Noto Sans CJK"）内置了 OpenType 特性，其中 liga（连字）和 clig（上下文连字）对中英文衔接有帮助，但真正影响字距的是 pwid（比例宽度）和 halt（半宽标点）。不过更直接有效的是启用 lnum（线性数字）+ tnum（表格数字），让英文数字与汉字基线对齐，减少“浮空感”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在 body 或全局文本选择器中加：
font-feature-settings: "lnum", "tnum", "pwid";
- 优先选用支持这些特性的字体，可通过
@font-face加载 WebFont 验证（比如 Google Fonts 的Noto Sans CJKv3.000+） - 不要对所有元素盲目开启
"kern"（字偶距）——它对中文字体基本无效，还可能拖慢渲染
用 text-rendering: optimizeLegibility 触发浏览器自动字距微调
这个 CSS 属性会强制浏览器启用更精细的字形处理逻辑，包括对中英文交界处的字距重算（尤其在 Safari 和较新 Chrome 中）。它不是万能的，但比手动调 letter-spacing 更可靠。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 只对正文类容器启用，例如：
.article-content { text-rendering: optimizeLegibility; } - 避免在按钮、标题等短文本上使用——它会轻微增加渲染开销，且短文本无需复杂字距优化
- 注意兼容性：
optimizeLegibility在 Firefox 中被忽略，在旧版 Edge 中不支持，但不影响布局，可安全降级
真正可控的方式：用 （薄空格）手动插入分隔
当需要精确控制某处中英文衔接（比如「iOS 18」、「Python 3.12」），最稳妥的做法是人工插入 Unicode 薄空格 ，它宽度约为 1/5 em，比普通空格窄，又比零宽空格（）有明确占位，浏览器普遍支持且不会折行。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 写成：
iPhone 16、Vue 3，而不是iPhone 16（普通空格太宽）或iPhone16（粘连） - 配合 CSS 限制：
word-break: keep-all; white-space: normal;
防止薄空格被当作断行点 - 自动化场景可用 JS 替换（如正则
/([a-zA-Z])(\d+)/g → '$1 $2'），但需避开代码块、<pre>等预格式化内容
中英文混排的字距问题本质不是样式失控，而是字体设计 + 渲染引擎 + 标准演进三者未完全对齐。手动插薄空格看着原始，却是目前最可控的落地方式；其他方案要么依赖字体支持，要么受制于浏览器实现细节。别指望一行 CSS 解决全部，关键位置宁可多敲几个字符，也比后期被设计师反复打回强。
