transition无法直接作用于<progress>的value属性，因其非CSS属性；伪元素width由浏览器自动计算且不触发transition；Firefox支持更弱；推荐用div模拟进度条并控制width动画。
transition 能让进度条视觉上平滑变化，但直接作用在 <progress> 的 value 上无效——浏览器不把 value 当 CSS 属性处理，所以必须绕过它，操作底层可动画的样式。
为什么 transition: width 在 <progress> 上经常失效
你写了 progress::-webkit-progress-value { transition: width 0.3s ease; }，但发现动画没触发，常见原因有三个：
- 伪元素（如
::-webkit-progress-value）的width是由浏览器根据value/max自动计算的，不是你手动设置的 CSS 值，transition对“隐式计算值”不响应 -
max值变动时，即使value不变，填充宽度也会重算，但这个过程不走 CSS 动画管线 - Firefox 的
::-moz-progress-bar对transition支持更弱，部分版本完全忽略
用自定义 DOM + transition 替代原生 <progress>
最稳的方式是不用 <progress>，改用两个 <div>：外层容器 + 内层填充块。这样你能完全控制 width、transition 和响应逻辑。
- 结构简单：
<div class="progress-bar"><div class="progress-fill"></div></div> - CSS 关键点：
.progress-fill { transition: width 0.3s cubic-bezier(0.25, 0.1, 0.25, 1); }—— 推荐用cubic-bezier替代ease，避免结尾拖沓 - JS 更新只需一行：
el.querySelector('.progress-fill').style.width = `${percent}%`;，percent是 0–100 的数值 - 注意：外层容器要设
overflow: hidden，否则填充块超出时会溢出
transition 配合百分比 vs px 单位的坑
如果你用 width: calc(var(--p) * 1%); + transition: width，看起来没问题，但实际可能卡顿或跳变：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
calc()中混用单位（如var(--p) * 1px）在 Safari 旧版会解析失败，回退为 0 - 百分比宽度在 flex 容器里受
flex-basis影响，transition可能被截断 - 更可靠的做法是：固定外层宽度（如
width: 300px），内层用width: 120px（即 40%），JS 直接更新像素值，避免任何计算依赖
动画中断与重置时的边界问题
用户中途取消任务、或进度从 80% 回退到 30%，transition 会自然反向动画——这看似合理，但容易暴露两个细节问题：
- 如果新目标值小于当前值，且你用的是
setTimeout或requestAnimationFrame逐步更新，transition会叠加多次，导致“抖动” - 连续快速调用
updateProgress(10); updateProgress(90);，中间过渡帧可能被丢弃，最终只看到 10→90 的单次动画 - 解决方法：每次更新前加
el.style.transition = 'none';瞬间跳到起点，再设回transition并更新目标值，强制重置动画状态
真正让 transition 发挥作用的，不是堆参数，而是控制好谁在变、怎么变、在哪变。原生 <progress> 的语义好，但动画控制权太弱；手写结构看似多几行，却把主动权牢牢攥在自己手里。
