H5端iOS Safari CSS动画锯齿源于渲染层未升层、像素未对齐或颜色采样截断；需同时使用translateZ(0)和will-change: transform强制GPU合成，伪元素需独立设置，角度/坐标须取整，渐变应移至带升层的伪元素并用十六进制色值。
直接说结论：H5端在移动端（尤其是 iOS Safari）出现 CSS 动画锯齿，**不是动画写错了，而是渲染层没升上去、像素没对齐、或颜色过渡被采样截断**。加 transform: rotate(1deg) 或单纯塞 will-change: transform 基本无效，甚至加重问题。
为什么 translateZ(0) + will-change 组合必须一起写
单独写 will-change: transform 只是“提示”浏览器要升层，但不触发实际合成；而 translateZ(0) 是真正强制创建独立 GPU 合成层的最小代价操作。两者缺一不可，且必须在同一 CSS 规则里声明：
- 顺序不能错：
transform: rotate(45deg) translateZ(0)有效，transform: rotate(45deg); transform: translateZ(0)会覆盖前者 - 伪元素也要同步加：如果锯齿用
::before实现，它的transform和will-change必须独立设置，父容器上设了不等于子元素自动继承 - 微信小程序 H5 渲染层（如 WebView 内核较老）可能忽略
will-change，此时只保留translateZ(0)更稳妥
旋转/缩放动画中角度和坐标必须取整
WebKit 对 sub-pixel 值（比如 rotate(37.82deg) 或 translateX(99.5px)）插值极不友好，会导致边缘毛刺、文字虚化、滚动时忽清忽糊：
- JS 控制动画时，角度务必
Math.round(angle)再拼进transform - 用
calc()替代百分比偏移：比如容器宽199px，left: 50%得到99.5px，应改写为left: calc(50% - 0.5px) - 锯齿边框若用
clip-path: polygon()，坐标值避免写死10px，改用10%或calc(10% + 1px)，再配合uni.getSystemInfoSync().pixelRatio动态修正
渐变背景+动画时锯齿更明显？把渐变挪到伪元素并隔离渲染
直接在动效元素上写 background: linear-gradient() 是色带重灾区——Safari GPU 渲染通道默认用 16-bit 色深，两个相近色硬切就会暴露断层：
立即学习“前端免费学习笔记（深入）”；
- 主元素只留
position: relative; background: transparent - 伪元素
::before承载渐变，必须有content: ""、inset: 0、transform: translateZ(0)和will-change: transform - 禁用
rgba()和rgb()函数色值，改用十六进制；色标之间至少留0.5%过渡区间，例如#ff9a9e 49.5%, #fad0c4 50.5% - 真机调试时发现渐变边缘发灰，优先检查 DevTools → Layers 面板里该伪元素是否被标红（即已进入独立合成层）
最易被忽略的一点：锯齿从来不是单一 CSS 属性能解决的问题，它暴露的是整个渲染链路的脆弱性——从设备 DPR 到图层合成策略，再到颜色采样精度。动效元素一旦开始旋转或缩放，就别再指望靠 -webkit-font-smoothing 或调整 border-radius 来“修边”，得从升层、对齐、降噪三方面同时控制。
