根源是WebKit内核在CPU渲染路径下对sub-pixel旋转插值时抗锯齿失效，本质为未启用GPU合成导致软件光栅化处理亚像素边缘；真正解法是同时使用transform: ... translateZ(0)与will-change: transform强制提升独立合成层。
transform: rotate() 在移动端出现锯齿的根源
锯齿不是“动画没写对”，而是 WebKit 内核（Safari、Chrome for iOS）在 CPU 渲染路径下对 sub-pixel 旋转做插值时，抗锯齿算法失效导致的边缘毛刺。尤其在 rotate(1deg) 这类小角度、或配合 border-radius、box-shadow、overflow: hidden 使用时，问题更明显——它本质是渲染层未启用 GPU 合成，浏览器被迫用软件光栅化处理亚像素边缘。
为什么加 rotate(1deg) 微调反而可能加重锯齿
单纯在原有 transform 中叠加 rotate(1deg)（比如从 rotate(45deg) 改成 rotate(46deg)），不会触发硬件加速，也不改变图层合成策略；反而因角度更偏离整数，加剧 sub-pixel 插值误差。这不是“微调”，是误把表象当病因。
- 浏览器不会因为角度变 1° 就自动切到 GPU 渲染
- 若原样式已含
transform: rotate(45deg)，再加rotate(1deg)会变成rotate(46deg)，但未解决底层合成问题 - 某些旧版 Safari（≤16.4）甚至对非整十度的 rotate 计算更不精确
真正起效的锯齿修复组合写法
必须同时满足两个条件：强制提升为独立合成层 + 告知浏览器该元素将变化。缺一不可，且顺序和写法有严格要求：
- 在同一个 CSS 规则中，
transform必须包含translateZ(0)（或translate3d(0,0,0)），这是实际触发 GPU 合成的最小代价操作 -
will-change: transform必须与translateZ(0)共存于同一选择器，否则浏览器忽略 - 旋转角度写在
transform里，不要拆开；例如：transform: rotate(45deg) translateZ(0)，而非分两行写 - 避免混用
-webkit-backface-visibility: hidden和will-change，后者已覆盖前者效果，且旧版 Safari 可能冲突
示例：
立即学习“前端免费学习笔记（深入）”；
.spinner {
animation: spin 2s linear infinite;
transform: rotate(360deg) translateZ(0);
will-change: transform;
}
遇到 box-shadow 或 border 锯齿要额外处理
如果旋转元素带阴影或边框，仅加 translateZ(0) 不够——box-shadow 在合成层中仍可能走 CPU 渲染路径，border 则受 DPR 和亚像素缩放影响。
- 替换
box-shadow为filter: drop-shadow()，例如：filter: drop-shadow(0 2px 4px rgba(0,0,0,0.2)) - 若必须用
border且缩放/旋转中发虚，优先考虑用伪元素 +transform: scaleY(0.5)模拟 1px 边框，避开 border 渲染链 - 图片本身锯齿？加
image-rendering: pixelated（适用于 icon 类小图）或换 SVG
真正容易被忽略的是：锯齿从来不是单一样式的问题，而是 transform + overflow + devicePixelRatio + 渲染层切换时机共同作用的结果。盯着 rotate 改，不如先打开 DevTools → Layers 面板，确认元素是否真成了绿色合成图层。
