用 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 层只是忠实反映这个数字——别让它猜。
