同一句话在不同电脑、不同浏览器、不同导出方式里会忽然变得发虚、发胖、发细，很多人会下意识把问题归结为“感觉不对”。但更常见的原因是：字体回退、字重映射、抗锯齿算法差异、像素对齐与子像素渲染的组合，让看似相同的文本在不同环境里变成了另一种文字形态。只要把“文字显示”拆成几个可检查的环节，你就能稳定复现并定位问题，而不是靠反复换字体碰运气。
先从最容易被忽略的一点开始：你以为自己在用某个字体，其实系统在用它的替身。许多字体家族的命名并不统一，尤其在 Windows、macOS、Android 和各类网页环境里，同名的 Regular、Book、Normal 可能并不是同一字重。更麻烦的是，当某个字重缺失时，系统会进行字重“合成”，把 400 拉向 500，或把 300 拉向 200，结果就是文字看起来比预期更粗或更细。
很多设计稿里会写“正文 14px 400，标题 20px 600”。在字体完备时没问题，但一旦进入缺字重的环境，系统会用最近的可用字重代替。比如某些中文字体没有 600，只有 500 和 700，最终显示会跳到 700，标题瞬间变得“喊叫”。如果你在界面设计中大量依赖字重层级，请把字重选择改成“可用字重集合”思维：先确定目标平台实际可用的字重，再决定层级，而不是先画层级再祈祷平台能支持。
修复思路也很直接：让字重层级由两段变成三段。正文不要压在最细端，标题不要压在最粗端，中间用字号、行高、颜色对比来补强。这样即使字重发生替换，视觉也不会崩。对中文而言，字号与行高的稳定性常常比字重更可靠。
文字“紧”或“散”的观感，往往不来自 letter-spacing 一个参数，而是字号、行高、段落间距共同产生的密度。尤其中文在小字号时，单字结构复杂，细节会挤在一起。此时如果行高过小，字形的上下部件会相互干扰，呈现出一种“糊成一团”的感觉。很多人会去调字距，结果越调越怪。更好的做法是先把行高抬到一个能让字形呼吸的范围，再微调字距。
经验上，小字号正文的行高应当给到足够的“安全边界”，让每行之间有明显但不松散的留白；标题的行高可以更紧，但不要紧到让上下两行的“口、日、目”等结构产生压迫感。你会发现，只要密度对了，字距几乎不需要大幅调整。
文本清不清晰，和它是否落在像素网格上关系很大。尤其在导出位图、做小图标、或在某些渲染管线里，半像素位置会导致抗锯齿把边缘“抹”得更软，文字显得发虚。你会看到同样的 12px 文本，移动 1px 就变清晰了。这不是玄学，是栅格化的结果。
修复时不要只盯着字体本身，而要看布局是否产生了 0.5px 的位移：容器宽高、缩放比例、导出倍率、甚至浏览器的页面缩放都可能引入非整数像素。让关键文本所在的容器在最终渲染环境中落在整数像素上，通常比换十个字体更有效。
macOS 的文本渲染更偏向保持字形轮廓，Windows 的 ClearType 更偏向提高边缘对比。你在 Mac 上觉得“细且高级”的字，在 Windows 上可能变得“发灰”；你在 Windows 上觉得“清楚利落”的字，在 Mac 上可能变得“略软”。这不是优劣，而是策略不同。设计稿评审时如果只在单一系统上看，会把渲染差异误判为设计差异。
解决方式是建立跨系统的预览流程：至少在两种渲染策略下看一遍关键页面，尤其是小字号、细字重、浅色文字和反白文字。把这些高风险组合提前规避，你会省下大量返工。
当你再次遇到“看起来不对劲”的文本，不要立刻改视觉，而是按顺序确认：字体是否回退、字重是否被替换、字号与行高的密度是否合理、是否存在半像素位移、渲染环境是否变化。这个顺序的好处是，从最容易发生且影响最大的因素开始，逐步缩小范围。你会发现大多数问题在前三步就能定位。
最后再提醒一个经常被忽略的点：导出到图片或截图再放回界面，会让文字从矢量变成位图，渲染逻辑完全不同。不要用截图文字去评判真实文本的效果。要评判，就在最终环境里评判。
如果文字“发胖”，先看字重是否被替换到更粗的档位，其次看是否发生字体回退；如果文字“发灰”，先看渲染策略差异与页面缩放，再检查是否把文字做成位图后被压缩；如果文字“发虚”，优先排查半像素位移与导出倍率；如果文字“忽大忽小”，重点看字号体系是否在不同容器里被二次缩放（例如嵌套缩放、浏览器缩放、导出缩放叠加）。把现象和原因做一对一映射，比盲目换字体有效得多。
在交付文档或标注里，不要只写“字体=某某”，建议补上可用字重范围、字号与行高、是否允许系统回退，以及关键页面需要在哪些系统/浏览器上验收。对 web 项目，明确资源导出是否转换为 sRGB、页面缩放是否允许、以及截图仅用于参考而非验收。把这些条件写清楚，能把“看起来不对劲”的争议从审美问题变成可复现的问题。
