25、WebRTC调试与排错：常用调试工具（chrome://webrtc-internals）、常见错误码分析、日志分析技巧
做WebRTC开发，最头疼的是什么？
不是写代码，是出了问题你根本不知道它卡在哪。信令通了没？ICE候选到了没？DTLS握手失败还是SDP协商错了？
我刚开始搞WebRTC那会儿，经常对着黑屏干瞪眼。后来摸清了几个调试路子，才慢慢有了「手感」。今天我把压箱底的经验掏出来，跟你聊聊怎么用工具、看日志、分析错误码。
一、chrome://webrtc-internals —— 你的第一把手术刀
这个页面，说白了就是Chrome给WebRTC开的「黑匣子」。你只要在浏览器里打开一个WebRTC应用，再新开标签页输入 chrome://webrtc-internals，所有底层细节全摊在你面前。
核心价值：不用猜，直接看ICE状态、RTT、丢包率、比特率、SDP原文。
我个人习惯，一上来先看三个面板：
- Stats Table —— 实时数据表。重点关注
googRtt（往返时延）和packetsLost（丢包数）。如果RTT突然飙到500ms以上，八成是网络问题。 - ICE Connection State —— 连接状态。看到
connected才放心，如果一直是checking或disconnected，那就要查STUN/TURN配置了。 - SDP Offer/Answer —— 原始SDP文本。我遇到过好几次，明明是H264编码，结果SDP里写的是VP8，双方协商失败。这种坑，看界面是看不出来的，必须看原文。
小技巧：在webrtc-internals页面里，按 Ctrl+F 搜索 failed 或 error，能快速定位异常行。我曾经靠这个在5分钟内找到了一个ICE候选地址格式错误的问题。
二、常见错误码分析 —— 别被数字吓到
WebRTC的错误码其实不多，但每个都挺要命。我整理了一张表，你遇到问题直接对照着查。
| 错误码 | 含义 | 常见原因 | 我的处理经验 |
|---|---|---|---|
kIceConnectionFailed |
ICE连接失败 | STUN/TURN服务器不可达、防火墙阻挡 | 先ping一下STUN服务器IP，很多时候是UDP端口被禁了 |
kMediaStreamError |
媒体流错误 | 摄像头/麦克风被占用、权限未授予 | 检查浏览器地址栏左侧的摄像头图标，看看是不是被禁了 |
kSdpParseError |
SDP解析失败 | SDP格式错误、缺少必要字段 | 把SDP原文复制出来，用在线SDP解析工具看，通常能找到缺失的行 |
kDtlsFailure |
DTLS握手失败 | 证书不匹配、TLS版本不一致 | 检查两端是否都用了自签名证书，如果是，需要设置 certificates 选项 |
kInvalidState |
状态无效 | 在错误时机调用了API（如连接未建立就发数据） | 加日志打印 peerConnection.connectionState，确保状态是 connected 再操作 |
注意：错误码在JavaScript层有时会被封装成 DOMException，你需要在 catch 块里打印 error.name 和 error.message，才能看到真正的WebRTC错误码。
三、日志分析技巧 —— 从海量信息里捞针
WebRTC的日志默认是不全的。你需要手动开启详细日志。我个人习惯在启动浏览器时加这些参数：
--enable-logging --v=1 --vmodule=*/webrtc/*=2这样会把WebRTC模块的日志级别调到2（info级别），输出到终端或日志文件。你想想看，没有这些日志，你连ICE候选是IPv4还是IPv6都不知道。
拿到日志后，我一般按这个顺序排查：
- 搜 "ERROR" 或 "WARNING" —— 先看有没有明显的红色错误。比如
ERROR: ICE failed to allocate candidates，那问题就在网络层。 - 搜 "ICE" 关键词 —— 看ICE状态机变化。正常流程是：
checking→connected→completed。如果卡在checking超过10秒，基本就是STUN没响应。 - 搜 "SDP" 关键词 —— 确认双方SDP是否一致。重点看
a=rtpmap和a=fmtp行，编码参数不匹配会导致黑屏。 - 搜 "DTLS" 关键词 —— 握手失败通常会有
DTLS handshake failed字样，后面会跟一个SSL错误码，比如SSL_ERROR_SSL或SSL_ERROR_NO_CYPHER_OVERLAP。
避坑指南：我曾经花了一整天查一个「偶尔连不上」的问题。日志里没有任何错误，就是ICE状态在 checking 和 disconnected 之间反复跳。后来发现是TURN服务器返回的 relay 候选地址端口号写错了。嗯，这种间歇性故障最坑人，一定要把日志级别开到 --v=2 才能看到细节。
四、知识体系总览
下面这张图，是我自己总结的WebRTC调试排错全景。你照着这个思路走，90%的问题都能定位到根因。
五、实战：一个典型的排错流程
假设你遇到一个问题：两个浏览器之间视频通话，A能看到B，但B看不到A。你会怎么查？
我的做法是这样的：
- 打开
chrome://webrtc-internals，看B的inbound-rtp统计。如果packetsReceived是0，说明B根本没收到A的视频包。 - 再看A的
outbound-rtp，如果packetsSent在增长，说明A在发，但B没收到。问题出在网络或ICE上。 - 切到ICE面板，看A和B的ICE候选。如果A只有
host候选，没有srflx或relay，那说明STUN/TURN没配置对。 - 最后翻日志，搜
ICE和STUN，确认是否收到了STUN响应。
你看，整个过程不超过10分钟。没有工具和日志，你只能靠猜。
记住：WebRTC调试的核心就三件事 —— 看数据、读日志、查错误码。把这三点练熟了，你就是团队里的WebRTC救火队员。
好了，这一章的内容就到这里。调试工具和技巧都给你了，剩下的就是多练。遇到问题别慌，打开webrtc-internals，搜关键词，看错误码，一步步来，总能找到根因。