alert()后调用audio.play()必然失败，因其同步阻塞JS并中断音频上下文，且浏览器仅认可弹窗前的用户手势，后续play()均被拒绝；应改用自定义弹窗+按钮事件内同步播放。
警告对话框配提示音不响，基本不是代码写错了，而是浏览器根本没给它播放机会——Alert弹窗本身会阻塞 JS 执行、中断音频上下文，且现代浏览器对非用户手势触发的 play() 一律拒绝。
为什么 alert() 后调 play() 一定失败
alert() 是同步阻塞式 API，执行时整个页面冻结，JS 线程挂起，任何后续语句（包括 new Audio().play()）都会被卡在队列里，等用户点“确定”后才继续。但此时已错过用户手势窗口：浏览器只认“弹窗前那一瞬间”的交互，弹出后点击确定不算可信手势。
- Chrome / Edge 抛
NotAllowedError：“play() failed because the user didn't interact with the document first” - Safari 更狠，连
AudioContext都可能被挂起，后续所有音频初始化都失效 - 即使你把
play()放在alert()后面，也属于“无手势上下文”，100% 被拒
用 confirm() 或 prompt() 也一样不行
这三个原生对话框（alert/confirm/prompt）共享同一套阻塞机制，都不产生可复用的用户手势信号。它们返回值后，浏览器已将该次交互标记为“已消耗”，无法用于解锁媒体播放。
- 别试
setTimeout(() => audio.play(), 0)—— 延迟不等于新手势 - 别指望
click事件冒泡到document后再播 —— 弹窗期间事件流已中断 - 移动端 iOS Safari 还额外要求首次播放必须由
touchstart触发，click都可能延迟或失效
真正能响的替代方案：自定义弹窗 + 手势绑定
必须把提示音和用户操作绑在同一事件回调里，且不能经过任何阻塞环节。推荐用原生 button 触发，而非依赖弹窗返回值。
- 把警告逻辑拆成两步：先显示自定义弹窗（
div+ CSS），再让用户点“确认”按钮（）来触发播放和下一步操作 - 提示音用
new Audio('alert.mp3')实例，提前在 DOM 加载后调用.load()（不.play()），避免首次点击卡顿 - 按钮事件中同步调用
audio.play().catch(e => console.warn('提示音被拒:', e))，并立即处理业务逻辑（如提交表单） - MP3 文件务必压缩到
120KB以内（22050Hz、单声道、64kbps），否则移动端首响延迟明显
容易被忽略的底层细节
即使用了自定义弹窗，仍可能静音——因为 iOS Safari 的 volume 属性是只读的，设了也没用；安卓某些 WebView 会忽略 audio.volume，只听系统音量。更麻烦的是，如果页面刚加载完就立刻让用户点按钮，部分旧版微信内置浏览器会因 AudioContext 未激活而报错 “The request is not allowed by the user agent”。
- 首次播放前，可用
new AudioContext().resume()主动唤醒上下文（需在用户手势回调内） - 不要依赖
preload="auto"，移动端常被忽略；改用fetch('alert.mp3').then(r => r.arrayBuffer())+decodeAudioData()预解码（适合精确控制场景） - 真机测试不可跳过：iOS 模拟器不模拟音频策略，必须用 iPhone 实测；Android 则要覆盖 Chrome、Samsung Internet、微信内置浏览器
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
