<progress> 元素是静态显示控件，需用 JavaScript 手动更新 value 属性；它无内置计时或事件机制，依赖外部逻辑驱动，常见错误是仅写 HTML 而不配 JS 导致进度条不变化。
<progress> 元素本身不主动更新，它只是个“哑巴”显示控件——你得自己用 JavaScript 定期设置它的 value 属性，否则它永远停在初始状态。
为什么直接写 <progress value="30"> 不会动
静态 HTML 中的 value 是只读快照，浏览器不会监听后续 JS 对 DOM 属性的修改（除非你显式赋值）。更关键的是：原生 <progress> 没有内置计时、轮询或事件驱动机制，它完全依赖外部逻辑驱动。
- 常见错误现象：
<progress id="p">写在页面里，但没配 JS，进度条始终空白或卡在 0% - 使用场景：文件上传、批量数据处理、Canvas 渲染循环、Web Worker 中分片计算等需暴露中间状态的任务
- 性能影响：频繁设置
progress.value = n本身开销极小，但若每毫秒都设一次，反而可能触发过度重绘；建议按实际阶段（如每 1% 或每 50ms）节流更新
如何配合 Promise / async 函数做阶段性更新
不能把整个长任务塞进一个 await 里再一次性更新——那样用户看到的仍是“卡住→突变到 100%”。必须拆解为可观察的子步骤，并在每个步骤后手动推进 progress.value。
- 不要这样写：
await longTask(); progress.value = 100;（无中间反馈） - 应该这样拆：
for (let i = 0; i - 注意兼容性：
progress.max默认是 100，但你可以设成任意正数（比如总文件字节数），然后让value等于已处理字节数——此时浏览器自动换算百分比 - 示例中避免用
setTimeout模拟耗时（易导致 UI 阻塞），优先用requestIdleCallback或queueMicrotask让出主线程
与 Web Worker 配合时怎么安全更新 <progress>
Worker 无法直接操作 DOM，所以不能在 Worker 里写 document.getElementById(...).value = ...。必须通过 postMessage 把进度数据发回主线程，由主线程更新 <progress>。
立即学习“前端免费学习笔记（深入）”；
- Worker 内：每次完成一部分后调用
self.postMessage({ type: 'progress', value: 42 }); - 主线程：监听
worker.onmessage = e => { if (e.data.type === 'progress') progress.value = e.data.value; } - 容易踩的坑：Worker 发送太频繁（如每毫秒一条消息）会导致主线程消息队列积压，UI 卡顿；应在 Worker 内做简单节流，比如“每处理 100 条记录才发一次”
- 别忘了设置
progress.max和初始value，否则第一次收到value=30时可能因max还是默认 1，导致显示异常
最常被忽略的一点：很多人以为 <progress> 支持 aria-live 自动播报，但实际上它需要显式加 role="progressbar" 和 aria-valuenow 才能被屏幕阅读器识别——光靠 value 属性不够。
