scale() 会将文字移入 GPU 合成层，用双线性插值缩放纹理，绕过字体亚像素光栅化，导致边缘发虚；验证可看 Chrome Layers 面板红色图层框。
因为 scale() 把文字从主渲染层拎进了 GPU 合成层，用双线性插值缩放纹理，绕过了字体亚像素光栅化。
scale() 触发了 GPU 纹理缩放，不是“加速”而是“降级”
浏览器对 transform: scale() 的实现，本质是把元素（含文字）先光栅化成位图，再传给 GPU 当纹理拉伸。GPU 默认用双线性滤波做插值——这适合图片，但会抹掉字体边缘的亚像素信息。你看到的“发虚”，不是模糊开关没开，是渲染管线根本没走字体光栅化那条路。
验证方式：打开 Chrome DevTools → Layers 面板，悬停目标文字，如果出现红色图层框，就说明它已脱离主图层，正在被 GPU 插值处理。
- 原生文字（无 transform）：走亚像素抗锯齿（如 macOS 的
-webkit-font-smoothing: subpixel-antialiased） - 加了
scale(1.2)的文字：降级为灰度抗锯齿或直接禁用，边缘变毛 -
scale(1)或scale(2)通常不糊——整数倍缩放不会触发插值
translateZ(0) 不是解药，还可能让事情更糟
translateZ(0) 只是强制新建一个合成层，它不修复像素对齐，也不重走字体光栅化流程。它在 Windows Chrome 110+ 上偶有改善，但前提必须是和 scale() 写在同一行：transform: scale(1.1) translateZ(0)；单独加无效。
立即学习“前端免费学习笔记（深入）”；
- macOS Safari 和多数移动端完全不响应
translateZ(0)对文字清晰度的调整 - 若父容器已设
will-change: transform，再加translateZ(0)可能引发图层嵌套，糊得更明显 - 对长列表、卡片流等密集元素滥用，会快速推高内存占用
真正可控的替代方案：避开 GPU 插值路径
不靠“加速”，而靠“不触发降级”。关键不是怎么缩放，而是让浏览器始终用主图层渲染文字。
- 优先用
font-size+transition: font-size替代scale()—— 性能略低，但文字永远清晰 - 必须用
scale()？确保缩放后尺寸为整数像素，例如font-size: 16px配scale(1.25)（得 20px），避免scale(1.23)（得 19.68px） - 位移类动画，用整数像素值：
transform: translateX(10px)比translateX(50%)安全；若要用百分比，先确认容器宽高是偶数（防 99px × 50% = 49.5px） - 对父容器加
isolation: isolate，防止它意外创建合成层，把子元素文字拖进 GPU 渲染陷阱
最常被忽略的一点：模糊往往不是单个属性的问题，而是 scale() + 小数像素位移 + 父容器 will-change 共同作用的结果。改掉其中任意一个，问题就消失；只调 font-smoothing，等于给漏雨的屋顶刷漆。
