要实现HTML5音频端到端≤150ms低延迟，必须弃用<audio>标签，改用AudioContext配合latencyHint: 'interactive'、用户交互后resume()、精确基于audioCtx.currentTime调度、精简处理链路，并适配平台限制兜底。
HTML5 音频播放要实现真正低延迟（端到端 ≤150ms），不能只靠 <audio> 标签或简单调用 play()。必须绕开浏览器默认媒体管线，改用 AudioContext 构建确定性音频流，并精细控制采集、调度与输出环节。
放弃 audio 元素，启用 AudioContext 交互模式
<audio> 的底层依赖媒体解码与系统音频缓冲，延迟常达 300–800ms，且不可控。低延迟场景必须切换到 Web Audio API：
- 创建时显式传入
{ latencyHint: 'interactive' }，提示浏览器启用最小缓冲策略 - 避免在页面加载即初始化上下文，应在用户首次交互（如点击按钮）后调用
audioCtx.resume() - 禁用
MediaElementAudioSourceNode（它会引入额外解码与同步开销），改用createMediaStreamSource()接入麦克风，或createBufferSource()播放预解码音频
精确调度播放起始时间
延迟失控往往源于时间基准混乱。关键不是“什么时候调 start()”，而是“在音频时钟的哪个时刻启动”：
- 永远使用
audioCtx.currentTime作为绝对时间参考，不要混用audioElement.currentTime - 加载完
AudioBuffer后，调用source.start(audioCtx.currentTime)，而非source.start(0) - 若需循环播放或节拍对齐，用
source.start(audioCtx.currentTime + offset)精确偏移，避免 JS 调度抖动累积
精简传输与处理链路
每多一个节点、一次格式转换或缓冲区拷贝，都可能增加 1–10ms 不等的隐性延迟：
立即学习“前端免费学习笔记（深入）”；
- 避免使用
MediaRecorder录制——它内置编码器，Chrome 中延迟常超 200ms；改用AudioWorklet直采原始 PCM（Float32Array → Int16Array → Uint8Array） - 混音不依赖
ChannelMergerNode，优先用多路connect()到同一GainNode，减少节点跳转 - 滤波、延迟等效果尽量复用已分配节点，避免频繁
disconnect()/connect()导致重调度
适配平台限制与兜底策略
不同浏览器对低延迟能力支持差异明显，需主动降级而非报错中断：
- iOS Safari 不支持
AudioWorklet（截至 2026 年 5 月），只能回退至ScriptProcessorNode（已弃用但仍可用），延迟略高（≈200ms） - 移动端需监听
audioCtx.state === 'suspended'，并在用户交互后立即resume()，否则静音且无提示 - 对不支持
outputLatency的旧版浏览器，可通过发送带时间戳的音频帧 + 远端回传 RTT 的方式，粗略估算单向延迟并动态补偿
