最稳纯CSS进度条需JS控制width实时更新，CSS仅负责transition；关键点：子元素设初始width:0%、overflow:hidden、transition:width 0.3s ease-out；完成时用width+opacity双过渡收尾。
用 width 过渡 + @keyframes 模拟进度条最稳
纯 CSS 实现动态加载进度条，核心是控制一个条形元素的 width 从 0% 到 100% 的变化。但直接用 @keyframes 写死动画时长（比如 2s）会脱离真实加载节奏——它只适合「伪加载」或视觉占位。真要匹配后端响应时间，必须靠 JS 控制 width 值，CSS 只负责过渡效果。
常见错误现象：transition: width 1s 生效了，但进度条卡在中间不动，或者跳变明显。原因通常是：没设初始 width、没加 overflow: hidden、或者 JS 设置的是 element.style.width = '50%' 但元素本身有内边距/边框干扰计算。
- 确保进度条容器有明确
height和overflow: hidden - 进度条子元素用
display: block，width设为0%初始值 - 过渡必须写在子元素上：
transition: width 0.3s ease-out，别写在父容器 - 避免用
max-width或flex-basis替代width，它们不触发同一类重排逻辑
JS 控制宽度时为什么推荐用 style.width 而不是 classList
用 classList.add('progress-30') 配合一堆预设 class（如 .progress-30 { width: 30%; }）看似干净，但实际不可控：你无法在任意时刻设置 37.2%，也无法做连续插值；而真实加载中，进度往往是非整数、非等间隔的。
使用场景很明确：需要实时反映后端返回的 loaded / total 比例，比如上传文件、fetch 加载、WebSocket 接收分块数据。
立即学习“前端免费学习笔记（深入）”；
- 直接操作
el.style.width = (loaded / total * 100) + '%'是最直接的方式 - 注意除零保护：当
total === 0时，建议设为'0%'或退回到不确定状态（如加indeterminate类） - 如果用 React/Vue，别在每次更新都重新设置
style.width，优先用内联 style 绑定，避免重复 DOM 写入 - 不要用
getBoundingClientRect()反推宽度再设回去——纯属绕路
transition-timing-function 选 ease-out 而不是 linear
线性过渡看着“准”，但人眼会觉得进度条启动慢、收尾急，尤其在 0→20% 和 80→100% 区间特别明显。真实加载通常前期快（DNS、TCP）、中期稳、末期可能因校验/渲染稍拖一点，ease-out 更贴合这种感知。
性能影响很小，但兼容性要注意：ease-out 在所有现代浏览器都支持，但如果你用到 cubic-bezier(0.2, 0.6, 0.4, 1) 这种自定义曲线，在老 Android WebView 上可能降级为 linear。
- 别用
steps(10, end)模拟“跳格子”效果——它和进度条语义冲突，用户会误以为卡顿 - 如果产品要求“匀速感”，宁可用
linear，也别硬套ease-in-out，后者中间段太慢，容易让人觉得卡住 - 过渡时长建议设
0.2s ~ 0.4s：短于0.15s人眼难识别变化，长于0.5s显得迟滞
隐藏但关键：如何处理加载完成后的状态收尾
进度条走到 100% 后，不能让它停在那里不动，也不能立刻消失——突兀的消失会让用户疑惑“到底成没成”。更自然的做法是：保持满宽 0.2 秒，再淡出或收缩回 0。
容易被忽略的点在于：很多人用 opacity: 0 隐藏，但没关掉 pointer-events，导致后续点击穿透；或者用 display: none，但 transition 不生效，造成闪烁。
- 推荐组合：
transition: width 0.2s ease-out, opacity 0.2s ease-out，先稳住width: 100%，再同时缩宽+变透明 - 收尾时设
opacity: 0; width: 0%，并加pointer-events: none防交互干扰 - 如果用 CSS 动画（
@keyframes）做收尾，记得用animation-fill-mode: forwards，否则动画一结束就回退 - 别依赖
animationend事件清理 DOM——它可能不触发（如动画被中断），JS 主动控制更可靠
