用width百分比+transition做进度条动画最轻量但易卡顿跳变，因width触发高开销重排；需加will-change:width、transform:translateZ(0)、overflow:hidden三行CSS，并用data-progress配合CSS规则控制宽度。
直接用 width 百分比 + transition 做进度条动画，是最轻量、兼容性最好、也最容易失控的方式——它能跑，但稍不注意就会卡顿、跳变或无法响应实时数据。
为什么 width 过渡在进度条里容易“假动”
浏览器对 width 的重排（reflow）开销比 transform 高得多；尤其当父容器宽高未固定、或存在 flex/grid 布局时，width: 0% → 65% 可能触发多次 layout 计算，动画帧率直接掉到 30fps 以下。更隐蔽的问题是：如果 JS 多次快速设置 element.style.width，中间过渡会被浏览器丢弃，最终只看到“闪”到目标值。
常见错误现象：
- 进度从 20% 突然跳到 80%，中间无动画
- 在 iOS Safari 上动画明显卡顿或完全静止
- 配合
display: none切换后，再 show 就失去过渡效果
必须加的三行 CSS 才能稳住过渡
仅写 transition: width 300ms ease; 是不够的。要让浏览器明确知道“这个元素的尺寸变化是可预测且可合成的”，得补全这三条：
立即学习“前端免费学习笔记（深入）”；
-
will-change: width;—— 提前告知浏览器该属性将变化（慎用，仅限进度条这类高频更新元素） -
transform: translateZ(0);或backface-visibility: hidden;—— 强制创建独立图层，避免重绘污染其他元素 -
overflow: hidden;—— 防止width超出容器时内容溢出干扰视觉节奏
完整最小样式示例：
.progress-bar {
height: 8px;
background-color: #eee;
border-radius: 4px;
overflow: hidden;
}
.progress-bar > .bar {
height: 100%;
width: 0%;
background-color: #26a2ff;
border-radius: 4px;
transition: width 300ms cubic-bezier(0.4, 0, 0.2, 1);
transform: translateZ(0);
}JS 更新时别直接赋值 width，改用 dataset 控制
直接操作 style.width 容易覆盖 CSS 动画、打断过渡链。推荐用 dataset 标记目标值，再由 CSS 拦截驱动：
- HTML 中写：
<div class="bar" data-progress="75"></div> - CSS 中加规则：
.bar[data-progress="75"] { width: 75%; } - JS 只做：
bar.dataset.progress = '82';
这样既保留 CSS 过渡声明的控制权，又避免 JS 频繁触发布局。若需动态值，可用 setAttribute('data-progress', value) 替代 dataset（兼容 IE11）。
移动端真机上仍卡？检查这俩硬伤
即使加了上述优化，在部分安卓 WebView 或低端 iOS 设备上仍可能掉帧。根本原因常是：
-
width值用了小数（如37.6%）—— 浏览器渲染子像素时强制降级为软件绘制 - 父容器用了
%或vw宽度，且嵌套了多层 flex —— 每次 width 变化都引发整条布局链重算
对策很实在：
- JS 中把进度值四舍五入到整数：
Math.round(progress * 100) - 给进度条父容器设固定
width（哪怕用max-width: 100%+width: 300pxfallback）
真正难的不是让进度动起来，而是让它动得不露痕迹——所有优化都指向一个点：把变化锁进合成层，把计算甩给 GPU，把 JS 降级为只发信号的遥控器。
