加 transition 却卡顿或首帧抖动，根本原因是浏览器未走 gpu 合成管线；需用 backface-hidden 预热图层、显式声明 transition-transform、避免 transition-all 和同步布局读取。
加了 transition 却卡顿或首帧抖动，不是 Tailwind 配错了，而是浏览器没走 GPU 合成管线——必须手动“预热”图层、选对可动画属性、避开隐式重排。
为什么 transition-transform 也要加 backface-hidden 才稳？
即使只用 transform 和 transition-transform，首次渲染仍可能微抖。原因：浏览器默认把新元素放在主图层，等第一帧绘制完才考虑是否提升合成层；而缩放/位移若在首帧发生，就会掉帧。
-
backface-hidden不改变视觉，但强制提前创建独立 GPU 图层，让过渡从挂载起就走合成管线 - 别用静态
will-change: transform（如写死在 class 里），它会拖慢首屏，且不比backface-hidden有效 - SSR 场景（如 Next.js）中，服务端已输出带
transform的 HTML，客户端水合瞬间易冲突，backface-hidden是最轻量的兜底方案
transition-all 是性能陷阱，不是省事捷径
transition-all 看似方便，实则让浏览器在每一帧都尝试插值所有可变属性，极易触发主线程重绘甚至降级。
- 它会连
box-shadow、filter、border-color一起动，而这些属性默认不进合成层 - 哪怕你只 hover 触发
scale，transition-all也会拉上其他属性“陪跑”，增加计算负担 - 正确做法是显式声明：用
transition-transform duration-300+hover:scale-105，精准控制动画范围
JS 控制过渡时，哪些操作会偷偷触发重排？
用 JS 切换类或改样式时，性能崩塌往往来自读取布局信息或批量切宽高类，而非动画本身。
- 别反复读
clientHeight、offsetWidth——每次读都会强制同步计算，打断渲染流水线 - 别用
classList.toggle('w-1/4', 'w-1/2')模拟宽度变化；改用el.style.transform = 'scaleX(0.7)' - 长时动画（>500ms）可加
will-change: transform，但必须 JS 动态添加/清除，不能写死在初始 class 中 - Flex 容器内做
scaleX，记得给父容器加min-w-0，否则gap或 flex 自动撑宽会让缩放失效
真正影响流畅度的，从来不是“有没有 transition”，而是“过渡是否发生在合成层”以及“JS 是否打断了渲染节奏”。backface-hidden 是最常被忽略的图层预热开关，而显式指定 transition-transform 或 transition-opacity 才是可控性的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
