-webkit-font-smoothing是webkit私有属性，仅macos下chrome/safari有效，需带-webkit-前缀，取值仅auto/antialiased/subpixel-antialiased，不适用于firefox或windows chrome，且不能解决cleartype问题。
font-smoothing在Chrome和Safari里为什么没生效
直接写 font-smoothing 不起作用，因为标准CSS里根本没这个属性——它是浏览器私有前缀的产物，必须用 -webkit-font-smoothing，且只对Webkit内核（Chrome、Safari、Edge新版）有效，Firefox完全无视。
常见错误是漏掉 -webkit- 前缀，或者误以为它能控制所有字体渲染细节。实际上它只影响抗锯齿策略，不改变字重、字宽或hinting行为。
- 仅适用于 macOS 系统下的 Webkit 浏览器（Windows 下 Chrome 忽略该属性）
- 必须配合
font-family中包含系统字体（如"-apple-system"或"Segoe UI"）才容易观察到差异 - 设为
none时可能让文字发虚，尤其在非Retina屏上；设为antialiased会削弱对比度，小字号易看不清
-webkit-font-smoothing 的三个取值怎么选
只有三个合法值：auto、antialiased、subpixel-antialiased。别信网上写的 smooth 或 light，那些是无效值，会被浏览器静默丢弃。
auto 是默认行为，由系统决定；antialiased 关闭子像素渲染，适合深色背景+浅色文字；subpixel-antialiased 是macOS默认，利用LCD子像素提升清晰度，但在某些缩放比例下反而出现彩边。
- 深色主题下优先试
antialiased，避免白色文字边缘泛灰 - 如果用户反馈文字“发虚”或“太细”，退回
subpixel-antialiased - 不要全局设置，只加在明确需要微调的文本容器上，比如
.header-title或.nav-link
和 font-display / font-feature-settings 冲突吗
不冲突，但顺序和层级会影响最终效果。如果同时用了 font-display: swap 和 -webkit-font-smoothing，前者控制字体加载时机，后者只在字体实际渲染时起作用——也就是说，swap 加载的自定义字体，其平滑效果仍受该属性约束。
但注意：font-feature-settings 控制字形替换（如连字、小型大写字母），和渲染平滑无关；两者可以共存，但别指望它们互相增强。
- 自定义字体（WOFF2）是否启用平滑，取决于浏览器是否把它识别为“可平滑字体”，通常系统字体更稳定
- 如果用了
text-rendering: optimizeLegibility，它可能覆盖部分平滑行为，建议二者不同时启用 - 开启
transform: translateZ(0)强制硬件加速后，某些旧版 Safari 会忽略-webkit-font-smoothing
替代方案：为什么现在更推荐使用 text-rendering
因为 -webkit-font-smoothing 越来越不可靠：Chrome 115+ 对它的支持开始松动，macOS Ventura 后部分场景自动降级，而且它无法解决 Windows 下 ClearType 渲染问题。
更务实的做法是用标准属性 text-rendering 配合字体栈设计。它虽不叫“平滑”，但通过提示浏览器优先考虑可读性（optimizeLegibility）或速度（optimizeSpeed），间接影响渲染质量。
-
text-rendering: optimizeLegibility在 Safari 和 Chrome 中会自动启用更精细的字距和抗锯齿，比硬塞-webkit-font-smoothing更稳妥 - 搭配字体栈如
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif，能让不同系统各取所长 - 真正难搞的是中文混合排版——这时候得靠
font-smooth（已废弃）或干脆放弃干预，依赖系统原生渲染
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
