will-change: transform 单独使用基本无效，仅提前升层却不修正像素对齐、抗锯齿或纹理采样；真正有效的是结合角度取整、容器像素对齐、动态设置 will-change 时机及移除策略。
单独加 will-change: transform 基本无效，甚至可能让模糊更严重。 它只是个提示，不修正像素对齐、不重置抗锯齿策略、也不干预 GPU 纹理采样。真正起效的是组合动作和时机控制。
为什么 will-change: transform 单独写没用
浏览器看到这行，只做一件事：提前升层。但升层后如果旋转中心不在像素边界、角度带小数、或字体仍走亚像素渲染路径，模糊照旧。实测中，will-change: transform + rotate(45.2deg) 比不用还糊；而删掉它、只留 translateZ(0) 反而更稳。
常见错误现象：
- 元素边缘发虚、文字毛边，尤其在 Safari 和部分安卓 WebView 中明显
- 动画中途突然清晰一帧，结束后又变糊——说明图层没清或坐标没对齐
- 列表滚动变卡，内存占用升高——
will-change被静态写死在 CSS 里，长期占着图层
真正有效的动态设置方式
必须配合动画生命周期手动控制，不能靠 CSS 静态声明。
立即学习“前端免费学习笔记（深入）”；
使用场景：轮播图翻页、下拉菜单展开、拖拽旋转控件等有明确“开始/结束”节点的交互。
实操建议：
- 动画触发前一帧，用 JS 设置
el.style.willChange = 'transform' - 动画最后一帧，在
requestAnimationFrame回调里立刻设为el.style.willChange = 'auto' - 若角度来自计算（如鼠标拖拽），务必先
Math.round(angle)再拼进transform，避免rotate(37.812deg)这种值 - 不要对
:hover这类无明确结束时机的状态用will-change，改用transform: rotate(45deg) translateZ(0)更可靠
比 will-change 更轻量且可控的替代方案
多数情况下，translateZ(0) 比 will-change 更直接有效：它强制创建新合成层，并重走光栅化流程，常能恢复亚像素渲染精度。
但要注意副作用：
- 长列表中每个 item 都加
translateZ(0)，会引发图层爆炸，内存飙升 - 静态图标翻转（如箭头展开）完全不需要
will-change，直接写transform: rotateY(180deg) backface-visibility: hidden就够 - 移动端 Safari 对
transform值极其敏感，必须搭配-webkit-font-smoothing: subpixel-antialiased，且仅当角度为整数时才生效
绕开 GPU 纹理采样的终极思路
只要文字被当作纹理处理，就逃不开插值模糊。所以最稳的解法是不让它进 GPU 渲染管线。
关键条件：
- 容器宽高设为偶数像素，配合
transform-origin: 50% 50%，确保旋转中心落在物理像素中心 - 避免
rotate()和scale()混用，缩放会放大坐标误差，加剧模糊 - 高密度列表项宁可用
transform: translate(0, 0)占位，也不加will-change—— 少一帧精度，换整页流畅 - 极端情况可放弃
rotate()，改用linear-gradient+::before模拟倾斜，完全脱离变换管线
复杂点在于：没有银弹。同一段 CSS 在 Chrome 桌面端看着正常，到了 iOS 17 的 Safari 上可能边缘全糊。真正要压住这个问题，得把“角度取整 + 容器像素对齐 + 动态升层 + 移除时机”四件事串起来做，漏一环都白搭。
