Progress标签本身不自动更新，必须用JavaScript手动设置value属性才能实时反映任务进度；它仅是语义化展示控件，需配合onprogress事件、分片执行或Web Worker等机制实现真实、可访问的动态效果。
Progress 标签本身不自动更新，必须手动控制 value
HTML 的 <progress> 元素只是个“哑控件”——它不会监听任何后台任务，也不会主动读取网络请求进度或定时器状态。你看到的进度条动起来，全靠 JS 主动修改它的 value 属性。常见错误是直接写 <progress max="100"></progress> 就以为能自动跑，结果永远卡在 0%。
使用场景很明确：需要你已有可分段的长任务（比如上传大文件、处理大量数组、执行多个 fetch 请求），且你能估算或实时获取当前完成比例。
实操建议：
-
max建议设为整数（如100或总项数），避免浮点精度问题影响渲染 - 初始状态建议显式设置
value="0"，否则某些浏览器可能显示空白或不确定样式 - 不要用 CSS 动画“模拟”进度（如
@keyframes），这会误导用户，且无法反映真实状态
如何给异步任务（如 fetch）绑定进度更新
原生 fetch 不提供上传/下载进度事件，但 XMLHttpRequest 支持 onprogress；现代方案更推荐用 ReadableStream + Response.body.getReader() 配合分块读取。
立即学习“前端免费学习笔记（深入）”；
如果只是简单上传文件，可用 XMLHttpRequest：
const xhr = new XMLHttpRequest();
xhr.upload.onprogress = (e) => {
if (e.lengthComputable) {
const percent = (e.loaded / e.total) * 100;
document.querySelector('progress').value = percent;
}
};
xhr.open('POST', '/upload');
xhr.send(file);
注意：e.lengthComputable 为 false 时说明服务端没返回 Content-Length，此时无法算百分比，只能用“已接收 X KB”这类模糊提示。
处理不可预估耗时的任务（如密集计算）
纯 CPU 密集型任务（如遍历百万级数组做运算）会阻塞主线程，导致 progress 根本无法重绘——即使你频繁改 value，页面也卡死不动。
必须拆分任务并让出主线程：
- 用
setTimeout或queueMicrotask分片执行，每片后更新一次value - 更优解是迁移到
Web Worker，由 Worker 发送postMessage({ type: 'progress', value: 42 })，主线程监听并更新<progress> - 避免在循环里直接写
progress.value = i / total * 100—— 这样 99% 的赋值会被浏览器合并丢弃，只看到“跳变”
兼容性与无障碍注意事项
<progress> 在所有现代浏览器中支持良好，但 IE10+ 才支持，且 IE 不支持 indeterminate（即无具体数值的“转圈”态）。若需 fallback，可用 <div role="progressbar" aria-valuenow="35" aria-valuemin="0" aria-valuemax="100"></div> 配合 CSS 模拟。
关键细节容易被忽略：
- 必须设置
aria-label或aria-labelledby，否则屏幕阅读器无法播报进度 - 不要仅靠颜色表达状态（比如绿色=完成），要加文字提示，例如旁边放一个
<span id="progress-text">已完成 67%</span> - 移动端 Safari 对快速连续更新
value渲染有延迟，建议限制更新频率（如不低于 50ms 间隔）
真正难的不是让进度条动起来，而是让它的数值和用户感知一致——这要求你对任务分段足够合理，对误差有诚实交代，对失败有明确回退路径。
