<progress>标签需同时设置合法数字型value和max属性才能显示确定进度，否则退化为不确定状态；动态更新须用JavaScript直接赋值element.value并校验范围，CSS定制依赖浏览器特定伪元素且须先设appearance:none。
<progress> 标签本身不是“模板”，它是个语义化原生元素，直接写进 HTML 就能用；所谓“制作进度条模板”，其实是把结构、样式、行为三者封装成可复用的最小单元——重点不在“怎么套模板”，而在“怎么避免每次重踩同样的坑”。
为什么<progress>写了却看不见进度
最常见原因：只写了标签，没设 value 和 max，或值类型不对。
-
value缺失 → 浏览器渲染为“不确定”状态（动画条或空白），不是你想要的确定进度 -
max缺失 → 默认是1，所以<progress value="0.7"></progress>能显示 70%，但<progress value="70"></progress>实际是 7000%，被截断为 100% -
value="70"是字符串 → 部分浏览器忽略，进度卡在 0%；必须用el.value = 70或el.value = Number("70") -
max="100"写成max="100px"或max=""→ 值非法，整个进度条退化为不确定模式
用 CSS 自定义样式时伪元素为什么没生效
因为不同引擎控制内部结构的方式完全不同，通用 CSS 对填充部分无效。
- Chrome / Edge 必须用
::-webkit-progress-bar控制轨道、::-webkit-progress-value控制已加载部分 - Firefox 只支持
::-moz-progress-bar，且::-moz-progress-value基本不可靠，建议整块覆盖背景色 - Safari 对伪元素支持更保守，
appearance: none是前提，否则自定义会被忽略 -
background-image在::-webkit-progress-value上多数失效，优先用background: linear-gradient(...) - 所有浏览器下，
<progress>默认是inline元素，要设宽高必须先加display: block
JavaScript 动态更新时 UI 卡住或跳变
进度条本身不节流、不防抖，你给多快，它就试图重绘多快——但浏览器扛不住高频 DOM 属性变更。
立即学习“前端免费学习笔记（深入）”；
- 别在
for循环里连续赋值progress.value = i++，会阻塞主线程，页面假死 - 用
requestAnimationFrame替代setTimeout或普通循环，保证每帧最多更新一次 - 上传类场景必须校验
event.lengthComputable，否则event.loaded / event.total会是NaN - 多个异步任务并行时（如并发 fetch），后到的响应可能覆盖先到的中间值，需用计数器 + 总数推算，而非直接取响应里的百分比
- 中断请求（如
AbortController）后，记得手动设progress.value = 0并清理定时器，否则残留状态误导用户
什么时候不该用<progress>标签
它语义明确，但也因此有硬约束——不是所有“看起来像进度”的东西都适合它。
- 接口还在等响应，总大小未知 → 不该用，应改用
<div role="progressbar" aria-valuetext="加载中">+ ARIA 属性 - 只是装饰性百分比（如“用户完成度 85%”，无实时计算依据）→ 更适合
<meter>，它表示标量测量，不暗示任务流程 - 需要拖拽调节（如音量条、时间轴）→
<progress>不支持交互，得换<input type="range"> - 项目需兼容 IE11 及以下 → 它完全不支持，必须降级为
<div class="progress"><div class="progress-fill"></div></div>+ CSS 宽度 + ARIA - 进度值来自第三方 SDK（如 Sentry、Plausible 的加载钩子），但返回的是字符串或对象 → 必须先提取数字再赋给
.value，绕过属性直接改style.width会破坏语义和无障碍
真正容易被忽略的是：即使样式调好了、JS 更新也节流了，如果后端没返回 Content-Length 或没启用 Transfer-Encoding: chunked，前端根本算不出真实百分比——这时候硬塞一个“65%”不是优化体验，是在制造信任漏洞。
