进度条不更新因value/max非数字类型，需用number()或parseint()转换；避免在循环中直接赋值；确保html语法正确。
直接用 <progress></progress> 标签但页面没反应？检查这三点
多数人贴完 <progress value="20" max="100"></progress> 就以为完事了，结果进度条卡在 0% 或压根不更新。核心问题不是写法错，而是浏览器根本不“认”这个值变化。
-
value和max必须是数字类型——字符串"50"会导致计算失效，务必用Number()或parseInt()转一下 - 别在循环里直接赋值：
for (let i = 0; i 这样浏览器来不及重绘，看起来就是“跳到 100%” - IE11 及以下完全不支持
<progress></progress>，在线运行环境若兼容旧版，得 fallback 到<div class="bar"></div>+ CSS 宽度控制
CSS 自定义 <progress></progress> 时伪元素失效？浏览器规则不统一
Chrome 要靠 ::-webkit-progress-value 控制进度色块，Firefox 却只认 appearance: none + 整体背景覆盖，而 Safari 对 ::-webkit-progress-bar 的支持又经常抽风。
- 所有浏览器下，
<progress></progress>默认是inline元素，不设display: block就没法调width或height - Chrome 中若给
::-webkit-progress-value加display: block，宽度计算会崩，必须保持display: inline-block（或不设） - 最简兼容写法：先重置通用样式（
border: none; height: 6px;），再分浏览器覆盖——progress::-webkit-progress-value { background: #4CAF50; }+progress::-moz-progress-bar { background: #4CAF50; }
不想写 JS 也能有呼吸式加载动画？用 <div> + <code>@keyframes 更稳
在线运行平台（如 JSBin、CodePen）常禁用或延迟执行 JS，纯 CSS 方案反而更可靠。关键是别用 <progress></progress> 套壳，结构用 <div class="loader"></div>，动画靠 ::before 模拟填充过程。
- 只动
width会抖动，必须同步控制opacity：从0%的width: 0%; opacity: 0.4;到100%的width: 100%; opacity: 1; - 动画时长建议 1.5–2s，
ease-in-out比linear更自然；太短看不出过程，太长像假死 - 别依赖
content: ""的伪元素高度继承——显式设height: 100%或top/bottom: 0，否则 Safari 里可能塌陷
上传或 AJAX 真实进度怎么接？event.lengthComputable 是开关
很多在线运行示例直接用 setTimeout 模拟进度，但真要连后端，XMLHttpRequest.upload.onprogress 或 fetch + ReadableStream 才是正路。第一步永远是判断能否计算长度。
- 没服务端配合时，
event.lengthComputable一定是false，此时强行读event.loaded / event.total会得NaN - 后端必须返回
Content-Length响应头，否则浏览器无法知道总大小；Node.js/Express 需手动加res.set('Content-Length', size) - 高频触发的
onprogress事件必须节流——用requestAnimationFrame更新 DOM，别用setInterval或无限制console.log
真正容易被忽略的是：在线运行环境往往屏蔽了跨域请求和部分响应头，Content-Length 拿不到、onprogress 不触发，这时候模拟进度反而是合理选择——先确保视觉反馈存在，再解决真实数据链路。
