-webkit-font-smoothing 在 Windows 上基本无效，Chrome 120+/Safari 17+ 已实质弃用，其失效源于底层渲染管线差异：macOS 用 Core Text 子像素抗锯齿，Windows 用 DirectWrite 灰度抗锯齿，CSS 属性无法跨系统统一控制。
-webkit-font-smoothing 在 macOS 和 Windows 上显示不一致，根本原因不是你写错了，而是它在 Windows 上基本不起作用，且在 Chrome 120+ 和 Safari 17+ 中已被浏览器实质弃用。
-webkit-font-smoothing 在 Chrome/Firefox/Safari 中已失效
- Chrome 从 v115 开始逐步忽略该属性，v120+ 多数渲染路径直接跳过解析
- Firefox 从未支持
-webkit-font-smoothing，也未提供等效替代（font-smooth早在 CSS 规范中被标记为废弃） - Safari 17+（macOS Sequoia）对
-webkit-font-smoothing的响应更弱，尤其当文本有font-weight: bold或transform时，会自动回退到系统默认策略
常见错误现象：
- DevTools 的 Styles 面板里能看到该声明，但 Computed 面板中值为
unset或空白 - 加了
-webkit-font-smoothing: antialiased后，macOS 字变细发虚，Windows 完全无变化 - 全局设在
body上，却被框架组件（如 Ant Design 的.ant-typography）或 CSS-in-JS 的高权重规则覆盖
为什么 macOS 看起来“柔”、Windows 看起来“硬”
这不是 CSS 能统一的事——底层是两套不可桥接的渲染管线：
- macOS 使用 Core Text + subpixel antialiasing（子像素抗锯齿），边缘带 RGB 微色差，视觉更饱满，尤其利于 Retina 屏
- Windows 使用 DirectWrite，默认 grayscale 抗锯齿，不依赖子像素，边缘无色但更锐利、笔画更细
-webkit-font-smoothing 本质只是向 WebKit/Blink 引擎“提个建议”，而引擎最终是否采纳、如何映射到系统 API，完全由操作系统决定。你在 CSS 里写的那行，连渲染管线的门都没摸到。
替代方案：用标准属性组合收口可读性
与其卡在已失效的私有属性上，不如转向稳定、跨浏览器支持的控制点：
- 用
text-rendering: optimizeLegibility激活字距调整与连字（对英文/数字明显，中文影响小但无害） - 配合
font-feature-settings: "liga"锁定字形稳定性（注意：对中文字体基本无效，别白费劲） - 对需要强视觉重量的标题，优先靠
font-weight显式匹配字体真实字重（比如用"PingFang SC", "Microsoft YaHei"而非泛泛的sans-serif） - 避免
transform: scale()、backface-visibility: hidden等触发合成层的操作——它们会绕过字体抗锯齿逻辑，反而让文字边缘半透明、模糊
真正起效的最小实践，是放弃“平滑化”执念，转而约束变量：选对字体栈、禁用缩放干扰、用无单位 line-height、显式声明 font-display: swap。
最容易被忽略的一点：字体渲染差异，80% 来自 font-weight 实际映射失败——你写 font-weight: 600，但 Windows 上 "Microsoft YaHei" 根本没有 600 字重，浏览器就近匹配 400 或 700；而 macOS 的 PingFang SC 却有完整支持。这种底层断层，-webkit-font-smoothing 一丁点都管不了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
