Web Audio API 的 play() “卡一下”是因浏览器默认懒加载和自动暂停策略，AudioContext 初始为 suspended 状态，需在用户手势中调用 resume() 并预解码音频才能实现 50ms 内响应。
Web Audio API 的 play() 为什么总“卡一下”
不是你代码写错了，是浏览器默认做了音频上下文懒加载和自动暂停策略。用户首次交互前，AudioContext 处于挂起（suspended）状态，调用 play() 不会立刻触发声音，而是排队等唤醒——这中间可能有 100–500ms 延迟，尤其在移动设备上更明显。
常见错误现象：play() 返回 Pending Promise、控制台报 The AudioContext was not allowed to start、点击按钮后没声音、隔半秒才出声。
- 必须在用户手势（如
click、touchstart）回调里调用audioContext.resume()，不能提前执行 - 不要在页面加载完就初始化播放器，等真实交互再建
AudioContext - 如果用
HTMLAudioElement，也要在用户操作中调用play()，否则会被静音拦截
如何让 play() 响应快于 50ms
核心思路：绕过解码延迟 + 避免首次解码阻塞 + 预热音频上下文。Web Audio 比 更可控，但代价是得自己管理缓冲和节点连接。
- 用
decodeAudioData()提前加载并解码音频文件，别等到play()时才调用（否则解码同步阻塞主线程） - 创建
AudioBufferSourceNode后立即start(0)，时间戳传0表示“现在就播”，不是“0秒位置” - 避免每次播放都新建
AudioContext，复用一个实例；但注意它可能被挂起，需监听statechange并适时resume() - 移动端务必加
{ once: true }监听touchstart或click，防止重复 resume 导致异常
示例关键片段：
button.addEventListener('click', () => {
if (audioContext.state === 'suspended') {
audioContext.resume(); // 必须在这里调
}
const source = audioContext.createBufferSource();
source.buffer = audioBuffer; // 已 decode 好的
source.connect(audioContext.destination);
source.start(0); // 不是 source.start()
});
HTMLAudioElement.play() 能不能压到 100ms 内
可以，但上限比 Web Audio 低，且平台差异大。iOS Safari 对 的处理很保守，即使写了也常不预加载；Android Chrome 表现稍好，但仍受后台标签页节流影响。
-
preload="metadata"是最稳妥选择，避免大文件提前下载，又能让时长/尺寸就绪 - 不要依赖
canplay，改用canplaythrough，它表示“按当前网速能一路播完”，更接近可播放状态 - 设置
audio.volume = 0.001再play()，有时能绕过某些浏览器的静音策略误判（尤其微信内嵌浏览器） - 若音频很短（AudioContext +
decodeAudioData更可靠，反而多一层解析开销
容易被忽略的兼容性坑
延迟问题在跨设备时不是线性变差，而是断崖式失效。比如同一段代码，在 macOS Chrome 上延迟 20ms，到了 iOS 17 Safari 就变成 400ms+，原因往往藏在细节里。
- iOS Safari 不支持
AudioContext的latencyHint: 'interactive'，设了也无效；只能靠预解码 + 手势唤醒硬扛 - 某些安卓厂商浏览器（如华为、小米）会劫持
AudioContext，state永远卡在suspended，得加兜底：超时 1s 后强制resume()并忽略错误 -
decodeAudioData()在低内存 Android 设备上可能失败，需捕获DOMException: Unable to decode audio data，降级用+play() - 不要用
setTimeout(() => play(), 0)模拟“立刻播放”，这会让浏览器判定为非用户手势触发，直接拒绝
真正在意首响延迟的场景（比如节拍器、游戏音效、实时反馈），Web Audio 是唯一靠谱路径，但得接受它需要更多初始化控制——没银弹，只有取舍。
