加will-change: transform不能解决旋转模糊，因其仅预升图层而不修复像素对齐；真正有效的是控制整数坐标、动态管理图层生命周期、绕开gpu纹理采样。
加 will-change: transform 不能解决旋转导致的盒模型模糊，它只提前升层，不修复像素对齐或光栅化问题；真正起效的是控制整数坐标、动态管理图层、绕开GPU纹理采样这三件事。
为什么 rotate() 后文字发虚不是旋转本身的问题
根本原因是 rotate() 触发了合成层（Compositing Layer），浏览器把文字渲染成纹理贴图后交给 GPU 做几何变换。GPU 默认用双线性插值采样，一旦坐标落在非整数像素上（比如 rotate(87.3deg)），边缘就会被平滑模糊——这不是 bug，是 GPU 渲染管线的默认行为。
- 小角度（如
rotate(2deg)）比 90° 倍数更易模糊，因为坐标计算天然带小数 - 移动端 Safari 对此最敏感，
will-change在它上面常无效甚至更糊 - 模糊程度和设备 DPI、字体粗细、缩放比例都相关，但根源始终是像素对齐失效
必须配合 JS 动态设置/清除 will-change 才可能生效
will-change: transform 单独写在 CSS 里基本没用，它只是个提示信号，不自动管理生命周期。真正起效的前提是：只在动画开始前一刻设，结束后立刻清。
- 动画开始前：
el.style.willChange = 'transform' - 监听
animationend或transitionend，执行el.style.willChange = 'auto' - 千万别在列表项上批量加，DevTools Layers 面板里看到超 50 层就说明内存正在泄漏
- 如果用
requestAnimationFrame清除，要确保在下一帧执行，避免“清得太晚”导致图层残留
比 will-change 更轻量的替代方案：translateZ(0) 和整数约束
多数场景下，transform: translateZ(0) 比 will-change 更直接有效——它强制创建新合成层并重走光栅化流程，常能恢复亚像素渲染质量，且不用 JS 管理。
- 但别滥用：高密度列表里每个 item 都加，图层数爆炸，滚动卡顿
- 更稳妥的写法是
transform: translate(0, 0)，效果接近，开销更低 - 所有动态计算的
rotate()角度必须截断小数：Math.round(angle) + 'deg' - 容器宽高设为偶数 px，配合
transform-origin: 50% 50%，让旋转中心落在像素中心点
终极手段：彻底绕开 transform 渲染管线
只要文字还被当作纹理上传 GPU，就逃不开插值模糊。最稳的做法是让它根本不进 GPU 管线。
- 移动端 Safari 必须叠加
-webkit-font-smoothing: subpixel-antialiased，但仅当rotate()值为整数时才生效 - 避免
rotate()和scale()混用——缩放会放大坐标误差，让模糊雪上加霜 - 用
linear-gradient+::before模拟倾斜效果，完全避开transform，适合静态标签类需求 - 注意：所谓“变清晰”，有时只是帧率提升带来的错觉，或某个 Chrome 版本偶然回退到高质量光栅化——这种不可靠性，恰恰是最需要警惕的
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
