用两个div嵌套而非progress元素，因原生progress样式兼容性差（ie不支持、各浏览器伪元素不一致），双div方案可完全自定义样式且兼容ie9+；过渡动画必须作用于内层div的width属性，且width需设明确初始值（如0%），禁用max-width；仅过渡width最轻量兼容，避免all或transform引发问题；js更新时需防抖、清旧定时器、处理浮点误差并确保dom就绪。
为什么用两个 div 嵌套，而不是单个 progress 元素
因为原生 <progress></progress> 标签样式极难统一控制：Chrome、Firefox、Safari 对 appearance、::-webkit-progress-bar 等伪元素的支持不一致，且 IE 完全不支持自定义；而双 div 方案完全由你掌控背景、圆角、动画、文字位置等所有细节，兼容性覆盖 IE9+。
常见错误是直接给外层 div 加 transition，结果内层宽度变化时毫无动画——过渡效果必须写在**内层元素**的 CSS 里。
width 必须设初始值，且不能用 max-width 替代
内层 div 的 width 必须有明确起始值（如 0% 或 10%），否则浏览器无法计算过渡起点，动画会跳变或失效。
-
max-width不触发重排动画，视觉上卡顿，仅适合做安全上限，不能当进度值用 - 百分比单位（
%）最稳妥，避免因父容器尺寸未定导致计算异常 - 若需 JS 动态更新，直接操作
element.style.width = '65%'即可，无需getComputedStyle反查
CSS 动画性能关键点：只过渡 width，别碰 transform 或 left
用 width + transition 是最轻量、最兼容的方案；若改用 transform: scaleX() 虽然硬件加速，但会破坏内层文字居中（需额外 transform-origin 调整），且 Safari 对 scaleX(0) 的渲染有偶发闪烁。
示例关键样式：
.progress-bar {
height: 8px;
background: #e0e0e0;
border-radius: 4px;
overflow: hidden;
}
.progress-fill {
height: 100%;
background: #4caf50;
border-radius: 4px;
width: 0%;
transition: width 0.3s ease;
}
注意：不要加 all 0.3s，只过渡 width，避免意外触发动画重绘。
JS 更新时容易忽略的边界与时机问题
直接用定时器递增 width 百分比时，常见坑包括：
- 没做防抖：用户多次点击触发多个
setInterval，造成进度飞快或错乱 - 没清空旧定时器：
clearInterval(timer)必须在新定时器启动前执行 - 百分比计算浮点误差：用
Math.round(value / total * 100)而非Math.ceil，避免最后一步跳到 101% - DOM 未就绪就操作：确保脚本在
DOMContentLoaded后运行，或把<script></script>放在 body 底部
真正复杂的不是怎么动起来，而是怎么在各种异步场景（API 返回、WebSocket 推送、表单提交回调）里稳定、可中断、可回退地更新那个 width 值。
