必须在用户点击事件回调中新建Audio并调用play()，且关闭模态框时需pause、重置currentTime并load清理；iOS需muted+playsinline配合首次点击解禁。
模态框弹出时插入音频，核心是「不依赖 autoplay」+「确保用户手势上下文」。现代浏览器（Chrome 66+、Safari 13.1+、Firefox 70+）默认禁止无用户交互触发的音频自动播放，直接在 layer.open 或 modal.show() 里调用 audio.play() 几乎必然失败，报错 DOMException: play() failed because the user didn't interact with the document first。
为什么不能直接写 autoplay 属性
即使 HTML 中写了 <audio autoplay>，只要模态框是 JS 动态创建/显示的（比如 layer.open、bootstrap Modal、document.createElement），浏览器仍会判定为“非用户手势触发”，直接静音或拒绝加载。这不是 bug，是策略性限制。
- autoplay 在页面首次加载时可能生效，但模态框是后续动态插入的，上下文已丢失
- 部分 iOS Safari 甚至会忽略
autoplay和muted组合，除非明确由 click/tap 触发 - 若音频带
controls，用户点播放按钮是合法手势，但你无法靠它“自动启动”
必须绑定到用户点击事件的回调里
真正可靠的做法，是把 audio.play() 放在打开模态框的**同一用户操作链中**，比如按钮的 onclick 或 addEventListener('click') 回调末尾。
- 先调用
layer.open(...)或modal.show() - 紧接着执行
const audio = new Audio('sound.mp3'); audio.play().catch(e => console.log('play blocked:', e)); - 注意：Audio 实例必须在 click 回调内新建，不能提前声明后延迟调用 —— 浏览器只认“此刻是否由用户动作发起”
- 如果音频需复用，可用
audio.currentTime = 0重置后再play()，但首次初始化仍要走 click 链
关闭模态框时记得 pause + load() 清理
音频没停，模态框关了，声音还在后台响，既耗资源又影响体验。Layui 的 end 回调、Bootstrap 的 hidden.bs.modal 事件、或原生 close 事件里必须做清理：
立即学习“前端免费学习笔记（深入）”；
-
audio.pause()停止播放 -
audio.currentTime = 0重置进度（避免下次点开从中间开始） - 可选：
audio.load()卸载当前资源缓冲（尤其换不同音频时） - 不要只设
audio.src = ''—— 这不会中断正在播放的音频流
移动端特别注意 playsinline 和 muted 兜底
iOS Safari 对 <audio> 的限制比桌面更严。若音频必须无用户点击就响（比如提示音），唯一可行路径是：
- 音频本身静音：
<audio muted autoplay>（muted 是硬性前提） - 配合
playsinline防止跳全屏 - 再在用户第一次点击模态框内任意元素（如关闭按钮、确认按钮）时，调用
audio.muted = false; audio.play() - 这个“解禁”步骤不可省——iOS 不允许 JS 在非手势下取消 muted
最易被忽略的是：音频资源地址如果是相对路径或带参数的签名 URL，务必在 new Audio(...) 时就传完整有效地址，而不是等模态框打开后再改 src。否则 play() 会因资源未加载而立即 reject。
