必须复用Audio实例，而非每次点击都new Audio；应在DOMContentLoaded时预创建并加载，play()须在click或touchstart等用户手势回调中同步调用，且iOS需用touchstart、配WAV/Opus格式、检查静音状态。
Audio实例必须在点击事件里创建还是复用？
每次点击都 new Audio('click.mp3') 是最常见却最不该做的操作。它会重复发起网络请求、重复解码、快速堆积未释放的音频资源，尤其在高频点击（比如游戏 UI 或虚拟键盘）时，页面卡顿、音效延迟半拍甚至完全不响都会出现。
推荐提前复用一个实例：
- 在
DOMContentLoaded 时初始化：const clickSound = new Audio('click.wav');
- 确保文件路径正确且能被浏览器直接加载（检查 Network 面板是否 200 OK）
- WAV 格式优先：无压缩、免解码延迟；Opus 次选（体积小、启动快）；避免 MP3 首播卡顿
- 不要依赖
preload="auto" —— new Audio() 不支持该属性，预加载得靠 JS 主动调用 clickSound.load()（但通常没必要，首次点击触发即可）
play() 调用后没声音，控制台报 “play() failed because the user didn't interact with the document first” 怎么办？
这不是代码 bug，是 Chrome/Firefox/Safari/iOS Safari 的统一策略：**任何有声音频的首次 play() 必须发生在真实用户手势回调中**，且不能是模拟事件（element.click() 不算）。
关键点：
- 第一次
play() 必须写在 click 或 touchstart 回调里，不能包在 setTimeout、fetch.then、DOMContentLoaded 里
- 移动端优先用
touchstart：iOS Safari 对 click 有 300ms 延迟，且某些场景下不触发“用户激活”状态
-
play() 返回 Promise，必须 .catch(e => console.warn('音效失败:', e))，否则失败静默，你根本不知道它没响
- 别在页面加载时尝试自动播放——哪怕只响一声，失败后整个音频上下文可能卡住，后续点击也失效
多个按钮共用一个音效，快速连点时卡顿或无声怎么办？
复用 Audio 实例后，连续点击常出现「重置了 currentTime = 0 却没声」，本质是音频尚未完成解码或前一次播放未结束就被中断。
缓解方式有限但有效：
- 强制重置 + 捕获错误：
clickSound.currentTime = 0; clickSound.play().catch(() => {});
- 加一点防抖（非必须，但对 UI 按钮很实用）：
if (clickSound.ended || clickSound.paused) { clickSound.currentTime = 0; clickSound.play(); }
- 不用
ended 判断，改用 readyState >= 2（HAVE_ENOUGH_DATA），更可靠
- 真要极致体验，得上 Web Audio API +
AudioBufferSourceNode，但复杂度跃升——普通按钮交互不值得
移动端 iOS Safari 完全不响，检查这三个硬性条件
iOS 对音频策略最严，缺一不可：
- 音频文件必须是短 WAV 或 Opus（MP3 在 iOS 上首播延迟极高，常失败）
- 必须用
touchstart 绑定，而非 click（iOS Safari 有时不把 click 视为有效激活源）
- 确保没有全局静音：地址栏小喇叭图标没被划掉；站点没被手动禁音（Chrome/Safari 设置 → 站点设置 → 声音）
音效看似简单，真正落地时最容易栽在「首次用户手势时机」和「复用实例生命周期管理」这两个点上。多数无声问题不是路径错、格式错，而是播放时机踩进了浏览器策略的雷区。
DOMContentLoaded 时初始化：const clickSound = new Audio('click.wav');
preload="auto" —— new Audio() 不支持该属性，预加载得靠 JS 主动调用 clickSound.load()（但通常没必要，首次点击触发即可）play() 必须发生在真实用户手势回调中**，且不能是模拟事件（element.click() 不算）。
关键点：
- 第一次
play()必须写在click或touchstart回调里，不能包在setTimeout、fetch.then、DOMContentLoaded里 - 移动端优先用
touchstart：iOS Safari 对click有 300ms 延迟，且某些场景下不触发“用户激活”状态 -
play()返回 Promise，必须.catch(e => console.warn('音效失败:', e))，否则失败静默，你根本不知道它没响 - 别在页面加载时尝试自动播放——哪怕只响一声，失败后整个音频上下文可能卡住，后续点击也失效
多个按钮共用一个音效，快速连点时卡顿或无声怎么办？
复用 Audio 实例后，连续点击常出现「重置了 currentTime = 0 却没声」，本质是音频尚未完成解码或前一次播放未结束就被中断。
缓解方式有限但有效：
- 强制重置 + 捕获错误：
clickSound.currentTime = 0; clickSound.play().catch(() => {});
- 加一点防抖（非必须，但对 UI 按钮很实用）：
if (clickSound.ended || clickSound.paused) { clickSound.currentTime = 0; clickSound.play(); }
- 不用
ended 判断，改用 readyState >= 2（HAVE_ENOUGH_DATA），更可靠
- 真要极致体验，得上 Web Audio API +
AudioBufferSourceNode，但复杂度跃升——普通按钮交互不值得
移动端 iOS Safari 完全不响，检查这三个硬性条件
iOS 对音频策略最严，缺一不可：
- 音频文件必须是短 WAV 或 Opus（MP3 在 iOS 上首播延迟极高，常失败）
- 必须用
touchstart 绑定，而非 click（iOS Safari 有时不把 click 视为有效激活源）
- 确保没有全局静音：地址栏小喇叭图标没被划掉；站点没被手动禁音（Chrome/Safari 设置 → 站点设置 → 声音）
音效看似简单，真正落地时最容易栽在「首次用户手势时机」和「复用实例生命周期管理」这两个点上。多数无声问题不是路径错、格式错，而是播放时机踩进了浏览器策略的雷区。
clickSound.currentTime = 0; clickSound.play().catch(() => {});
if (clickSound.ended || clickSound.paused) { clickSound.currentTime = 0; clickSound.play(); }
ended 判断，改用 readyState >= 2（HAVE_ENOUGH_DATA），更可靠AudioBufferSourceNode，但复杂度跃升——普通按钮交互不值得- 音频文件必须是短 WAV 或 Opus（MP3 在 iOS 上首播延迟极高，常失败）
- 必须用
touchstart绑定，而非click（iOS Safari 有时不把 click 视为有效激活源） - 确保没有全局静音：地址栏小喇叭图标没被划掉；站点没被手动禁音（Chrome/Safari 设置 → 站点设置 → 声音）
