will-change: transform 不能修复 transform 导致的模糊，因其仅触发图层提升而不解决像素对齐、坐标精度或字体光栅化问题；真正有效需配合 js 动态设置/清除 + 整数 transform 值，或改用 translatez(0)、避免 gpu 合成等方案。
will-change: transform 不能直接修复 transform 导致的盒模型模糊，它只是提前声明“这个元素要动了”，不解决像素对齐或抗锯齿降级问题。
为什么加了 will-change 还是模糊？
浏览器把 will-change: transform 当作图层提升信号，但不会重置坐标精度、不强制整数像素对齐、也不干预字体光栅化策略。实际中常见现象包括：
- 动画开始前加了
will-change，但transform: rotate(87.3deg)仍导致文字边缘插值发虚 - 移动端 Safari 上完全没效果，甚至更糊
- 长列表里每个 item 都加，DevTools Layers 面板显示超 50 层，内存飙升、滚动卡顿
真正起效的组合写法
必须配合三个条件才能让 will-change 发挥作用：
- 只在动画触发前一刻用 JS 设置：
el.style.willChange = 'transform' - 动画结束后立刻清除：
el.style.willChange = 'auto'（监听animationend或transitionend） - transform 值必须是整数角度或整数像素位移，例如
rotate(90deg)、translateX(12px)；动态计算时用Math.round(angle)截断小数
比 will-change 更轻量且可控的替代方案
多数场景下，transform: translateZ(0) 比 will-change 更直接有效：
- 它强制创建新合成层并重走光栅化流程，常能恢复亚像素渲染质量
- 无需 JS 管理生命周期，无内存泄漏风险
- 但要注意：不要滥用在高密度列表项上，否则图层数爆炸；可改用
transform: translate(0, 0)替代
绕开 GPU 渲染管线才是治本之策
只要文字被当作纹理上传 GPU，就逃不开插值模糊。最稳的做法是让它不进 GPU 管线：
- 确保容器宽高为偶数 px，配合
transform-origin: 50% 50%，让旋转中心落在像素中心 - 避免
rotate()和scale()混用——缩放会放大坐标误差 - 移动端 Safari 必须叠加
-webkit-font-smoothing: subpixel-antialiased，但仅当 transform 值为整数时才生效 - 终极手段：用
linear-gradient+::before模拟倾斜，彻底避开transform
容易被忽略的一点是：模糊不是 bug，而是 GPU 合成层的默认行为。你看到的“变清晰”，有时只是帧率提升带来的错觉，或者 Chrome 某个版本偶然回退到高质量光栅化——这种不可靠性，恰恰是最需要警惕的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
