Audio构造函数必须在点击事件里直接调用play()，浏览器强制要求首次play()由用户真实手势（click/touchstart）同步触发，禁止异步调用，否则报NotAllowedError；正确写法是将play()置于事件回调最内层，移动端优先用touchstart，复用实例优于频繁new Audio()以降低开销。
Audio构造函数必须在点击事件里直接调用play()
浏览器自动播放策略强制要求：首次play()必须由用户真实手势（click或touchstart）同步触发，不能包裹在setTimeout、Promise.then或fetch回调里。否则会报NotAllowedError: play() failed because the user didn't interact with the document first。
正确写法是把play()放在事件回调函数体最内层，中间不跳转：
const clickSound = new Audio('click.wav');
button.addEventListener('click', () => {
clickSound.currentTime = 0;
clickSound.play().catch(e => console.warn('音效失败:', e)); // ✅ 直接调用
});
- 移动端优先用
touchstart而非click，iOS Safari对click有300ms延迟，且touchend不被认可为有效解锁手势 - 元素需有交互语义：加
role="button"或cursor: pointer样式，否则部分Android WebView可能忽略手势上下文 - 不要在
DOMContentLoaded里预调play()，哪怕只调一次也会被拦截
复用Audio实例比每次new Audio()更稳
高频点击场景下，反复new Audio('xxx.mp3')会导致重复加载、解码开销大、内存上升，尤其在弱网或低端设备上明显卡顿或延迟半拍。
推荐提前初始化一个实例并复用：
立即学习“前端免费学习笔记（深入）”；
const clickSound = new Audio('click.wav');
// 预加载：设src后立刻调load()（仅对<code><audio></code>标签有效，new Audio()不支持）
// 所以靠文件体积小 + 格式优化来弥补
- 音效文件选
.wav（无压缩，免解码）或.opus（体积小、启动快），避免.mp3首播延迟 -
.mp3若必须用，需确保无ID3v2标签，否则Safari可能加载失败；可用ffmpeg -i in.mp3 -c copy -map_metadata -1 out.mp3清理 - 连续点击时加
currentTime = 0重置，但别指望它100%即时——解码未完成仍可能卡住
多个按钮共用音效时如何避免声音堆积或静音
单个Audio实例快速连续触发play()，可能出现“只响第一声”或“延迟半拍”，这不是bug，而是音频引擎内部缓冲和解码节奏导致的固有现象。
两种实用解法：
- 简单节流：重置
currentTime后用setTimeout(() => clickSound.play(), 50)，给解码留出余量 - 双实例轮换：准备
soundA和soundB，点击时交替调用，A播完B重置，B播完A重置，适合游戏类高频场景 - 避免同时监听
click和touchend，移动端会触发两次，造成重复播放或play()被拒
Web Audio API不是必须，但适合精确控制
对普通按钮音效，new Audio()足够轻量、兼容性好（Chrome 1+、Firefox 3.5+、Safari 4+）。Web Audio API只有在以下情况才真正必要：
- 需要毫秒级调度，比如节奏游戏里音效必须严格对齐16分音符
- 要动态生成或实时混音（如调节音高、添加回声）
- 大量音效并发（>10个/秒），
Audio实例池管理成本过高
但注意：Web Audio同样受自动播放策略限制，首次AudioContext.resume()也必须在用户手势回调里调用，不是绕过策略的捷径。
容易被忽略的是：iOS Safari对Audio资源加载更敏感，preload="auto"只对<audio>标签生效，new Audio()无法设置该属性，只能靠文件小、格式优、提前声明来扛。
