移动端进度条必须用 transform: scalex() 而非 width，因 width 触发重排重绘，在低端 android 和微信 webview 中导致卡顿、跳帧甚至动画消失；应结合 requestanimationframe、will-change 控制及 vh 单位适配。
移动端进度条必须用 transform: scaleX()，别碰 width —— 否则低端 Android 和微信 WebView 里一滚动就卡顿、跳帧，甚至动画直接消失。
为什么不能用 width + transition
直接改 style.width 或写 width: 60% 触发 layout + paint，移动端 GPU 不加速这个路径。尤其在页面有 touchmove、scroll 或后台标签页时，浏览器会节流重排，导致进度条“突变”而非“流动”。真机上常见现象包括：
- 进度从 0% 直接跳到 70%，中间过渡全丢
- 手指还在滑动，进度条却停住不动
- 微信内置浏览器中，
width动画完全不执行（尤其 Android 7.x WebView）
正确写法：transform + requestAnimationFrame
核心是只动 transform: scaleX()，靠 JS 控制缩放比例，再用 requestAnimationFrame 节流更新。关键点：
- 进度容器设固定宽高，
.progress-fill内部元素加transform-origin: left center - JS 中只写
el.style.transform = 'scaleX(' + progress + ')'，progress 是 0~1 的小数 - 用
requestAnimationFrame包裹更新逻辑，但需判断document.hidden，页面切后台时暂停 - 避免每 1% 都设一次 —— 建议按 5% 分段，或对连续调用做防抖（比如
setProgress(32)和setProgress(38)合并为最终值）
适配不同屏幕的单位和尺寸
别用 px 或 rem 设高度，它们在 iPhone SE 和 iPad 上视觉差异极大：
- 高度统一用
vh：例如height: 0.15vh（≈1.5px @375px 宽屏），iOS/Android 兼容性好 - 禁用
rem：用户缩放字体或 UA 修改根字号时，进度条可能变粗、消失甚至错位 - 如果用了 CSS 变量如
--progress-height，JS 更新时必须同步调用el.style.setProperty('--progress-height', '0.15vh')，否则动画断掉 - 动画时长设 2s–3s，太短用户感知不到，太长像卡死；必须显式写
animation-timing-function: linear，别用默认ease—— 否则“先快后慢”反而加剧焦虑
真机调试绕不开的 Safari will-change 坑
iOS Safari 对 transform 动画首帧优化依赖 will-change: transform，但滥用会吃 GPU 内存：
- 只在动画开始前加：
el.style.willChange = 'transform' - 动画结束后立刻移除：
el.style.willChange = 'auto'或清空 - 老安卓 WebView（如 Android 4.4）不支持该属性，检测到不支持时要主动移除，否则更卡
- 别给整个
.progress容器加，只加到实际动画的子元素（如.progress-fill）
最易被忽略的是：动画是否真正“持续可见”。很多项目在页面进入后台、横竖屏切换、或触发 scroll-behavior: smooth 时，requestAnimationFrame 会被系统暂停或延迟，导致进度条“假死”。这不是代码写错了，而是没把生命周期管理当一回事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
