-webkit-font-smoothing在小众安卓机型上基本无效，因其底层图形栈禁用子像素抗锯齿、webview陈旧或深度定制，导致该属性被忽略；字体发虚主因是渲染干扰（如transform、filter）或字体栈配置不当，而非抗锯齿开关。
-webkit-font-smoothing 在小众安卓机型上基本无效，别白费力气全局加
它不是“移动端字体平滑开关”，而是 WebKit 内核在特定系统上控制子像素渲染的私有属性。小众安卓厂商（如传音、中兴、酷派等）的定制系统普遍禁用子像素抗锯齿，且 WebView 渲染栈深度定制，-webkit-font-smoothing 的 subpixel-antialiased 和 antialiased 值多数被直接忽略，none 已废弃、部分系统会当没写。
为什么在小众安卓机上加了 -webkit-font-smoothing 还是发虚
根本原因不在抗锯齿开关，而在底层图形栈：这些机型往往使用降频 GPU、阉割 Skia 后端、或强制启用灰度抗锯齿（grayscale AA）以省电；WebView 版本陈旧（如基于 Android 5.1 的 Chromium 44），根本不解析该属性；有些甚至把文字栅格化逻辑移到内核态，CSS 完全无权干预。
常见错误现象包括：
- 加了
-webkit-font-smoothing: antialiased后文字更发灰、笔画变细、小字号（≤13px）出现断裂 - 全局设置在
body或* {}上，导致输入框、系统按钮文字可读性下降 - 配合
transform: scale(0.99)或will-change: transform使用，反而触发 Chrome for Android 的降采样 bug，模糊加剧
真正该检查的渲染干扰项（比 font-smoothing 优先级高得多）
字体发虚大概率是 CSS 触发了非预期的合成层或栅格化策略，而非抗锯齿本身。优先排查以下几类操作：
- 移除所有
transform: scale()、transform: translateZ(0)、will-change: transform—— 它们在低端安卓 WebView 中极易导致字体强制缩放再放大，失真严重 - 检查是否误设
backface-visibility: hidden或perspective，某些定制 WebView 会因此把文本丢进低精度 GPU 层 - 确认未对文本容器使用
filter: opacity(0.99)类伪透明，这会让渲染管线放弃子像素优化 - 若用了自定义字体，验证
@font-face是否声明了font-display: swap；加载期间 fallback 字体若被错误抗锯齿，也会造成临时发虚
针对小众机型的务实处理建议
没有银弹，但有可落地的收敛策略：
- 放弃用 UA 判断机型后差异化设置
-webkit-font-smoothing—— 小众机型 UA 差异大、行为不可预测，matchMedia('(prefers-reduced-motion)')也帮不上忙 - 只对明确使用了自定义中文字体的容器（如
.title-custom）单独加-webkit-font-smoothing: antialiased !important，且仅限 iOS Safari 真机测试有效时才保留；安卓端一律不加 - 确保
font-family栈以系统字体开头：font-family: -apple-system, BlinkMacSystemFont, "Roboto", "Noto Sans CJK SC", sans-serif，比任何平滑 hack 都管用 - 小字号（12–14px）优先用
font-weight: 450或500替代normal，避免 Windows/Android 下 fallback 字体 hinting 错乱
最易被忽略的一点：所谓“发虚”，80% 情况下是设计稿用了非系统字体 + 小字号 + 未配光学尺寸，而不是渲染属性没调对。别在 CSS 抗锯齿上死磕，先换 font-family、调 font-size、删 transform。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
