点击按钮没反应，主因是浏览器静默拒绝音频播放或加载失败；需检查路径是否正确、启用本地HTTP服务、捕获play()的Promise错误、添加controls属性并确保用户手势直接触发。

点击按钮没反应，八成不是代码写错了，而是浏览器根本没让音频加载成功或拒绝执行播放——它连错误都懒得报给你看。

audio.src 路径错或文件没加载成功

浏览器对 audio 元素加载失败极其沉默：不报错、不提示、控制台干干净净，但你点按钮就是没反应。根源往往在路径本身。

• 把 src 值直接粘到浏览器地址栏里敲回车，看能不能下载或播放；打不开 = 路径错或服务器没配 MIME 类型
• 用相对路径时，确认它相对于当前 HTML 文件，不是 JS 文件位置；"./sound.mp3" 和 "sound.mp3" 在嵌套目录下行为可能不同
• 本地双击打开 HTML（file:// 协议）时，Chrome/Firefox 会禁用音频解码 —— 必须起本地服务：python3 -m http.server
• Network 面板里找音频请求，状态不是 200，而是 404、net::ERR_BLOCKED_BY_CLIENT 或 ERR_FAILED，就别查 JS 了，先修路径

play() 被浏览器静默拒绝（NotAllowedError）

这是最隐蔽也最常被忽略的问题：play() 返回 Promise，失败时不抛同步异常，只在 Promise reject 里带 NotAllowedError。你不 catch，就等于什么都没发生。

• 必须在用户真实交互（click、touchstart）的回调中**同步调用** play()，不能包在 setTimeout、fetch.then 或 DOMContentLoaded 里
• 移动端尤其严格：iOS Safari 要求事件必须由原生 触发，绑在
  上且没加 role="button" 可能被判定为“非可信手势”
• 务必捕获失败：audio.play().catch(e => console.warn('播放被拒:', e))，否则控制台一片空白，你根本不知道它早就放弃了
• autoplay 属性单独存在基本无效；想有声自动播？必须等用户首次点击后，再手动调一次 play()

controls 没开，误以为“没反应”

很多人写了 就以为万事大吉，结果页面上啥也没有——因为没加 controls，元素完全不可见，更别说点了。


DeepBI DHTML 页面生成器
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
下载
• 是能立刻验证是否加载成功的最小可用结构
• 如果 controls 出来了但点播放条没反应，说明问题不在 JS 绑定，而在加载或策略层（回到前两个副标题）
• 不要依赖“看起来在播”来判断：界面显示播放中但没声音，先看地址栏有没有小喇叭图标被 mute，再查系统音量

移动端点一次没反应，要点两次才播

这不是 bug，是 iOS Safari 和 Android Chrome 的硬性限制：首次音频播放必须由**直接、未被干扰的用户手势**触发。任何中间层转发、事件代理或延迟，都会让它失效。

• 确保按钮是原生 ，不用
  或 addEventListener('click') 绑在非交互元素上
• 避免在事件处理中调用 e.stopPropagation() 或 e.preventDefault()（除非必要），它们可能破坏手势信任链
• iOS 上 touchstart 比 click 更可靠；可同时监听两者，但不要在 touchstart 里阻止默认行为后再等 click
• 首次播放前，audio.volume 不要设为 0；iOS Safari 对 volume 属性是只读的，设了也白设，还可能影响上下文激活

真正卡住人的，从来不是语法写错，而是浏览器在背后悄悄否决了你的 play()，还不告诉你理由。抓 Network、加 catch、开 controls、走 HTTP 服务——这四步做完，90% 的“没反应”就定位清楚了。