audio无法自动播放的根本原因是浏览器媒体策略要求用户真实交互后才能播放有声媒体。Chrome≥66等主流浏览器均拦截无手势触发的play()，需预激活每个audio实例、监听用户事件后逐个调play().then().pause()，src切换后须等待loadedmetadata事件再操作。
audio元素无法自动播放，根本原因不是代码写错
几乎所有跨设备音频播放列表卡住的第一步，都是play()静默失败。它不报错、不弹窗、不中断 JS，只在控制台输出一行：DOMException: play() failed because the user didn't interact with the document first。这不是 bug，是 Chrome ≥66、Firefox ≥66、Safari ≥11、Edge ≥79 共同执行的媒体策略——没有用户真实点击或触摸，带声音的播放请求一律拦截。
常见误操作包括：
- 在
DOMContentLoaded或window.onload里直接调audio.play() - 用
setTimeout延迟 100ms 再播——iOS 会判定为非用户驱动，照样拒绝 - 以为加了
muted="true"就万事大吉，却没确认volume是否真为 0（有些 JS 后续又把它设回了 1） - 在微信 iOS WebView 中依赖
autoplay或muted，实际必须等WeixinJSBridgeReady且用户 touch 后才能首次激活
播放列表切换时 audio 元素必须单独预激活
iOS Safari 和微信 WebView 对每个 <audio> 实例独立校验“用户手势上下文”。你不能只对第一个元素调一次 .play().then(() => .pause()) 就认为整张列表都通了——漏掉任意一个，它后续调 play() 都会失败。
正确做法是：
立即学习“前端免费学习笔记（深入）”；
- 所有音频元素初始化时先设
muted="true"、preload="metadata"，避免空加载 - 监听首个用户交互事件（如
document.addEventListener('click', handler, { once: true })） - 在该 handler 中遍历所有
<audio>，逐个调用.play().catch(() => {})→.pause()，完成预激活 - 之后切换播放项时，直接
audio.currentTime = 0; audio.play()即可
src 切换后必须等 loadedmetadata 才能设 currentTime
动态更换播放列表项时，如果刚改完 audio.src 就立刻设 currentTime 或调 play()，多数浏览器会忽略——因为元数据（时长、采样率等）还没加载完。
可靠流程是：
- 更新
audio.src后，监听loadedmetadata事件（不是canplay或loadeddata） - 在该事件回调中设置
currentTime、volume等参数，再调play() - 务必
.catch(e => console.warn('play failed:', e))，否则失败无声无息 - 不要在
timeupdate里频繁读写currentTime，节流或用requestAnimationFrame批量处理进度同步
多页跳转时背景音乐不断掉的唯一可行路径
靠 localStorage 存时间点 + 状态来“续播”，调试难、易丢帧、页面 reload 后仍断音。真正稳定的解法是：把整个播放器逻辑抽离为单页应用（SPA）结构，用前端路由（如 history.pushState）切换内容，而非传统多 HTML 页面跳转。
若必须多页，仅限极简场景：
- 所有页面共享同一
<audio>元素（例如固定在<body>底部，不随路由销毁） - 用
beforeunload记录当前currentTime和paused状态到sessionStorage - 新页面加载后立即从
sessionStorage读取并恢复（注意：仅限同域，且需用户已交互过） - 放弃“无缝”幻想——iOS 微信下页面跳转必然重置音频上下文，首次播放仍需用户再点一次
最常被忽略的是：预激活不是“做一次就永久有效”，而是“每个新创建的 <audio> 实例都得走一遍”，哪怕它和前一个 src 完全相同。漏掉这个，列表播到第二首就卡死。
