根本原因是width变化触发layout+paint双开销，尤其在padding/border/flex/box-sizing混用时帧率骤降；平滑方案是用transform:scalex()替代width，因其走合成层、支持gpu加速且不触发布局。
Bootstrap 进度条的 width 动画不流畅，根本原因不是“没加 transition”，而是浏览器在 width 变化时触发了 layout（重排）+ paint（重绘）双开销，尤其当父容器或自身存在 padding、border、flex 布局、box-sizing 混用时，动画帧率直接掉到 30fps 以下。
为什么加了 transition: width 0.3s 依然卡顿
常见错误是只写 transition: width 0.3s，但没约束盒模型行为：
-
width是 layout 属性，每次变化都会强制浏览器重新计算整个元素及其后代的几何位置 - 如果
.progress-bar外层有padding或border，且未设box-sizing: border-box，width 实际占用空间会浮动，导致动画抖动 - 在 Flex 容器中（如
.progress设为display: flex），width可能被flex-grow覆盖，transition 失效 - 移动端或低端设备上，
width动画无法启用 GPU 加速，纯 CPU 渲染易掉帧
真正平滑的替代方案：用 transform 替代 width
浏览器对 transform: scaleX() 的优化远高于 width —— 它走合成层，不触发布局，支持硬件加速。只需两步：
- 给
.progress-bar设置固定宽度（如width: 100%），再用transform: scaleX(0.6)控制视觉进度 - 添加
transform-origin: left center，确保缩放锚点在左侧，避免向右“漂移” - 过渡声明必须包含
transform：transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1)
注意：需同步更新 aria-valuenow 和 JS 控制逻辑，因为视觉进度已脱离 width。
哪些 CSS 属性会让 width 动画彻底失效
这些看似无害的样式，会悄悄破坏 width 过渡的连贯性：
-
overflow: hidden在父容器（.progress）上 +width子元素 → 触发频繁裁剪重绘 -
position: absolute+left/top配合 width → 浏览器可能放弃优化，降级为软件渲染 -
filter: drop-shadow()或backdrop-filter→ 强制创建新图层，width 变化时图层重合成成本飙升 -
will-change: width（错误用法）→ 不仅无效，还可能提前占用内存，反而拖慢首帧
检查是否真正在“动画”，而不是“跳变”
打开 Chrome DevTools → Rendering 面板 → 勾选 “FPS Meter” 和 “Paint Flashing”。播放进度更新时观察：
- 如果进度条每次变化都伴随大面积绿色闪烁 → 说明在重绘，
width不适合当前上下文 - 如果 FPS 长期低于 45 → 几乎可以确定是 layout bottleneck，应立即切换到
transform方案 - 如果动画开头/结尾有明显卡顿 → 很可能是 cubic-bezier 时间函数不合理，或 JS 更新频率过高（比如每 10ms 改一次 width）
真正难调的不是怎么写动画，而是怎么让浏览器相信这个动画值得用 GPU 跑——而 width 在绝大多数现代布局里，已经失去了这种信任。
