17370845950

用 progress 元素 + JavaScript 控制 value 是最直接的方式，它依赖 value 和 max 属性实现原生进度动画，需用 JS 动态更新而非静态设置，现代浏览器均支持 transition，iOS Safari 需优化更新节奏与 GPU 加速。

用 progress 元素 + JavaScript 控制值是最直接的方式

HTML5 原生 progress 标签不是用来“模拟”上传进度的，但它能完美承载进度动画的视觉表现。关键在于：它不依赖真实文件上传，只关心 value 和 max 属性。你手动更新 value，浏览器就自动渲染过渡动画（前提是 CSS 未禁用 transition）。

常见错误是直接写死 value="50" 然后不动——这不会动，必须用 JS 定时或事件驱动更新。

• 默认有浏览器内置样式，Chrome/Firefox/Safari 都支持 transition 动画（如 progress::-webkit-progress-value 可定制）
• 不要用 meter 替代，它语义是“测量值”，不支持进度动画语义
• 若需兼容 IE（已淘汰），得回退到 div + width 百分比模拟，但现代项目无需考虑

用 CSS @keyframes 做“假进度条”仅适合加载占位

当没有 JS 或需要极简 fallback（比如 SSR 页面首屏）时，可用纯 CSS 实现“扫描线”或“流动色块”效果。但这不是真进度，只是视觉暗示——用户感知是“正在处理”，而非“已完成 67%”。

典型场景：按钮点击后、API 请求发出前的瞬间反馈；或图片懒加载占位。

• 不能绑定实际数值，animation 是循环或单次播放，无法 pause/resume
• 若和真实进度混用（比如先播 CSS 动画，再切到 JS 控制 progress），容易出现跳变或错位
• 推荐仅用于 indeterminate 状态，即不显示具体百分比的场景

监听 XMLHttpRequest.upload.onprogress 才算真正对接上传流程

如果目标是“模拟上传进度动画”，但又希望它和真实上传行为一致（比如断网重试、暂停续传），就不能只靠定时器。必须接入原生上传事件链，哪怕当前只是 mock 数据。

关键点：即使不用真实 FormData，也可构造一个带 onprogress 的 mock XMLHttpRequest 实例，或用 fetch + ReadableStream（较新，兼容性稍弱）。

• XMLHttpRequest.upload.onprogress 的 event.loaded 和 event.total 是唯一可靠来源
• 注意：本地测试时，event.total 可能为 0（如 CORS 预检失败或服务端未设 Access-Control-Allow-Headers: Content-Length），此时无法计算百分比
• 别在 onload 里才把 progress 设为 100%——应确保最后一次 onprogress 已覆盖到 100%，否则会有“卡住”感

移动端 Safari 对 progress 的 transition 支持不稳定

iOS 15+ 虽支持

progress，但其内部渲染机制导致 CSS transition 在快速更新 value 时可能丢帧或跳变。实测中，每 100ms 更新一次常出现“阶梯式”前进，而非平滑动画。

解决方法不是加更多 CSS，而是调整 JS 更新节奏 + 启用硬件加速：

• 将更新间隔拉长到 ≥ 160ms（接近 60fps 下限），避免触发渲染瓶颈
• 给 progress 加 transform: translateZ(0) 或 will-change: transform 强制 GPU 渲染
• 慎用 progress::-webkit-progress-bar 的 background 渐变动画——Safari 不支持该伪元素内 animation

进度动画的核心矛盾从来不在“怎么画”，而在于“谁告诉它该走到哪”。mock 时靠定时器，真实上传时靠事件，UI 层只是忠实反映这个数字——别让它猜。