transition作用于width、height、top、left会卡顿，因其触发高成本layout；应优先使用transform和opacity等仅影响合成层的属性，并通过translateZ(0)或will-change提升图层。
为什么 transition 作用于 width、height、top、left 会卡顿
这些属性变更会触发浏览器的 layout（重排），而 layout 是高成本操作，尤其在中低端设备或复杂 DOM 下，每秒多次重排直接拖垮帧率。Chrome DevTools 的 Rendering > Paint flashing 和 Layers 面板能直观看到哪些元素被强制重排或频繁重绘。
哪些 CSS 属性适合做 transition
只影响合成层（compositor layer）的属性，不触发 layout 或 paint，能走 GPU 加速：
-
transform（如translateX()、scale()、rotate()） opacity
注意：transform: translateZ(0) 或 will-change: transform 可主动提升为合成层，但滥用会导致内存占用上升，仅在必要时加。
如何把「改 width」安全转成「改 transform」
典型场景：下拉菜单、折叠面板、进度条伸缩。核心思路是用 transform 模拟尺寸变化，保持原始 layout 不变。
立即学习“前端免费学习笔记（深入）”；
.panel {
/* 原本可能这样写（危险） */
/* transition: width 0.3s ease; */
<p>/<em> 改为安全方案：固定 width，靠 transform 缩放 </em>/
width: 300px;
transform-origin: left center;
transition: transform 0.3s ease;
}</p><p>.panel.is-collapsed {
transform: scaleX(0);
/<em> 注意：scaleX(0) 会让内容不可见，若需保留可访问性，配合 aria-hidden 或 visibility </em>/
}更稳妥的做法是结合 max-height + overflow: hidden 做渐隐（不触发布局），再用 transform 做位移补强，避免纯 max-height 过渡因高度不确定导致时间不准。
检查和验证是否真避开了 layout
打开 Chrome DevTools → More Tools > Rendering → 勾选：
- Layout Shift Regions（看是否有意外位移）
- Paint Flashing（绿色闪烁越少越好）
- Layer Borders（确认动效元素有独立图层边框）
如果仍看到 layout 耗时尖峰，大概率是：
- 父容器用了 flex 或 grid 且子项尺寸变化引发了连锁重排
- 动画元素上有 box-shadow、border-radius 等导致 paint 成本升高
- JavaScript 在动画过程中读取了 offsetWidth、getComputedStyle() 等触发同步 layout
真正难的不是换属性，而是识别那些藏在 flex 容器里、被 JS 无意读取的 layout 触发点。
