字体文件里存的是轮廓（曲线/点阵信息），真正呈现在屏幕上的，是操作系统与渲染引擎把轮廓“栅格化”后的像素结果。不同系统（Windows/macOS/iOS/Android）、不同浏览器、甚至同一系统的不同设置，都会走不同的渲染管线，所以同一款字体看起来不一样是常态。
最常见的差异包括：字形边缘清晰度（锐/糊）、笔画粗细、字腔开口大小、细节（尖角/弧度）是否被吞掉、行高与基线位置、字间距与字偶距（kerning）是否生效。
在低分辨率或小字号场景，曲线会被迫贴合像素网格。如果不做引导，细笔画可能断裂、发虚或忽粗忽细。Hinting（字形微调指令）会告诉渲染器：哪些笔画该更贴近像素边界、哪些地方要保持笔画厚度一致，从而提升可读性。
不同平台对 hinting 的执行策略差异很大：有的平台更追求“像素级清晰”，有的平台更追求“几何忠实”。同一字体在 Windows 上可能更锐利、在 macOS 上更柔和，本质就是策略取舍。
抗锯齿通过灰阶过渡让边缘更平滑，但会带来“更糊”的观感；子像素渲染利用 RGB 子像素结构提升横向分辨率，让文字更锐，但也可能在高对比背景下出现轻微彩边。部分系统/设备会禁用或替换子像素方案，这会直接改变文字的锐利程度。
设计稿里一眼看上去“更细、更干净”的标题，落地到不同设备后可能出现“变粗、发灰、发虚”，多数与此有关。
两台设备都写着 14px，并不等于视觉尺寸相同。高 DPI 屏幕会把更多像素塞进同样的物理长度里，因此同一字号的边缘更顺、更细节；而在低 DPI 或系统缩放（125%/150%）时，栅格化会发生在不同的比例上，导致笔画对齐方式改变，肉眼就会觉得“同一字体变了”。
如果你在 Windows 125% 缩放下觉得文字“发虚”，在 100% 下又变清晰，这是典型现象。
很多界面通过数值字重（100-900）调用字体，但不同平台对字重映射不一致，字体文件里也可能缺少某些字重，于是系统会用“最近的字重”替代。变量字体（Variable Font）更复杂：同一个文件可以连续变化字重与字宽，如果渲染器或调用方式不同，实际落地的权重位置也可能有细微偏差。
结果就是：同一套 CSS/同一份设计规范，在某些设备上标题更粗、正文更细，甚至字宽略有变化。
最容易被忽略的一点：当字体缺字（例如某些符号、罕见汉字、数字风格不全），系统会自动回退到另一款字体补齐。你会看到同一行里某些字符突然“变形”“变粗”“不对齐”，这往往不是 kerning 失效，而是回退发生了。
排查时建议把文本复制到纯文本环境，观察是否某些字符触发了替换；前端可以通过开发者工具检查实际使用的字体族。
统一测试场景：至少覆盖 2 套系统（Windows + macOS）与 2 档屏幕（普通屏 + 高 DPI），并在常见缩放（100%/125%/150%）下看标题与正文。
给字号留冗余：小字号最受 hinting 与栅格化影响，正文尽量避免过细字重；标题若必须纤细，优先在高对比背景上做可读性验证。
明确字体回退策略：写清楚字体族顺序（主字体/备用字体/系统字体），并确认数字、标点、英文是否会触发回退。
控制字重调用：对关键组件指定明确的字重档位（例如 400/600/700），避免“介于两档之间”的模糊调用；变量字体要确认浏览器支持与调用方式。
截图对比而不是凭感觉：同一段文本在不同设备做并排截图，重点看：x-height、笔画厚度、字腔开口、行高与基线。这样能快速判断是渲染策略差异，还是确实调用了不同字体。
字体“看起来不一样”，通常不是设计错误，而是渲染策略与设备条件的自然结果。把它当成需要管理的变量：提前测试、明确回退、控制字重与字号，就能把差异压到可接受范围。
