progress标签必须同时设置value和max属性且value≤max才能正确显示确定进度；仅设max或value超限会导致不确定状态或渲染异常；动态更新需同步aria属性，网络异步任务应避免使用。
progress标签必须设value和max才能显示进度
不设value时，<progress></progress>会变成“不确定进度”状态（浏览器渲染为动画条），哪怕你写了max="100"也没用。必须同时指定value和max，且value ≤ max，否则进度条不渲染或显示异常。
常见错误写法：<progress max="100"></progress> → 看不到数值进度；<progress value="120" max="100"></progress> → Chrome 会显示但值被截断，Firefox 可能不渲染。
-
value和max都必须是数字，不能是字符串（如value="50"可，value="50%"不行） - 省略
max时默认为1，此时value只能是0或1（实用价值极低） - 动态更新时直接改
element.value即可，无需重写整个标签
用CSS定制progress样式要注意浏览器前缀差异
Chrome/Edge 用::-webkit-progress-bar和::-webkit-progress-value；Firefox 用::progress-bar（仅较新版本支持）；Safari 对progress的伪元素支持有限，旧版甚至不支持自定义。纯CSS方案无法全兼容，必须降级处理。
安全做法是：先用appearance: none清空默认样式，再对 WebKit 内核做精细控制，Firefox 用background兜底，Safari 建议加一层包裹容器做视觉模拟。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
::after覆盖进度条——progress是替换元素，伪元素行为不稳定 -
height在不同浏览器中表现不一，建议用min-height+line-height辅助对齐 - 无障碍需保留原生语义，别用
div+aria-valuenow完全替代（除非有强定制需求）
JavaScript动态更新value时别忘了同步aria属性
屏幕阅读器依赖aria-valuenow、aria-valuemin、aria-valuemax识别进度，而原生progress只自动同步value和max到对应aria-属性——但仅限初始渲染。JS修改value后，部分读屏器（尤其是NVDA旧版）不会自动抓取新值。
稳妥做法是在设置el.value = x后，手动同步aria-valuenow：
const bar = document.querySelector('progress');
bar.value = 65;
bar.setAttribute('aria-valuenow', '65');
- 如果用了
max非100的值（比如max="24"），aria-valuemax也得同步设 - 避免用
innerHTML更新——会销毁原生进度状态和事件绑定 - 监听
progress的change事件比input更可靠（它只在value实际变化时触发）
progress不适合表示加载中的异步任务（比如fetch）
原生progress要求明确的max和可测量的value，但多数网络请求无法预知总大小（如流式响应、chunked transfer），或者根本没提供Content-Length。硬套progress会导致value乱跳、卡死，或只能做成不确定状态（失去意义）。
- 真要显示上传进度，优先用
XMLHttpRequest.upload.onprogress+ 服务端返回Content-Length - 下载场景可用
response.headers.get('content-length')配合ReadableStream分块计算，但实现复杂 - 不确定进度请用
<progress></progress>不设value，或改用<div role="progressbar" aria-valuetext="加载中...">更可控 原生<code>progress最稳的场景就两种：确定步数的任务（如表单多步提交）、已知总量的本地计算（如文件解析进度）。一旦涉及网络、流、或用户不可控的耗时操作，就得换思路——不是标签不好，是它设计上就不为那些场景服务。
