移动端进度条应使用 transform: scaleX() 替代 width + transition，因其不触发重排、GPU加速更稳；需配合 requestAnimationFrame、分段更新、防抖及老安卓兜底方案。
移动端进度条为什么不能只靠 width + transition
直接用 width 百分比加 transition 确实能动起来，但真在手机上跑会发现：动画卡顿、进度跳变、甚至某些安卓 WebView 里完全不触发重绘。根本原因是纯 CSS 控制 width 依赖 DOM 属性更新触发重排，而 JS 更新 style.width 频率高时容易被浏览器节流，尤其低端机上掉帧明显。
推荐写法：用 transform: scaleX() 替代 width
transform 是合成层属性，不触发重排，GPU 加速更稳。配合 transition: transform，移动端兼容性好（iOS Safari 12+、Android Chrome 60+ 都没问题）。
- 进度容器保持固定宽高，内部条用
transform-origin: left center确保从左向右拉伸 - JS 更新时只改
style.transform = 'scaleX(0.75)'，别碰width - 避免同时设置
width和transform，否则可能因层叠顺序导致视觉错位
.progress-bar {
height: 4px;
background: #e0e0e0;
}
.progress-fill {
height: 100%;
background: #4a90e2;
transform-origin: left center;
transition: transform 300ms ease-out;
}
JS 更新进度时的两个关键细节
不是所有 requestAnimationFrame 或 setTimeout 更新都可靠，尤其在页面后台或节电模式下。
- 用
requestAnimationFrame包裹更新逻辑，但需判断是否已进入后台：document.hidden为true时暂停动画 - 不要每 1% 就设一次
transform，建议按 5% 或 10% 分段，减少渲染压力 - 如果进度来自接口响应，注意防抖：连续多次调用
setProgress(20)、setProgress(45)，应合并为最终值，避免中间无效过渡
兼容老安卓 WebView 的兜底方案
部分 Android 4.x 系统 WebView 不支持 transform 动画，或者 scaleX() 行为异常。此时可检测支持性并降级：
- 用
CSS.supports('transform', 'scaleX(1)')判断是否可用 - 不可用时切回
width+transition，但把transition-duration设为0ms，改用 JS 手动插值 +requestAnimationFrame模拟动画（避免卡死） - 务必给进度条加
will-change: transform（现代浏览器），但老安卓上要移除，否则反而拖慢
实际效果差异很直观：用 transform 的进度条在微信内置浏览器里滑动页面时依然顺滑；而纯 width 方案，只要页面有滚动或 touchmove，动画就大概率卡住一两帧。这点在弱网加载场景下特别明显——用户盯着进度条，卡顿感比加载慢本身更让人焦虑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
