必须在用户点击触发的上下文中调用audio.play()且确保音频资源可访问，否则现代浏览器会阻止播放；需处理play()返回的Promise拒绝，检查路径、MIME类型及跨域配置，iOS Safari尤其严格。
弹窗里放 <audio></audio> 标签就行，但得确保它能播
浏览器默认不自动播放带声音的音频，尤其在弹窗这种非用户主动触发的上下文中。直接写 <audio src="xxx.mp3" autoplay></audio> 几乎肯定失效——现代浏览器会静音或直接阻塞。真正能播的前提是：用户刚点过弹窗触发按钮（比如“播放”或“查看详情”），且你在那个点击回调里调用 play()。
- 弹窗建议用原生
dialog元素或div+display: none切换，别依赖已淘汰的window.open() -
<audio></audio>必须放在弹窗 DOM 内（不能靠 JS 动态 append 后再 play，容易错过播放时机） - 加
controls属性，让用户有手动控制权；去掉autoplay和muted（除非你真需要静音自动播）
用 JavaScript 控制播放，必须处理 play() 的 Promise 拒绝
调用 audio.play() 返回 Promise，失败时会抛异常（比如被策略拦截），不 catch 就可能卡住后续逻辑。常见错误是只写 audio.play() 然后以为完事了。
- 在弹窗显示后立即调用：例如
myDialog.showModal(); audio.play().catch(e => console.warn("播放被阻止:", e)); - 如果弹窗是点击按钮触发的，把
play()放在按钮的onclick或事件监听器里，保证用户手势上下文还在 - 不要在
setTimeout或异步回调（如fetch完）后再调play()，这时上下文已丢失
MP3 路径和 MIME 类型要对得上，否则加载失败没提示
浏览器对 <audio></audio> 的资源加载失败很安静——既不报错也不提示，只留个空白控件。常见原因是路径 404、服务器没返回正确 Content-Type，或跨域没配好。
- 检查浏览器 Network 面板，确认音频请求状态码是 200，
Content-Type是audio/mpeg（MP3）或audio/wav（WAV）等合法类型 - 本地文件用相对路径时，确保路径相对于 HTML 文件位置，不是相对于弹窗 JS 脚本位置
- 如果音频在不同域名下，服务端需返回
Access-Control-Allow-Origin: *，且<audio></audio>加crossorigin属性：<audio crossorigin src="https://xxx.com/sound.mp3"></audio>
移动端 iOS Safari 特别难搞，别信“加 muted 就能自动播”
iOS Safari 对自动播放限制最严：即使加了 muted，也要求用户至少一次触摸交互后才能解禁音频上下文。而且它不支持 dialog 元素（Safari 15.4 才开始部分支持），用 div 模拟弹窗更稳妥。
立即学习“前端免费学习笔记（深入）”；
- 务必在用户点击弹窗内某个按钮（比如“播放音频”）后才调
audio.play()，别在弹窗一打开就试 - 避免用
background: rgba()遮罩层盖住整个页面——iOS 上遮罩层可能拦截后续 touch 事件，导致按钮点不动 - 测试时真机连 Safari Web Inspector，看 Console 是否有 “The audio playback was blocked” 类提示
