will-change 本身不导致模糊，而是放大已有像素对齐问题；它提前将元素推入gpu合成层，当transform值含小数时触发双线性插值致边缘发虚。
will-change 本身不导致模糊，但会放大已有像素对齐问题
加了 will-change: transform 后文字或边框变糊，不是它“引入”了新问题，而是提前把元素推入 GPU 合成层——一旦该层的渲染坐标落在非整数像素上（比如 transform: rotate(87.3deg) 或 translateX(12.7px)），GPU 就必须用双线性插值采样，边缘自然发虚。Chrome、Edge 默认如此，Safari 更敏感。
- 模糊只在合成层里可见；普通文档流中文字仍走 CPU 光栅化，清晰度有保障
-
will-change不重置坐标精度，也不强制四舍五入，它只是“通知浏览器：我要动了”，后续一切仍取决于你传进去的 transform 值是否为整数 - 移动端 Safari 上，
will-change: transform常完全无效，甚至因图层管理策略差异让模糊更明显
静态写死 will-change 是最常见模糊诱因
在 CSS 里直接写 .card { will-change: transform; }，等于让所有 .card 长期驻留 GPU 图层。图层越多，浏览器越倾向复用纹理缓存、降低单次光栅化质量——尤其当容器尺寸为奇数 px 或 transform-origin 落点偏移时，亚像素误差被持续放大。
- DevTools Layers 面板里看到超 30 层 “Composited” 元素，基本可以确认是静态声明惹的祸
- 列表页中每个 item 都这么写，滚动时图层无法及时回收，内存飙升 + 模糊加剧
- 它不区分“是否真在动画”，只要匹配就升层，哪怕元素只是 hover 状态静止着
真正起效的组合必须含 JS 动态控制
只有在动画触发前一刻设置、结束后立刻清除，并配合整数 transform 值，will-change 才可能避免模糊恶化。否则它只是给 GPU 渲染管线加了一道不可控的中间层。
- 动画开始前：用
element.style.willChange = 'transform' - 监听
animationend或transitionend，再用双requestAnimationFrame清除：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 所有动态计算的角度/位移必须截断小数：
Math.round(angle) + 'deg'、Math.round(x) + 'px' - 容器宽高设为偶数 px，搭配
transform-origin: 50% 50%，确保旋转中心落在像素中心点
比 will-change 更稳的替代方案
多数场景下，transform: translateZ(0) 或 transform: translate(0, 0) 比 will-change 更可控：它们强制创建新合成层并重走光栅化流程，且无需 JS 生命周期管理，不会因忘记清除而残留图层。
-
translateZ(0)在 Chrome/Firefox 中恢复亚像素渲染质量的效果通常优于will-change -
translate(0, 0)开销更低，适合轻量级 hover 动画 - 终极绕过方案：用
linear-gradient+::before模拟倾斜，彻底不进 GPU 渲染管线 - 移动端 Safari 必须叠加
-webkit-font-smoothing: subpixel-antialiased，但仅当rotate()值为整数时才生效
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
