-webkit-font-smoothing在WebKit内核（如Safari）中并非开关抗锯齿，而是控制子像素渲染策略：macOS下对非粗体文本生效，antialiased禁用子像素转灰度、subpixel-antialiased为默认启用RGB子像素，none极少使用；Safari 17+对antialiased部分尺寸会回退灰度致发虚。
font-smoothing 在 WebKit 内核（Safari）里到底起什么作用
-webkit-font-smoothing 并不是开启/关闭抗锯齿的开关，而是控制子像素渲染（subpixel rendering）的策略。它只在 macOS 上生效，且仅对非 font-weight: bold 的文本起作用。常见值有：antialiased（禁用子像素，仅灰度抗锯齿）、subpixel-antialiased（默认，启用 RGB 子像素渲染）、none（几乎不用，效果差）。注意：Safari 17+ 对 antialiased 的行为做了调整，部分字体尺寸下会回退到灰度模式，视觉上反而更“虚”。
Firefox 和 Chrome（Blink）为什么无视 -webkit-font-smoothing
Firefox 完全不支持 -webkit-font-smoothing，它的字体平滑由系统级渲染器决定（macOS 用 Core Text，Linux 用 FreeType 配置，Windows 用 GDI/Uniscribe）。Chrome（Blink）在 macOS 上默认跟随系统设置，但可通过 font-smooth（已废弃）或 text-rendering 间接影响：text-rendering: optimizeLegibility 可能触发 OpenType 特性（如 ligatures），但不改变抗锯齿方式；text-rendering: geometricPrecision 会禁用字距微调，有时让文字显得更“硬”。真正能跨浏览器轻微干预的只有 font-optical-sizing: auto（需字体支持）和 font-variation-settings 中的 'wdth' 或 'wght' 调整。
Windows 下 ClearType 关键参数如何被网页绕过
Windows 的 ClearType 是系统级服务，网页无法直接开关，但可通过 CSS 触发不同渲染路径：
• 强制使用 GDI 渲染（模糊但兼容）：-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=100)";（IE 旧语法，现代已无效）
• 现代做法是避免触发 DirectWrite 的“cleartype disabled”状态——比如不要给 <body> 设 transform: translateZ(0) 或 will-change: transform，否则某些旧版 Edge/Chrome 会降级为 GDI 渲染，字体变软、发虚
• 更可靠的是用 font-feature-settings: "liga" on, "calt" on; 配合支持 OpenType 的字体（如 Inter、IBM Plex），让渲染器优先走高级字形替换路径，间接提升清晰度
移动端 iOS 和 Android 的字体渲染差异根源
iOS WebKit 强制使用 subpixel rendering（即使设 -webkit-font-smoothing: antialiased），且对 font-size < 16px 自动启用字体放大（text size adjustment），导致实际渲染尺寸不可控；Android Chrome（Blink）则依赖系统字体栈和 Skia 渲染器，在 Android 12+ 上默认启用 subpixel，但若页面声明了 viewport 的 user-scalable=no 或 maximum-scale=1，可能触发软件渲染路径，丢失 subpixel 效果。真实项目中，最稳妥的做法是：固定 font-size ≥ 16px，用 line-height 控制行距，避免 rem 在高 DPR 屏幕下被缩放抖动，同时对图标文字用 font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto; 显式指定系统字体。
立即学习“前端免费学习笔记（深入）”；
实际调试时，别盯着“是否开了 font-smoothing”，先确认当前平台、DPR、字体加载状态、是否触发了合成层（compositing layer）——这些比一个 CSS 属性的影响大得多。
