关键在于理清信号路径、控制时序同步并规避浏览器限制：所有音频源须共享同一AudioContext，通过GainNode等节点汇聚至MediaStreamDestination输出，再交由MediaRecorder录制，确保相位一致与动态调控。
要构建支持音频轨道混录的实时应用，关键不在堆砌功能，而在于理清信号路径、控制时序同步，并规避浏览器音频调度的隐性限制。Web Audio API 是核心载体，MediaRecorder 或 MediaStream Recording 可作为输出出口，但混音逻辑必须在 Web Audio 图中完成。
音频轨道混录的核心原理
混录不是简单把多个音频源“叠加播放”，而是将多个音频节点的输出信号，在同一个 AudioContext 下通过 AudioNode 连接汇聚到一个统一的处理点（如 ChannelMergerNode 或 GainNode 后再合并），最终送入录制或播放目标。所有参与混音的轨道必须共享同一个 AudioContext 实例，否则无法实现精确时间对齐与相位一致性。
- 每个音频源（麦克风、文件、合成器）都需接入同一上下文，不能各自创建独立 context
- 使用
createMediaStreamDestination()获取混音后的 MediaStream，可直接传给 MediaRecorder 录制 - 若需动态调节各轨道音量/静音，优先用
GainNode控制，避免反复连接/断开造成音频中断
多源输入的接入与同步处理
真实场景中，音频轨道常来自不同源头：用户麦克风、远程 WebRTC 音频流、本地音频文件、甚至 Web Audio 合成音效。它们的采样率、延迟特性不一，需统一协调。
- 麦克风流：用
navigator.mediaDevices.getUserMedia({audio:true})获取，注意设置echoCancellation: false若需保留原始声场 - WebRTC 远程流：从
RTCPeerConnection的ontrack事件中提取track，用AudioContext.createMediaStreamSource(stream)接入 - 本地文件流：用
fetch()+AudioContext.decodeAudioData()加载后转为BufferSourceNode，或用<audio>元素配合AudioContext.createMediaElementSource() - 所有源接入后，建议统一启用
context.resume()触发音频系统启动，避免 Safari 等浏览器因自动暂停机制导致无声
混音输出与录制落地
混音完成后，输出方式决定后续流程：实时播放、本地保存、或推流上传。推荐以 MediaStream 为中间媒介，兼顾灵活性与兼容性。
- 创建混音目标：
const destination = audioContext.createMediaStreamDestination() - 将各轨道 GainNode 输出连接至
destination，而非audioContext.destination - 用该
destination.stream初始化MediaRecorder，指定 mimeType 如audio/webm;codecs=opus（Chrome/Firefox 支持好）或audio/mp4;codecs=mp4a.40.2（Safari 更友好） - 录制时监听
dataavailable事件收集 Blob 片段，最后用new Blob(chunks, {type: 'audio/webm'})合并下载
常见坑与应对建议
实际开发中，以下问题高频出现且不易定位：
-
Safari 不支持 MediaStreamDestination 直接录制：需改用
OfflineAudioContext离线渲染，或降级为单轨录制+服务端混音 -
轨道间延迟漂移：WebRTC 流自带网络抖动缓冲，应将其接入前先通过
ScriptProcessorNode（已弃用）或AudioWorklet做时间戳对齐，或采用getInputTimestamp()补偿 -
iOS Safari 权限限制严格：必须由用户手势（如点击按钮）触发整个链路，且首次调用
getUserMedia后才能创建 AudioContext -
长时间运行内存泄漏：每次停止录制后，显式调用
mediaRecorder?.stop()并清除所有node.disconnect()，避免 AudioNode 持有引用
