audio.currentTime 是音频当前播放位置（秒），但需等媒体就绪（readyState≥2）才能赋值生效，否则可能无效或报错；跳转后需显式调用play()，且拖动进度条时应防抖并监听seeked事件。
audio.currentTime 是什么，为什么不能直接赋值就生效
currentTime 是 <audio> 元素的可读写属性，表示当前播放位置（单位：秒）。但它不是“设了就跳”，而是依赖媒体是否已加载元数据和是否处于可播放状态。常见现象是：刚加载完 <audio> 就执行 audio.currentTime = 30，结果没反应，甚至抛出 InvalidStateError。
根本原因是：浏览器尚未解析出时长（duration 为 NaN），或资源还没准备好播放（readyState < 2）。所以必须等 loadedmetadata 或 canplay 事件触发后再操作。
点击按钮跳转到 45 秒，最简可靠写法
不要在 DOM 加载完就立刻绑定跳转逻辑，而要把跳转动作包裹在媒体就绪检查中。推荐用 canplay 事件——它比 loadedmetadata 更稳妥，因为此时音频已能播放，duration 和 currentTime 都可用。
<audio id="myAudio" src="song.mp3"></audio>
<button onclick="jumpTo(45)">跳到 45 秒</button>
<script>
const audio = document.getElementById('myAudio');
function jumpTo(seconds) {
if (audio.readyState >= 2) {
audio.currentTime = seconds;
audio.play().catch(e => console.warn('自动播放被阻止：', e));
} else {
audio.addEventListener('canplay', () => {
audio.currentTime = seconds;
audio.play().catch(e => console.warn('自动播放被阻止：', e));
}, { once: true });
}
}
</script>
-
readyState >= 2表示至少已加载足够数据可开始播放（HAVE_ENOUGH_DATA） -
{ once: true }确保事件只监听一次，避免重复绑定 -
play().catch()不可省略——现代浏览器普遍禁止静音外的自动播放，用户需有交互（如点击）后才能触发播放，否则会报NotAllowedError
跳转后不播放？检查这三件事
即使 currentTime 赋值成功，音频也可能保持暂停。这不是 bug，而是行为预期。HTML5 音频不会因修改 currentTime 自动恢复播放。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 用户点击按钮本身是有效交互，但如果你在回调里只改
currentTime，没调play()，它就停在那 - 如果音频之前是暂停状态，跳转后仍暂停；如果之前正在播，跳转后继续播（除非被中断）
- 部分安卓 WebView 或旧版 iOS Safari 对
play()的调用时机敏感，建议把play()放在setTimeout(..., 0)中兜底（仅当首次调用失败时）
用 range input 拖动进度条时，如何避免跳转抖动
用 <input type="range"> 同步控制 currentTime 时，常见问题是拖动过程中频繁触发 change 或 input 事件，导致多次赋值、卡顿甚至跳回原位置。
- 优先监听
input事件（而非change），以获得实时拖动反馈 - 在事件处理中加防抖：用
requestAnimationFrame批量更新，比setTimeout更精准 - 别在拖动时反复调
play()——只在松手（mouseup或touchend）后调一次即可 - 注意：
audio.duration可能为Infinity（流式直播源），此时无法用百分比计算，得靠服务端返回真实时长或用seekable时间范围校验
复杂点在于：不同浏览器对 seekable 范围的支持不一致，有些只返回空 TimeRanges，有些则滞后更新。实际项目中，若需高精度拖动体验，建议结合 seeking 和 seeked 事件做状态同步，而不是只信 currentTime 的瞬时值。
