全屏切片动画的核心是 stagger + transform，不是靠 transition-delay 堆叠
直接给多个 div 设 transition-delay 看似能实现“逐片入场”，但实际会卡顿、难控制节奏，且无法响应窗口缩放或重绘。真正稳定的做法是用 transform: translateZ(0) 触发硬件加速，配合 will-change: transform 提前告知浏览器，再用 js 控制每个切片的 transition-timing-function 和起始状态。
常见错误现象：transition-delay 在 safari 上失效；切片在 chrome 中闪动；动画中途 resize 后错位。
- 每个切片必须有独立的
transform-origin（比如top left或center），否则旋转/缩放中心错乱 - 避免对
width/height做过渡——改用scale()或clip-path - 切片数量超过 8 个时，建议用
requestAnimationFrame批量触发动画，而非 css 全量声明
用 clip-path 实现“撕纸式”切片入场更可控
clip-path 能精准裁剪任意形状，比靠 overflow: hidden + translateX 更干净，也更容易做非线性展开（比如从中心放射、螺旋、波浪）。它天然支持 transition，且兼容性已覆盖 Chrome 79+、firefox 70+、Safari 15.4+。
使用场景：全屏轮播页、PWA 启动页、产品功能引导弹层。
立即学习“前端免费学习笔记（深入）”；
- 基础写法：
clip-path: polygon(0 0, 100% 0, 100% 0, 0 0)→clip-path: polygon(0 0, 100% 0, 100% 100%, 0 100%) - 为每个切片加不同
transition-delay是可行的，但只限于clip-path和opacity，别碰background-color - 注意 Safari 对
clip-path: polygon()的解析更严格——坐标值不能带空格逗号混用，必须写成0% 0%,100% 0%,100% 100%,0% 100%
JS 驱动比纯 CSS 更可靠，尤其要响应全屏切换事件
用户按 F11 或调用 document.documentElement.requestFullscreen() 时，CSS 动画常被中断或重置。必须监听 fullscreenchange 事件，并手动触发重绘或重设 class。
性能影响：在 fullscreenchange 回调里直接操作 20+ 个 div 的 style 会阻塞主线程，应批量用 classList.toggle() + CSS 变量驱动。
- 监听写法：
document.addEventListener('fullscreenchange', () => { /* 重新 apply 动画 class */ }) - 推荐用 CSS 自定义属性传参，比如
--stagger: 0.08s，避免 JS 里硬编码 delay 值 - 切片 dom 必须提前渲染完成（不能等
fullscreenchange再innerHTML注入），否则动画帧直接丢失
移动端 Safari 的 transform 3D 渲染陷阱
Safari ios 对 transform: translate3d(0,0,0) 的优化很激进，有时会导致切片“消失一帧”或初始位置偏移。这不是 bug，是 webkit 强制启用 GPU 渲染时的坐标系重置行为。
容易踩的坑：transform: scale(0.999) 比 scale(1) 更稳；backface-visibility: hidden 必须加在每个切片上；perspective 值不能为 0。
- 安全写法：
transform: translateZ(0) scale(0.999); backface-visibility: hidden; - 不要用
rotateY(0deg)做起始态——改用rotateY(-0.01deg)避免 Safari 合并图层 - 如果切片含文字，务必加
-webkit-font-smoothing: antialiased，否则放大时边缘发虚
事情说清了就结束。最麻烦的永远不是怎么动起来，而是动完之后要不要重排、要不要保留状态、以及 Safari 什么时候突然决定不渲染那一帧。