进度条实现需规避原生progress动画限制，改用div+js控制width/transform配合css过渡；fixed定位须设top/left/width且防overflow截断；ios渲染用2px或4px加scaley；raf驱动线性插值确保平滑；框架中应直接操作style而非依赖响应式更新。
progress 元素不支持 CSS 动画直接驱动
浏览器原生 <progress></progress> 是表单控件，它的 value 属性是唯一合法的动画目标，不能像普通 DOM 元素那样对 width 或 transform 做 CSS 过渡。直接写 transition: width 0.3s 完全无效——这是最常卡住的地方。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 放弃用
<progress></progress>做动画进度条，改用语义化更弱但可控性更强的<div> + <code>aria-valuenow - 用 JS 主动更新元素的
style.width或style.transform，再配合 CSStransition - 若坚持用
<progress></progress>，只能靠 JS 触发value变更，再用::after伪元素模拟动画（兼容性差、不可靠） - 必须设
top: 0+left: 0+width: 100%，缺一不可；只写top: 0在某些安卓 WebView 下会错位 - 避免用
z-index: 9999这类魔法数字，优先用z-index: 1000并确保父容器没设置overflow: hidden截断 - 在 iOS 上，
height: 3px容易被渲染成模糊线条，建议用height: 2px或height: 4px配合transform: scaleY(0.99)强制清晰渲染 - 用
requestAnimationFrame驱动每一帧更新，配合线性插值计算当前值：current = start + (end - start) * progressRatio - 别硬编码 100 步循环，按毫秒计时（如 300ms 内完成），否则不同设备体验差异极大
- 加载完成时，务必手动设
width: 100%并清除定时器/raf，否则可能残留 99.8% 卡住 - Vue 用户：加
key强制重渲染，或用this.$nextTick()确保样式应用后再推进下一步 - React 用户：避免在单次 render 中多次 setState，改用函数式更新 +
useRef缓存进度值，仅在useEffect中触发 DOM 修改 - 通用原则：动画过程不要依赖框架响应式系统做中间状态，直接操作
element.style.width更可靠
固定顶部进度条的定位陷阱
position: fixed 看似简单，但和页面滚动、视口缩放、iOS Safari 的地址栏隐藏逻辑一碰就出问题。常见现象是进度条在滚动中“跳动”或“消失半截”。
实操建议：
立即学习“前端免费学习笔记（深入）”；
从 0% 到 100% 的平滑过渡要绕开 requestAnimationFrame
很多人用 setTimeout 或 setInterval 模拟进度增长，结果卡顿、跳变、甚至超调到 105%。根本原因是时间片不精准，且没和屏幕刷新率对齐。
实操建议：
立即学习“前端免费学习笔记（深入）”；
Vue/React 中状态更新与 DOM 渲染的时机差
在 Vue 的 v-bind:style 或 React 的 style={{ width: `${percent}%` }} 中，JS 更新 state 后，DOM 不一定立刻重绘——尤其在快速连续更新时，会合并渲染，导致动画断续。
实操建议：
立即学习“前端免费学习笔记（深入）”；
真正难的不是让进度条动起来，而是让它在各种网络抖动、低端机、iOS 地址栏收起/展开、WebView 缓存策略下都不抽搐。大部分失败都发生在「以为 CSS 能搞定一切」的那一刻。
