steps()第一参数应填可见帧总数且必须配end关键字，如12帧写steps(12,end)；background-position须用固定像素单位，禁用百分比；需防纹理越界、全局样式覆盖及旧版safari渲染bug。
steps() 函数到底怎么填参数才不跳帧
填错 steps() 的第一个参数是雪碧图动画卡顿、快进或漏帧的最常见原因。它不是“总帧数”，而是“分几步完成整个动画周期”——比如 12 帧序列，动画时长 1s，你希望每帧停 1/12 秒，就得写 steps(12, end)；写成 steps(12, start) 或 steps(11) 都会偏移一帧。
-
steps(n, end)：动画从第 0 帧开始，第 n 步跳到第 n 帧（即最后一帧），适合大多数雪碧图左→右排列场景 -
steps(n, start)：第一帧不显示，直接跳到第 1 帧，容易漏播首帧，慎用 - n 必须严格等于雪碧图中「可见帧总数」，不是图片总格数（比如最后一格是空白占位符，就不能算）
- 若雪碧图是竖排，
background-position用 y 轴位移，但steps()参数逻辑不变
background-position 动画必须用百分比或固定像素？
必须用固定像素（如 px），不能用百分比或 em。因为 steps() 是离散跳变，浏览器需要明确知道每一帧的绝对位移量；百分比在不同容器尺寸下计算结果浮动，会导致帧对不齐，尤其在响应式页面里一缩放就错位。
- 横向雪碧图：假设每帧宽 64px，共 12 帧，则总宽 768px，
background-position从0px动画到-704px（注意：最后一帧起始位置是-(12-1)*64 = -704px） - 别偷懒写
background-position: 0 -704px，要显式声明单位，0写成0px - 用 CSS 变量存单帧宽度（如
--frame-w: 64px）能减少硬编码，但计算仍得在 JS 或预处理器里做，CSS 自身不支持calc()在steps()动画路径中动态算偏移
animation-timing-function 设为 steps() 后为啥还是平滑过渡
因为只设了 steps()，但没关掉默认的 easing 行为——CSS 动画默认会把 steps() 当作一个 timing function，但如果同时写了其他 transition 或 animation 属性干扰，或者用了简写 animation 覆盖了 animation-timing-function，就会退回到 ease。
- 务必单独声明：
animation-timing-function: steps(12, end)，不要依赖animation简写隐含传入 - 检查是否被父元素或重置样式表里的
* { animation-timing-function: ease }全局覆盖 - DevTools 里看「Computed」面板，确认最终生效的
animation-timing-function确实是steps(12, end)，而不是ease或linear - 某些旧版 Safari（≤15.4）对
steps()+background-position组合有渲染 bug，需加transform: translateZ(0)强制硬件加速
移动端真机上动画突然变慢或卡死
不是性能问题，大概率是雪碧图尺寸超限触发了 GPU 纹理降级。iOS Safari 和部分安卓 WebView 对单张背景图的宽高乘积有硬限制（通常 ≤ 2048×2048 或 4096×4096），一旦超标，浏览器会静默降级为 CPU 渲染，steps() 动画就失去逐帧精度，表现为拖影、跳帧甚至卡住。
立即学习“前端免费学习笔记（深入）”；
- 用
img标签打开雪碧图，右键「检查图像信息」看真实分辨率，别信文件名里的 “12frames” - 横向拼接易超标，优先改用竖排（高度增长比宽度更可控）
- Chrome DevTools → Rendering → 「Layer borders」可看到哪些元素被拆成独立纹理层；如果雪碧图层显示异常粗边或闪烁，基本就是纹理越界
- 真机调试时禁用
will-change: transform，它有时反而加剧纹理管理混乱
雪碧图逐帧动画的复杂点不在写法，而在像素级对齐和设备纹理策略的隐性耦合——动效看起来没问题，不代表所有设备都跑得稳。
