width百分比+transition最稳妥，因它依赖父容器可计算宽度上下文，只要父容器有明确宽度（如width:100%、max-width:100%或flex:1），width:65%即可随父缩放；失效主因是父容器无宽、position:absolute未设宽、inline元素无块级约束、min-width覆盖或transition未写在起始状态且缺少初始width值。
直接用 width 百分比 + transition 是最稳妥、兼容性最好、也最容易调试的方案。其他花哨写法（比如 background-position 或 transform: scaleX()）在真实业务中反而容易翻车。
为什么 width 百分比能响应式？
不是因为写了 % 就自动响应，而是它依赖父容器的“可计算宽度上下文”。只要父容器有明确宽度（比如 max-width: 100%、width: 100% 或是 flex 子项且父级设了 flex: 1），width: 65% 就会随父容器缩放自动调整——这是 CSS 流式布局的天然能力。
常见失效场景：
- 父容器是
position: absolute且没设width或left/right - 进度条套在
display: inline元素里，父级没块级约束 - CSS 中写了
min-width: 200px，强行覆盖百分比逻辑
transition: width 动不起来？先查这几点
transition 不是“加了就动”，它对起始状态有硬性要求：
- 元素必须有初始
width值（比如width: 0%），不能是auto或未声明 -
transition: width 0.3s ease必须写在起始 CSS 规则里，不能等 JS 改完再动态加 - 父容器要设
overflow: hidden，否则进度条溢出看不见动画 - 务必设
box-sizing: border-box，否则padding和border会挤占width空间
JS 更新 width 的安全写法
直接写 el.style.width = '73%' 最简单，但容易出问题：
- 避免连续快速调用（如每 10ms 改一次），推荐用
requestAnimationFrame驱动 - 重置进度时，先设
el.style.width = '0%'，再设目标值，否则可能跳变 - 别用
max-width或flex-basis替代width——它们不触发同一类重排逻辑，transition不生效 - 内联样式优先级高于 CSS 类，如果类里写了
transition却被更高优先级样式覆盖，动画就失效
别碰原生 <progress></progress> 元素
它的 value 属性无法被 transition: width 驱动——写上去完全无效。WebKit 内核虽支持 ::-webkit-progress-value 伪元素 + background-color 过渡，但 Firefox 和新 Edge 行为不一致。
真正稳定的做法：放弃 <progress></progress>，改用 <div role="progressbar" aria-valuenow="65"> + 自定义填充层，并确保 <code>aria-valuemin 和 aria-valuemax 同步更新。
最易被忽略的一点：动画卡顿往往不是 transition 本身的问题，而是 JS 频繁读取 offsetWidth 触发了同步布局。只要不主动读尺寸，只写 style.width，90% 的卡顿就消失了。
