font-kerning仅开关字体内置字偶距，无法实现高级微调；编辑器中真正可控的是letter-spacing，需结合字体族、中英分离、单位选择与继承清理来精细化调整。
font-kerning 不是用来“实现高级字距微调”的工具，它只是开关——开或关字体自带的字偶距（kerning）数据。真正在编辑器里做“高级微调”，得靠别的手段。
为什么 font-kerning 在 HTML 编辑器里基本没用
编辑器场景下，用户输入的是动态文本，字体可能随时切换、字号缩放、语言混排，而 font-kerning 依赖字体文件内置的 'kern' 表或 GPOS 表——这些表只覆盖有限字符对（如 "AV"、"To"、"Wa"），且浏览器是否启用还受字号影响（比如 Chrome 对 ≤12px 文本默认禁用 kerning）。你设 font-kerning: normal，不代表所有相邻汉字/标点/数字都会被“智能收紧”；设 font-kerning: auto，也不代表它会像 Adobe 那样分析字形轮廓做光学调整。
- 它不响应用户输入内容变化：输入 “T.” 或 “「あ」” 时，不会自动触发特殊间距逻辑
- 它无法覆盖 fallback 字体行为：WebFont 加载中显示 SimSun，SimSun 没 kerning 表 →
font-kerning形同虚设 - 它不能和 JavaScript 联动：没有 API 可读取当前字符对的 kerning 值，也没法 runtime 注入新字距规则
真正能控制编辑器内字距的只有 letter-spacing
这是唯一可编程、可响应、可精细化控制的属性。但必须避开常见误用：
- 别在
contenteditable容器上直接设全局letter-spacing—— 它会继承到所有子节点，导致<strong></strong>、<em></em>、<code>等内联元素也变松散，需显式重置：strong, em, code { letter-spacing: normal; } - 移动端小字号（≤14px）慎用
px：1px 在 Retina 屏可能渲染为 0.5px 并被舍入丢弃，改用em（如letter-spacing: 0.02em）更稳 - 中英文混排必须分治：同一值对汉字太紧、对英文太松，推荐包裹语义标签：
<span lang="en">NEW</span>+[lang="en"] { letter-spacing: 0.05em; } - 避免负值滥用：中文字符本身笔画密集，
letter-spacing: -0.1em极易造成粘连，尤其在非等宽字体下，肉眼难判是否重叠
想模拟“光学字距”？只能妥协实现
CSS 没有 font-optical-kerning 这种属性，所谓“高级微调”在浏览器里本质是权衡：
立即学习“前端免费学习笔记（深入）”；
- 用
text-rendering: optimizeLegibility可间接触发部分浏览器启用更激进的 kerning 和 ligature，但它不是标准，Safari 支持好，Firefox 忽略，且会轻微拖慢渲染 - 对关键标题或按钮，可预设几组
letter-spacing值并按字体族切换：font-family: "Inter", sans-serif;→letter-spacing: 0.03em；font-family: "Noto Sans CJK SC", sans-serif;→letter-spacing: 0.01em - 若编辑器支持富文本，可把字距逻辑下沉到内容层：用户选中某段文字 → 后端存一个
data-letter-spacing="0.04em"属性 → 渲染时注入内联样式，绕过 CSS 继承污染
别碰 font-kerning 的三个典型错误场景
很多人以为开了它就能“让文字更专业”，结果反而埋坑：
- 给
<input type="text">设font-kerning: normal—— Safari/iOS 完全无视，Chrome 仅部分生效，且表单控件本身渲染路径和普通文本不同 - 在 flex 容器里对子元素设
font-kerning: none想“统一间距”，却忘了这会让 “AV”、“To” 看起来突兀松散，破坏阅读节奏 - 用它替代
text-overflow: ellipsis实现截断 ——font-kerning和文本溢出控制毫无关系，纯属概念混淆
真正需要关注的，是字体加载状态、单位选择、继承链清理和中英分离策略。字距问题从来不是单个 CSS 属性能解决的，它是字体、尺寸、设备、内容共同作用的结果。
