-webkit-font-smoothing 非标准属性，仅在部分 WebKit 浏览器生效，iOS Safari 完全忽略；真正可控的是 font-display、viewport 设置及 text-rendering 等标准属性。
-webkit-font-smoothing 不是标准属性，也不能“全局优化字体渲染”——它只在 WebKit 内核浏览器（Chrome、Safari、新版 Edge）中生效，且对 iOS Safari 完全无效。别指望加一句 font-smoothing: antialiased 就能解决问题，那行代码根本不会被解析。
为什么 -webkit-font-smoothing 在 iOS 上不起作用
iOS 系统级禁用了网页对字体渲染的干预，无论你设 -webkit-font-smoothing: antialiased 还是 subpixel-antialiased，Safari 和所有基于 WKWebView 的 App（包括微信内置浏览器）都会直接忽略。这不是 bug，是 Apple 的设计决策。
常见错误现象：
– 开发者在 macOS Safari 调试时看到字体变细变锐利，上线后真机测试发现毫无变化
– 误以为是 CSS 未加载或选择器权重不够，反复加 !important 或提升层级，徒劳无功
- 真正可控的入口是
font-display：用font-display: block避免回退字体模糊，尤其对标题类文本 - 检查
<meta name="viewport">是否漏了maximum-scale=1.0—— 缺失会导致页面被意外缩放，物理像素错位，字体自然发虚 - 不要在 iOS 相关样式里写
-webkit-font-smoothing，纯属冗余
Chrome / macOS Safari 下怎么安全使用 -webkit-font-smoothing
这个属性只影响已加载完成的字体如何渲染边缘，和字体是否加载无关。它的三个合法值行为差异明显：
立即学习“前端免费学习笔记（深入）”；
-
auto：尊重系统设置，macOS 默认走 subpixel，但高分屏下可能过重；Windows Chrome 实际忽略该属性 -
antialiased：强制灰度抗锯齿，字体更纤细锐利，在 Retina 屏上观感接近系统原生；但小字号（≤14px）易显模糊 -
subpixel-antialiased：启用亚像素渲染，字形更饱满，适合 Windows 风格偏好，但在 macOS 上可能和系统字体风格冲突
推荐写法（仅限桌面端明确需要微调的容器）：
h1, .header-title, .nav-link {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
注意：-moz-osx-font-smoothing: grayscale 是 Firefox 在 macOS 上的对应属性，值只能是 grayscale 或 auto，不能填 antialiased。
text-rendering 和 font-smoothing 能一起用吗
可以，但别混为一谈：text-rendering 是通用标准属性，控制浏览器在速度、可读性、几何精度之间的权衡；-webkit-font-smoothing 是私有渲染细节开关。
-
text-rendering: optimizeLegibility会启用连字、字距调整等高级排版，间接提升小字号可读性，但它不改变抗锯齿方式 - 两者叠加时，
optimizeLegibility可能放大antialiased带来的“偏细”效果，需实测字号与字重匹配度 - 避免在整站
body上设text-rendering: optimizeLegibility，长文本列表页可能出现轻微性能抖动
硬件加速 hack 对字体渲染的影响
给元素加 transform: translateZ(0) 曾被当作“修复字体模糊”的万能药，但现在要谨慎：
- 在旧版 Safari（≤15.x）中，该声明会直接让
-webkit-font-smoothing失效 - 现代 Chrome 中基本无影响，但会触发额外图层合成，对滚动性能敏感的页面可能得不偿失
- 如果你发现加了
translateZ(0)后字体反而更糊，先删掉它，再检查font-display和 viewport 设置
真正容易被忽略的点是：字体渲染不是单一样式能决定的，它是操作系统策略、浏览器内核、屏幕物理特性、字体文件 hinting 数据共同作用的结果。CSS 层面能做的，只是在有限范围内做适配，而不是“修复”。
