transition 卡顿主因是触发 layout thrashing，混入 width 等非合成属性会使 transform/opacity 的 GPU 加速整体失效；应仅用 transform、opacity 等可合成属性，并避免 JS 同步读写布局、父级阻断合成等干扰。
因为浏览器被迫在每一帧同步计算 layout，而 transition 本身不卡，卡的是它触发的 layout thrashing。
transition 声明里混入了非合成属性（如 width、margin、background-color）
只要 transition 列表中包含任一触发 layout 的属性，整个过渡都会降级到 CPU 渲染，哪怕你同时动了 transform 和 opacity。浏览器无法把它们拆开优化，只能逐帧重排+重绘。
- 常见错误写法：
transition: width 0.3s, transform 0.3s, opacity 0.3s;——width一出现，transform和opacity的 GPU 加速就全失效 - 正确做法：只保留可合成属性：
transition: transform 0.25s ease, opacity 0.25s ease; - 慎用
box-shadow、filter: blur()，尤其在 iOS Safari 上，它们会隐式创建新层但又不提层，导致合成器频繁重调度
JS 在同一任务中读写交错，强制触发同步 layout
比如在 click 回调里先改 el.style.width = '200px'，紧接着读 el.offsetWidth，浏览器必须立刻回流计算真实尺寸，打断正在运行的 transition 帧队列。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 旧浏览器（如 Safari 9–10、IE11）对此更敏感，一次
getBoundingClientRect()就可能让首帧卡住 30ms+ - 修复方式：写操作批量做，读操作放到
requestAnimationFrame下一帧，确保“先写后读”分离 - 避免在
transitionstart或touchstart中读取任何布局信息
父容器有阻断合成的样式（如 overflow: hidden、filter、will-change: transform 写错位置）
这些规则会让子元素的 transform 动画失去独立合成层，被迫和父容器一起 repaint，动画帧率直线下跌。
立即学习“前端免费学习笔记（深入）”；
- 验证是否真提层：Chrome DevTools → Rendering → 勾选 “Layer borders”，只有绿色边框才表示 GPU 合成生效
-
will-change: transform必须写在动画开始前至少一帧，且不能写在伪类或动态 class 里（否则来不及初始化） - 父级
filter: blur(1px)会让所有子元素的transform过渡变卡，即使子元素自己没设 filter
最常被忽略的一点：transition 不是“加了就动”，它是浏览器对「两个确定状态之间变化」的承诺；一旦中间夹杂 layout 计算、样式重置或父层约束，这个承诺就会被中断——不是代码没写对，而是你没给浏览器留出安静执行的路径。
