audio.play()失败主因是浏览器策略限制，须由用户手势触发，需监听canplay事件后调用并捕获异常，流式音频要确保响应头正确，移动端需注意交互上下文持续有效。
audio.play() 调用失败，八成不是代码写错了
浏览器拒绝播放，几乎总是因为策略限制，而不是 play() 写法有误。现代 chrome、edge、safari 都强制要求：音频首次播放必须由用户手势（如 click、touchstart）触发，否则直接抛出 DOMException: play() failed because the user didn't interact with the document first。
- 不能在页面加载完成就自动调用
audio.play()，哪怕加了autoplay属性也没用 - 动态插入的
<audio></audio>元素（比如通过innerHTML或appendChild创建），需手动调用audio.load()，再等canplay事件 - 某些安卓 webview 不支持
play()返回 promise，得用try/catch+onerror双保险
确保音频资源真的“准备好”了再播
play() 成功的前提是媒体已加载就绪，光有标签不行，还得看状态。常见误区是以为 loadedmetadata 就能播，其实更稳妥的是等 canplay —— 表示至少有一帧可解码播放。
- 检查
audio.networkState === 1（即NETWORK_LOADED），排除网络加载中卡住的情况 - 避免多个
<audio></audio>标签共用同一 URL 且设置了preload="none"，后一个可能被前一个静音或中断 - 推荐写法：
audio.addEventListener('canplay', () => { audio.play().catch(e => console.warn('Play failed:', e)); });
播网络音频流（如 MP3 URL、AAC 流）要注意什么
播静态文件和播流式音频（比如直播源、TTS 接口返回的音频流）行为一致，但流式更易因缓冲不足或服务端响应头缺失而失败。
- 确保服务端响应头包含
Content-Type（如audio/mpeg）和Accept-Ranges: bytes，否则 Safari 可能拒绝加载 - http 重定向（302）在部分安卓 WebView 中不被正确处理，建议用最终直连 URL
- 若用
fetch+blob URL方式加载，注意 blob 生命周期：页面刷新后 URL 失效，且大文件 blob 占内存
移动端真机调试时最常漏掉的一件事
很多开发者在桌面 Chrome 上调通了，一上 ios 或安卓真机就失败，往往是因为忘了确认「用户交互上下文」是否持续有效。
- iOS Safari 中，
click后若页面发生跳转、弹窗、location.href修改，后续异步的play()会丢失手势上下文 - 安卓部分厂商浏览器（如华为、小米）对
touchend的信任度低于click，优先用click绑定 - 别依赖「点一次，后面都能播」—— 每次新音频源加载后，首次播放仍需新的用户手势
实际项目里最麻烦的不是怎么写 play()，而是怎么让浏览器相信“这是用户要听的”，这个信任链一旦断开，所有补救都只是绕路。