-webkit-font-smoothing: antialiased 仅在纯文本、font-weight为400/500、无transform/text-rendering干扰、macOS非Retina屏等严格条件下生效，iOS中完全无效；失效主因是浏览器跳过软件渲染路径。
-webkit-font-smoothing: antialiased 不是“加了就生效”的开关，它在多数常见场景下根本不会起作用——不是你写错了，是浏览器压根没走这条渲染路径。
为什么 -webkit-font-smoothing: antialiased 看不到效果
这个属性只在 WebKit/Blink 内核中参与最终文本光栅化阶段，但前提是：文本必须处于「标准软件渲染路径」。一旦触发以下任一条件，浏览器会自动跳过该属性，回退到系统默认策略：
-
font-weight值为bold、900或与字体文件实际字重不匹配（比如声明font-weight: 600，但加载的却是 Regular 字重的 .woff2） - 元素上存在
transform: scale()、transform: translateZ(0)或backface-visibility: hidden - 父容器启用了
text-rendering: optimizeLegibility—— 它会接管抗锯齿逻辑，覆盖-webkit-font-smoothing - 在 iOS Safari 或 WebView 中：该属性被完全忽略，无论怎么写都无效
哪些地方能安全生效
只有满足「纯文本 + 默认渲染上下文 + 明确选择器权重」时，-webkit-font-smoothing: antialiased 才可能真正介入：
- 仅对
font-weight为normal（400）或500的文本有效；中文字体建议搭配font-weight: 400和真实支持该字重的字体文件（如"PingFang SC"而非仅"Helvetica"） - 必须写在具体容器上，例如
.header-title、.nav-link，而不是全局body—— 否则极易被框架样式或 CSS-in-JS 动态规则覆盖 - 需确保没有更高优先级的同名声明（比如 Bootstrap 的
.btn类里已设了-webkit-font-smoothing: subpixel-antialiased） - 在 macOS 上，它只影响非 Retina 屏或缩放非 100% 时的灰阶过渡行为；Retina 屏本身做的是像素级双线性插值，
antialiased实际只是微调 hinting 强度
替代方案比硬调这个属性更可靠
与其反复调试 -webkit-font-smoothing，不如直击模糊根源：
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的 Fonts 面板确认真实渲染的字体和字重，而非依赖
font-family声明顺序 - 把
font-display: swap换成font-display: optional或预加载<link rel="preload" as="font">，避免 FOUT 导致的布局重排+重绘模糊 - 中文字体栈必须前置系统字体：例如
font-family: "HarmonyOS Sans SC", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif；漏掉任一环，fallback 可能落到无 hinting 的位图字体 - 禁用硬件加速相关 hack：
transform: translateZ(0)在旧版 Safari 和 Electron（v25+）中会直接关闭子像素渲染，且无视-webkit-font-smoothing
真正难调的从来不是这个属性本身，而是它背后那一整套字体加载、fallback、hinting、设备像素比和渲染管线的耦合逻辑。加一行 antialiased 解不了问题，但看清它在哪失效、为什么被绕过，往往就离修复只剩一步。
