在弹窗中直接使用标签无效，因原生弹窗不支持HTML嵌入且autoplay被浏览器拦截；应解耦播放逻辑，绑定到用户点击按钮等手势事件，用new Audio()预加载并同步调用play()。
弹窗里直接放
很多人想在 alert()、confirm() 或自定义 modal 里塞 标签，结果点开弹窗没声音、控件不显示，甚至控制台报错。根本原因是：弹窗本身（尤其是原生 JS 弹窗）不支持嵌入 HTML 内容；而自定义弹窗若未正确挂载 DOM 或未触发音频加载时机， 就只是个“死标签”。更关键的是，即使 DOM 存在，autoplay 在弹窗中基本必被浏览器拦截——没有用户手势上下文，play() 会直接抛 DOMException: play() failed because the user didn't interact with the document first。
new Audio() 必须在用户点击弹窗按钮时同步调用
真正能落地的做法，是把音频播放逻辑从弹窗渲染解耦，绑定到用户明确触发的动作上，比如点击「确定」「关闭」或「重试」按钮。此时浏览器认定存在“用户手势”，允许播放：
- 提前创建好实例：
const confirmSound = new Audio('/sounds/confirm.mp3'); - 在按钮 click 回调里重置并播放：
confirmSound.currentTime = 0; confirmSound.play().catch(e => console.warn('提示音未响:', e)); - 不要在弹窗
show()或open()后 setTimeout 调用 —— iOS Safari 会拒掉所有异步play() - 避免复用失败的实例：如果某次
play()被拒，该实例后续调用大概率仍失败，建议每次成功播放后缓存，失败时重新new Audio()
MP3 文件必须压缩且预加载，否则首响延迟明显
首次调用 new Audio(src).play() 会触发网络请求 + 解码，500KB 的 MP3 在弱网下可能卡顿 1 秒以上，用户点完按钮没反应，会反复点击。这不是代码问题，是资源加载瓶颈：
- 把提示音压到
80–120KB：单声道、采样率22050Hz、比特率64kbps足够清晰 - 页面加载后立即预加载（不播放）：
const preload = new Audio('/sounds/notify.mp3'); preload.load(); - 别用
preload="auto"的标签预加载 —— 它会阻塞解析，移动端常被忽略 - 服务端确保返回正确
Content-Type：MP3 对应audio/mpeg，否则 Safari 直接跳过
通知音和弹窗音要分开管理，开关必须独立
用户可能关掉消息提示音，但希望弹窗确认音保留；也可能反过来。硬编码在一起会导致设置失效或逻辑混乱：
- 用对象管理不同用途的音频：
const sounds = { modal: new Audio(...), notify: new Audio(...) }; - 设置项存 localStorage，读取后决定是否调用
play()，而不是删 DOM 或设muted=true - 别在
Notification.onshow里调play()—— 这个事件不保证有用户手势，Chrome 会静音 - 移动端尤其注意：iOS Safari 不支持
AudioContext在非手势上下文中恢复，所以new Audio()是目前最稳的选择
实际最难的不是写几行代码，而是让第一次点击就响、连续点击不卡、不同机型都兼容——这取决于你什么时候加载、什么时候调用、以及有没有给浏览器它想要的那个“用户点了”的信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
