transition 在 opacity 或 transform 上更流畅，因其触发硬件加速交由 GPU 合成；而 width、height、left、top 等属性频繁触发 CPU 的 layout 和 paint，导致卡顿。
为什么 transition 在 opacity 或 transform 上更流畅
浏览器对 opacity 和 transform（如 translate、scale、rotate）的过渡能触发硬件加速，直接交由 GPU 处理合成帧；而 width、height、left、top 等属性会频繁触发 layout + paint，CPU 负担重，卡顿明显。
常见错误是写成：transition: left 0.3s ease; —— 这会让每一帧都重新计算布局，尤其在中低端设备上掉帧严重。
- 优先用
transform: translateX(10px)替代left: 10px - 用
transform: scale(1.2)替代width/height变更 - 动画中避免同时过渡
transform和background-color，后者仍走 CPU paint
如何强制启用 GPU 加速但不破坏可访问性
加 will-change: transform 或 transform: translateZ(0) 确实能提前提示浏览器“这个元素要动”，但它不是万能药，滥用反而增加内存开销和图层分裂风险。
真正有效的做法是：只在需要动画的元素上、且仅在动画触发前一刻启用加速，并在动画结束后清理（尤其在频繁交互场景下）。
立即学习“前端免费学习笔记（深入）”；
- 不要全局写
* { will-change: transform; }—— 这会让整个页面图层爆炸 - 推荐用 class 控制：
.is-animating { will-change: transform; }，JS 中el.classList.add('is-animating')→ 动画 start 时加，transitionend后立刻remove -
transform: translateZ(0)兼容性更好，但 iOS Safari 旧版本可能引发输入框失焦，慎用于表单内元素
transform 动画中常见的性能陷阱
即使用了 transform，卡顿仍可能发生——问题往往出在「隐式合成」或「非合成属性干扰」上。
比如给一个 position: absolute 元素加 transform 动画，但它的父容器有 overflow: hidden 或 filter: blur(1px)，就会导致该元素无法独立图层化，被迫回退到 CPU 渲染。
- 检查 DevTools → Rendering → “Paint flashing” 和 “Layer borders”，看动画区域是否被正确分图层
- 避免在动画元素上同时设置
box-shadow（尤其是动态变化的）或filter，它们会阻止 GPU 加速 - 用
transform: translate3d(0, 0, 0)替代translateZ(0)在部分 Android WebView 中更可靠，但注意它仍是 2D 动画，z 轴无实际位移
过渡卡顿却没报错？先查这三件事
没有控制台报错不等于没有性能问题。很多卡顿来自渲染管线阻塞，而非 JS 错误。
打开 Chrome DevTools → Performance 面板，录制一次完整过渡过程，重点关注 “Rendering” 和 “Layout” 区域的耗时峰值。
- 看是否有频繁的 “Layout” 或 “Recalculate Style” —— 说明你在动 layout 触发属性
- 检查 “Frames” 底部是否持续低于 60fps，黄色长条多意味着主线程被 JS 或样式计算占满
- 确认动画元素是否被其他 CSS 规则意外覆盖，比如
animation和transition同时存在导致行为冲突
硬件加速不是银弹，真正决定流畅度的是“是否让浏览器少做 layout 和 paint”。动得越少，越顺。
