应使用 transform: scaleX() 实现循环进度条动画，避免直接 animating width；推荐 2.5s linear 动画，配合 vh 单位适配屏幕，必要时用 will-change 提升性能但需及时移除。
用 @keyframes 实现循环进度条动画，但别直接 animating width
移动端加载进度条最常见错误是直接对 width 做线性动画——它会卡顿、跳帧，尤其在低端 Android 上。根本原因是 width 触发 layout + paint，而移动端 GPU 不加速这个属性。
正确做法是只 animating transform: scaleX() 或 clip-path，它们走合成层（compositor），不触发重排重绘。
- 推荐用
transform: scaleX()：兼容性好（iOS 9+、Android 4.4+），代码简单 - 若需精确控制渐变或圆角裁剪，可用
clip-path: inset(0 0 0 calc(100% - Xpx))，但 iOS Safari 对动态clip-path动画支持不稳定，慎用 - 动画时长建议设为
2s~3s，太快用户感知不到，太慢显得卡死
用 animation-timing-function: linear 保证匀速推进
默认的 cubic-bezier(.25,.1,.25,1)（即 ease）会让进度条“先快后慢”，造成加载“快开始、慢收尾”的错觉，用户反而更焦虑。
必须显式声明 linear，让视觉进度与真实加载节奏一致：
立即学习“前端免费学习笔记（深入）”；
@keyframes progress-fill {
0% { transform: scaleX(0); }
100% { transform: scaleX(1); }
}
.progress-bar::after {
animation: progress-fill 2.5s linear infinite;
}- 别用
ease-in-out或steps()——前者失真，后者无法实现平滑循环 - 如果进度条要配合真实加载状态（比如从 0% → 100% 后暂停），就不要用
infinite，改用 JS 控制animation-play-state
适配不同屏幕密度：用 vh/vw 而非固定 px
移动端屏幕宽度差异大，固定高度如 height: 2px 在 iPhone SE 上可能看不见，在 iPad 上又太粗。用视口单位更稳妥。
-
height: 0.15vh是个安全起点（约等于 1.5px @ 375px 宽屏） - 避免用
rem或em，因为根字体大小可能被用户缩放或 UA 修改，导致条变粗/消失 - 如果项目用了 CSS 自定义属性（
--progress-height），记得在 JS 动态更新时也同步改style.setProperty()，否则动画会断
真机调试时注意 Safari 的 will-change 行为
iOS Safari 对 transform 动画有优化策略，但有时会因未声明 will-change 导致首帧掉帧；可加但别滥用：
.progress-bar::after {
will-change: transform;
/* 仅在动画开始前设置，结束后 remove，否则长期占用 GPU 内存 */
}- 只对正在动画的元素加
will-change: transform，全局加会导致内存泄漏 - Android Chrome 不需要它，加了反而可能增加开销
- 测试时用 Safari 的「开发者 → 仿真器 → FPS 计数器」看是否稳定 60fps，低于 50fps 就要查是否触发了 layout
真正难的是让动画和实际资源加载节奏对齐——CSS 动画再顺滑，如果 JS 没在合适时机暂停或重置，用户看到的就是“假进度”。这点没法靠样式解决，得靠 loading 状态管理逻辑兜底。
