进度条解决的是什么问题
用户等待时最怕的不是慢，而是“不知道还要多久”。js进度条的核心价值，是把不确定的等待变成可预期的过程。它分两类：一类是确定性进度，对应可计算总量的任务，比如文件上传、分片加载；另一类是不确定性进度，用于无法预估时长的操作，通常表现为循环动画或缓慢逼近的假进度。
做进度条之前先想清楚属于哪一类，否则容易出现“进度条走完了，任务还没结束”的尴尬。
最小可用实现
一个原生 js进度条，本质是两层结构：外层轨道、内层填充。进度值通过宽度百分比或 CSS 变量驱动。
结构
样式
.progress { height: 8px; background: #e8e8e8; border-radius: 4px; overflow: hidden; }
.progress__bar { height: 100%; width: 0; background: #2f6fed; transition: width .2s ease; }
逻辑
function setProgress(el, value) {
const v = Math.max(0, Math.min(100, value));
el.querySelector(‘.progress__bar’).style.width = v + ‘%’;
el.setAttribute(‘aria-valuenow’, v);
}
关键点有三个：一是百分比钳制，避免越界；二是同步无障碍属性，让读屏软件能读到进度；三是过渡时间不要过长，否则高频更新时会显得迟钝。
让进度真实可信的几种策略
分片任务用“完成数 ÷ 总数”
文件分片上传时，每片成功回调就累加计数，再换算成百分比。这比按字节估算更稳，因为网络抖动不会让进度倒退。
长任务用“阶段权重”
一个包含下载、解析、写入三步的操作，可以给每步分配权重，比如 50%、30%、20%，按阶段推进。这样即使某一步耗时波动，整体进度也平滑合理。
无法预估时用“渐近曲线”
没有总量信息时，可以让进度缓慢逼近 90%，等任务真正完成后跳到 100%。常见做法是按时间做缓动，避免涨得太快后长时间卡住。
常见坑与优化
频繁重排：每毫秒更新一次宽度会造成大量样式计算。用 requestAnimationFrame 合并更新，或把进度写入 CSS 变量，让浏览器批量处理。
动画与数据脱节：CSS 过渡会让视觉值滞后于真实值。对精度要求高的场景，直接设置宽度并去掉过渡，或缩短到 100ms 以内。
进度倒退：并发任务汇总时，后完成的任务可能拉低总进度。解决办法是只允许进度单调递增，取历史最大值。
忽略可访问性：给容器加上 role="progressbar" 和 aria-valuenow，并在完成时更新。这是低成本高收益的细节。
小结
js进度条的技术难度不高，难在“诚实”和“流畅”。先判断进度是否可计算，再选择合适的推进策略，最后处理更新频率与无障碍属性，基本就能覆盖大多数业务场景。把它当成交互契约而不是装饰，用户对等待的容忍度会明显提高。
