AI音视频技术的应用越来越广，从实时音视频通话、直播推流，到AI语音识别、视频分析，音视频链路已经成为很多产品的核心能力。但音视频开发涉及的链路特别长：采集、编码、传输、解码、渲染，任何一环出问题都会表现为用户可感知的故障。而且故障现象往往和根因距离很远，比如“对方听不到我说话”，可能是麦克风权限没开、采集设备选错、编码器异常、上行丢包、下行丢包中的任何一个原因。这篇文章把常见的音视频故障分门别类整理出来，给出每类问题的排查思路和解决方法，方便遇到问题时按图索骥。
音频类常见故障：无声、噪声、回声与啸叫
音频问题是投诉率最高的一类。用户对声音的容忍度远低于视频，画面卡一点可能还能接受，声音断断续续基本就无法沟通了。音频故障最常见的有四种表现：完全无声、声音断续、有杂音电流声、回声或啸叫。
完全无声的排查要先确认采集端。第一步检查设备权限，浏览器里可以通过navigator.mediaDevices.getUserMedia申请权限时观察是否被拒绝，移动端则要检查系统设置中麦克风权限是否授予。第二步确认采集设备是否选对，很多电脑有多个音频输入设备（内置麦克风、USB耳机、虚拟声卡），如果SDK默认选择了错误的设备，就会出现“我这边明明在说话但对方听不到”的情况。第三步检查音频轨道是否真正有数据，可以通过AudioContext分析音量值：
// 检测音频轨道是否有实际数据输入
async function checkAudioTrack(stream) {
const audioTrack = stream.getAudioTracks()[0];
if (!audioTrack) {
console.log('没有音频轨道，采集配置可能有问题');
return;
}
const context = new AudioContext();
const source = context.createMediaStreamSource(stream);
const analyser = context.createAnalyser();
source.connect(analyser);
const data = new Uint8Array(analyser.frequencyBinCount);
setInterval(() => {
analyser.getByteFrequencyData(data);
const volume = data.reduce((a, b) => a + b) / data.length;
console.log('当前音量：', volume);
// 音量长期为0说明采集端没有声音输入
}, 500);
}杂音和电流声通常是采样率不匹配或设备占用冲突导致的。比如系统采样率是48kHz，应用按44.1kHz处理，重采样算法不好就会产生明显的电流声。解决方法是统一采样率，或者在SDK层做好重采样。回声和啸叫则多发生在免提场景，两个设备距离近时，A端的声音从B端扬声器播出又被B端麦克风采回去，形成回路。这需要开启AEC（回声消除），排查时可以先确认AEC开关是否打开，再检查采集和播放的时钟是否同步，时钟漂移会显著降低AEC效果。
视频类常见故障：黑屏、花屏、卡顿与音画不同步
视频故障里黑屏和花屏最影响体验。黑屏要先区分是采集端黑屏还是渲染端黑屏。采集端黑屏常见于摄像头被其他应用占用（Windows上尤其常见）、权限未授予、或者视频轨道被禁用。渲染端黑屏则可能是解码失败、渲染时机错误或者视图层级被遮挡。排查时可以在本端先做本地预览，如果本地预览正常，说明采集没问题，问题出在传输或对端渲染。
花屏一般是丢包或解码器状态异常导致的。视频编码中I帧是完整帧，P帧依赖前面的帧，如果丢了关键的P帧，后面的画面就会错乱直到下一个I帧到来。缓解手段包括开启FEC前向纠错、启用NACK重传、以及缩短关键帧间隔。卡顿的排查要结合网络统计，主流SDK都会提供丢包率、RTT、抖动等指标，丢包率超过10%基本就会出现明显卡顿，此时需要动态降级：降低分辨率、降低帧率、切换到更抗丢包的编码策略。
音画不同步的根因是音频和视频的时间戳基准不一致，或者缓冲策略不当。人的听觉对声音超前或滞后比视觉敏感得多，超过200毫秒的不同步就能被感知。解决思路是确保采集时打上统一时钟源的时间戳，播放端按照RTP时间戳的映射关系做同步渲染，而不是各自独立播放。跨设备场景还要注意NTP时钟校准。
网络与性能类故障：延迟、抖动与设备发热
网络问题是音视频故障的放大器。同样的应用，在内网测试一切正常，一上公网就各种异常，这是很典型的场景。排查网络问题要抓住三个指标：RTT（往返延迟）、丢包率和抖动。RTT过高说明链路绕远，常见于没有就近接入边缘节点；丢包率高要看是持续丢包还是突发丢包，持续丢包多为网络拥塞，突发丢包可能是WiFi切换或基站切换引起；抖动大则需要加大抗抖动缓冲区（JitterBuffer），但缓冲区加大又会增加延迟，要在流畅和实时性之间权衡。
// 简单的网络质量评估逻辑
function evaluateNetwork(stats) {
const { rtt, packetLoss, jitter } = stats;
if (packetLoss > 0.1) {
return '差：建议降级到低码率模式';
}
if (rtt > 400 || jitter > 50) {
return '一般：建议开启抗抖动缓冲';
}
return '良好：可维持当前质量';
}设备发热和性能不足也是常见隐患，特别是在AI实时处理场景下，模型推理本身就吃CPU和GPU，再叠加编解码，低端设备很容易过载。过载的表现是采集帧率下降、编码耗时上升、整体延迟持续累积。优化手段包括：使用硬件编解码（H.264硬编硬解）、降低AI模型推理频率、在移动端把视频处理任务调度到独立线程，避免阻塞采集和编码线程。还要注意排查内存泄漏，长时间通话内存持续增长最终会触发系统杀进程。
一份实用的排查清单
实际排查时建议按固定顺序走，能大幅减少无效排查。整体思路是沿着“采集、编码、传输、解码、渲染”的链路逐段确认，先把问题定位到具体环节，再深入分析原因。
- 权限与设备：麦克风摄像头权限是否授予，默认设备是否正确，设备是否被占用
- 采集验证：本地预览和本地录音回放是否正常，确认采集端有无数据
- 编码检查：编码器是否初始化成功，输出码率帧率是否符合预期
- 网络指标：丢包率、RTT、抖动是否在可接受范围，是否与故障时间点吻合
- 解码渲染：对端是否收到流，解码是否报错，渲染视图是否正常
- 日志与埋点：保留端到端的全链路日志，记录每帧时间戳，便于回放分析
最后强调一点：音视频问题复现成本高，很多故障和当时的网络环境、设备状态强相关，事后很难还原。所以一定要提前做好监控和日志上报，把关键指标（音量、帧率、码率、丢包）持续上报到服务端，故障发生时才有数据可查。排查问题本质上是靠数据缩小范围，而不是靠猜。