transition 对 progress 元素无效，因其是浏览器控制渲染的替换元素，value 属性不可动画；需用 div 模拟进度条，通过 transform: scalex() + requestanimationframe 同步 audio 状态实现平滑过渡。
transition 为什么对 progress 元素无效
因为原生 <progress> 是替换元素（replaced element），它的内部渲染由浏览器控制，CSS 无法直接过渡其“进度值”——你写的 transition: width 0.3s 或 transition: transform 0.3s 都不会生效，哪怕它看起来是个条形图。
常见错误现象：progress 值突变、跳变，没有滑动感；开发者试图给 progress[value] 加 transition，完全没反应。
- 真正能被 CSS 过渡的，只有你可控的 DOM 属性：比如自定义容器的
width、transform、background-position - 原生
<progress>的value属性是“只写触发”，不映射为可动画的 CSS 属性 - 兼容性上，所有现代浏览器都一致：不支持直接过渡
<progress>的视觉变化
用 div 模拟进度条 + transition 的最小可行方案
核心思路：放弃原生 <progress>，用 <div class="progress-bar"><div class="progress-fill"></div></div> 结构，靠 JS 更新 progress-fill 的 width 或 transform，再加 CSS 过渡。
推荐用 transform: scaleX() 而非 width：避免重排（layout），性能更稳，尤其在音频频繁更新（如 requestAnimationFrame 驱动）时。
立即学习“前端免费学习笔记（深入）”；
.progress-fill { transform-origin: left center; transition: transform 0.15s cubic-bezier(0.4, 0, 0.2, 1); }- JS 更新时写：
fillEl.style.transform = `scaleX(${currentTime / duration})`（注意归一化到 0–1） - 务必设
transform-origin，否则缩放会从中心出发，导致左右晃动 - 别用
ease-in-out——音频进度是线性推进的，用缓动会让人感觉“拖沓”或“抢拍”
audio currentTime 变化太密，transition 被打断怎么办
当音频播放中频繁调用 audio.currentTime = x（比如拖拽后校准、或 seek 完立刻更新），CSS 过渡会被新值中断，出现“卡顿回弹”。这不是 transition 写错了，而是浏览器在丢帧。
关键点：transition 不是“动画队列”，它只响应最终的样式计算结果。如果 JS 在一帧内多次改 style，只最后一次生效。
- 用
requestAnimationFrame聚合更新：把进度更新逻辑节流到每帧一次，而不是每次timeupdate都设 style - 避免在
timeupdate里直接操作 DOM；改用raf缓存当前值，再统一应用 - 如果用了
transform，确保父容器没触发will-change: transform以外的重绘属性（比如意外改了color） - 测试时关掉 DevTools 的“Disable cache”，某些浏览器在调试模式下会降级 transition 性能
移动端 touch 拖拽进度条时的过渡断裂
手指拖动时，你手动设置了 progress-fill 的宽度，但松手瞬间 transition 突然跳回——这是因为松手后 JS 继续监听 timeupdate，而此时 audio 的 currentTime 还没追上你拖的位置，造成“视觉滞后”。用户会明显感到“松手后条子自己蹦一下”。
解决不是靠加 transition-delay，而是靠状态同步策略。
- 拖拽开始时，暂停 audio 的
timeupdate监听，避免干扰 - 拖拽中，只更新 UI，不调
audio.currentTime（避免触发播放器内部重算） - 拖拽结束瞬间，先设
audio.currentTime，再立即读取它的真实值（可能被播放器微调过），用这个值去更新 UI —— 这样 UI 和 audio 才真正对齐 - 别依赖
seeking事件来恢复监听：它触发时机不稳定，seeked更可靠，但仍有 10–50ms 延迟
平滑感真正的瓶颈不在 transition 写法，而在 JS 更新节奏和 audio 状态同步的时机。这点容易被忽略，但恰恰决定用户是否觉得“这播放器很跟手”。
