移动端进度条真正平滑填充需避开iOS伪元素限制，用CSS变量+width过渡并配合requestAnimationFrame节流、will-change加速及visibilitychange兜底。
移动端进度条要真正平滑填充，关键不是加 transition 就完事——必须让浏览器明确知道“动什么、从哪来、到哪去”，且避开移动端常见的 repaint 阻塞和伪元素失效问题。
为什么直接给 progress 元素写 transition: all 在 iOS 上无效
iOS Safari（截至 iOS 17.5）对 <progress></progress> 的伪元素支持不完整：::-webkit-progress-value 的 width 无法被过渡，background-color 是唯一稳定可动画的属性。同时，若未显式声明 background-color（哪怕设为 transparent），整个过渡链会静默失败。
- 错误写法：
progress::-webkit-progress-value { transition: width 0.3s ease; }→ iOS 下无动画 - 正确写法：
progress::-webkit-progress-value { background-color: #007BFF; transition: background-color 0.3s ease; } - 必须同步设置容器背景：
progress { background-color: #f0f0f0; }，否则伪元素无“起始状态”可比
用 CSS 变量 + transition 实现 JS 可控的平滑填充
把进度值抽成 --progress 变量，再通过 width 或 background-position 映射它，比直接操作内联 style.width 更利于维护，也避免频繁重排。
- HTML 结构用普通 div 更可靠：
<div class="progress-bar"><div class="progress-fill"></div></div> - CSS 中绑定变量：
.progress-fill { width: calc(var(--progress, 0) * 1%); transition: width 0.4s cubic-bezier(0.34, 1.56, 0.64, 1); } - JS 更新只需改变量：
el.style.setProperty('--progress', 65);，无需 touch DOM width - 移动端注意加
will-change: width;到.progress-fill，触发 GPU 加速（尤其在低端 Android 设备上明显）
避免移动端 scroll/jank 导致的动画卡顿
很多“平滑”进度条在手指滑动页面时突然跳变或暂停，本质是浏览器将 transition 降级为低优先级任务。这不是 CSS 写得不对，而是触发时机没对齐。
立即学习“前端免费学习笔记（深入）”；
- 不要在
scroll或touchmove里实时更新进度变量 —— 改用requestAnimationFrame节流 - 禁用
overflow: hidden的父容器滚动条动画（iOS Safari 会强制同步渲染） - 如果进度条嵌在
position: sticky区域内，确保其父级有transform: translateZ(0)强制图层提升 - 测试真机时重点看 Chrome for Android 的“Rendering > Paint flashing”面板，确认
.progress-fill没有每帧重绘
最易被忽略的一点：移动端 CSS 变量更新后，transition 不会自动 fallback 到上一帧状态。如果 JS 中断了更新（比如用户切后台），进度条可能卡在中间值不动 —— 必须监听 visibilitychange 并手动重置变量或补一帧动画。
