width动画会强制触发每帧重排，导致严重卡顿；应改用transform: scaleX()替代，并避免读取offsetWidth等触发同步layout的操作。
改变 width 会强制触发每帧重排（reflow），因为浏览器必须重新计算该元素及其所有后代、兄弟、父级甚至后续流内元素的布局位置与尺寸——这不是“动一个元素”，而是“重跑整个布局流水线”。
width 动画为什么等于主动卡顿
浏览器对 width 的每次修改，都会打断渲染流水线，进入同步 Layout 阶段。尤其在移动端 WebView（如 Android 5–7）中，一次 layout 耗时常达 3–8ms，而 60fps 帧间隔仅 16.67ms；连续动画下极易堆积未完成帧，直接掉到 20–30fps。
- 它影响盒模型尺寸，必然牵连 margin/padding/border/内容换行/文本流/浮动清除等
- 若元素是 flex 或 grid 子项，
width变更还会触发容器的 justify-items / align-content 重评估 - 哪怕父容器设了
overflow: hidden，也无法跳过 layout 计算，只是裁剪结果
替代方案：用 transform 替代 width 的实操要点
把宽度变化转化为缩放操作，让 GPU 合成层接管，完全避开 Layout 和 Paint 阶段。
- 进度条场景：用
transform: scaleX(0.7)替代width: 70%，前提是父容器宽度固定且子元素设transform-origin: left center - 避免混用：
width和transform同时出现在同一动画规则里，整条动画会降级回 CPU 渲染 - 单位要明确：起始/结束值不能含
auto、em或未解析的calc()，否则浏览器无法插值，动画退化为瞬时切换
will-change 对 width 动画无效，还可能更糟
will-change: width 不被任何主流浏览器支持——它不是合法值。强行写上会被忽略；若误写成 will-change: transform 却还在改 width，既浪费内存升层，又没解决根本问题。
立即学习“前端免费学习笔记（深入）”；
- 合成层只对
transform和opacity生效，其他属性加will-change等于白加 - 对列表项批量加
will-change: transform，在低端安卓机上容易触发 OOM，页面直接卡死或白屏 - 真正需要的是删掉
width，而不是给它加加速提示
最易被忽略的一点：很多“平滑进度条”实现仍偷偷读取 offsetWidth 来做 JS 进度校准，这个读操作会强制同步 layout，哪怕你已经用了 transform —— 动画再稳，一帧里读一次 offsetWidth 就全毁了。
