为什么CSS transition的scale会导致文字发虚？

scale() 会将文字移入 GPU 合成层，用双线性插值缩放纹理，绕过字体亚像素光栅化，导致边缘发虚；验证可看 Chrome Layers 面板红色图层框。

因为 scale() 把文字从主渲染层拎进了 GPU 合成层，用双线性插值缩放纹理，绕过了字体亚像素光栅化。

scale() 触发了 GPU 纹理缩放，不是“加速”而是“降级”

浏览器对 transform: scale() 的实现，本质是把元素（含文字）先光栅化成位图，再传给 GPU 当纹理拉伸。GPU 默认用双线性滤波做插值——这适合图片，但会抹掉字体边缘的亚像素信息。你看到的“发虚”，不是模糊开关没开，是渲染管线根本没走字体光栅化那条路。

验证方式：打开 Chrome DevTools → Layers 面板，悬停目标文字，如果出现红色图层框，就说明它已脱离主图层，正在被 GPU 插值处理。

1. 原生文字（无 transform）：走亚像素抗锯齿（如 macOS 的 -webkit-font-smoothing: subpixel-antialiased）
2. 加了 scale(1.2) 的文字：降级为灰度抗锯齿或直接禁用，边缘变毛
3. scale(1) 或 scale(2) 通常不糊——整数倍缩放不会触发插值

translateZ(0) 不是解药，还可能让事情更糟

translateZ(0) 只是强制新建一个合成层，它不修复像素对齐，也不重走字体光栅化流程。它在 Windows Chrome 110+ 上偶有改善，但前提必须是和 scale() 写在同一行：transform: scale(1.1) translateZ(0)；单独加无效。

1. macOS Safari 和多数移动端完全不响应 translateZ(0) 对文字清晰度的调整
2. 若父容器已设 will-change: transform，再加 translateZ(0) 可能引发图层嵌套，糊得更明显
3. 对长列表、卡片流等密集元素滥用，会快速推高内存占用

真正可控的替代方案：避开 GPU 插值路径

不靠“加速”，而靠“不触发降级”。关键不是怎么缩放，而是让浏览器始终用主图层渲染文字。

1. 优先用 font-size + transition: font-size 替代 scale() —— 性能略低，但文字永远清晰
2. 必须用 scale()？确保缩放后尺寸为整数像素，例如 font-size: 16px 配 scale(1.25)（得 20px），避免 scale(1.23)（得 19.68px）
3. 位移类动画，用整数像素值：transform: translateX(10px) 比 translateX(50%) 安全；若要用百分比，先确认容器宽高是偶数（防 99px × 50% = 49.5px）
4. 对父容器加 isolation: isolate，防止它意外创建合成层，把子元素文字拖进 GPU 渲染陷阱

最常被忽略的一点：模糊往往不是单个属性的问题，而是 scale() + 小数像素位移 + 父容器 will-change 共同作用的结果。改掉其中任意一个，问题就消失；只调 font-smoothing，等于给漏雨的屋顶刷漆。