progress标签不自动更新，必须用javascript手动设置value属性才能动态显示进度；需显式设置max、确保value为数字且在0到max范围内，并配合节流、边界校验和初始化操作以避免不确定态或渲染异常。
progress 标签不自动更新，必须手动设 value 才能动
<progress></progress> 是个“哑控件”——它不会监听 fetch、定时器或循环状态，只按你给的 value 和 max 渲染。写 <progress max="100"></progress> 就放那儿，进度条永远卡在 0%。
常见错误包括：
- 只设
value没设max（浏览器按默认max="1"解析，value="50"变成 5000%，实际渲染异常） - 用
setAttribute('value', '65')而不是el.value = 65（前者只改 HTML 属性，不触发 DOM 值更新，Safari 下尤其失效） - 传字符串如
"65"或"0.7"（虽多数浏览器会隐式转数字，但旧版 Firefox/IE 可能静默失败）
value 和 max 怎么设才不出错
关键不是“怎么好看”，而是“怎么不退化”。一旦 value 超出 [0, max] 区间，<progress></progress> 会静默回退到不确定态（条纹动画），用户看不到任何数值反馈。
实操建议：
-
max必须显式设置：上传用max="100"，处理 2489 条数据就用max="2489"，避免浮点除法舍入误差 -
value严格用数字：从 API 拿到的字符串进度先转Number(data.progress)或+data.progress - 边界强制校验：
bar.value = Math.min(Math.max(0, computedValue), bar.max) - 任务开始前初始化：
bar.value = 0；结束时补足：bar.value = bar.max，防止因网络抖动或计算误差卡在 99%
怎么避免高频更新导致卡顿或跳变
在密集循环或 onprogress 回调里每毫秒都写 bar.value = i，看似精准，实则浪费——浏览器会合并重排，用户只看到“0% → 100%”跳变，低端设备还可能卡死。
真正有效的更新节奏：
- 用
requestAnimationFrame把赋值让出到下一帧，不阻塞主线程 - 加变化阈值：只在
Math.abs(newVal - bar.value) >= 1时才更新（百分比场景）或 ≥ 10（计数类场景） - 纯 CPU 密集任务（如遍历百万数组）必须分片：用
setTimeout或queueMicrotask拆成小块，每块后更新一次value - 别在 for 循环里直接写
bar.value = i / total * 100——中间 99% 的赋值毫无意义
fetch 场景下怎么拿到真实下载进度
原生 fetch 不提供 onprogress 事件，<progress></progress> 拿不到 loaded/total，硬写定时器模拟会失真。
可行路径只有两条：
- 上传用
XMLHttpRequest：监听xhr.upload.onprogress，检查e.lengthComputable，再算(e.loaded / e.total) * 100 - 下载用
Response.body.getReader()：配合ReadableStream分块读取，累加bytesRead，再对比content-lengthheader（需服务端返回该 header，否则e.lengthComputable为false） - 如果服务端不返回
Content-Length，就别硬算百分比——改用模糊提示：“已接收 3.2 MB” 或 “正在解压…”
真正难的从来不是怎么让 <progress></progress> 动，而是怎么从异步深处捞出那个准确的当前值：它可能藏在 Web Worker 的 postMessage 里，Canvas 渲染帧的计数中，或者第三方库的回调参数里。盯着标签本身，解决不了问题。
