你以为WebRTC通话出了问题只能等用户截图给你？今天Chrome 155终于把诊断日志做进了浏览器API

做过 WebRTC 的人都踩过这个坑——通话卡了、黑屏了、连不上了，生产环境的问题根本没法本地复现。用户不知道去哪抓日志，开发者只能一步步教：打开 chrome://webrtc-internals，复制所有内容，粘贴到 Bug 里。这件事，Chrome 155 今天把它做进了浏览器 API。

WebRTC Diagnostic Logging API 是 W3C/WICG 推进的标准（chromestatus.com/feature/5091582546149376），Chrome 155 桌面版默认启用。核心就三个方法：startDiagnosticLogging() 启动日志收集并返回一个 UUID；stopDiagnosticLogging() 停止并生成可用日志；cancelDiagnosticLogging() 直接丢弃，兼顾隐私。metadata 字典最多 5 对键值、每对限长 100 字符，防止被用来做指纹追踪。

日志生成后，应用拿到一个 session ID，这个 ID 可以直接附到 Chromium 的 Bug 报告里——和崩溃报告的 report ID 逻辑一样，开发者再也不用让用户手动导出那堆看不懂的文本。

这件事真正的价值在哪？以前 chrome://webrtc-internals 是被动记录所有会话，出了问题靠用户截图；现在有了 startDiagnosticLogging()，开发者可以在用户点击「报告问题」的同一时刻主动触发日志，把当时那一次会话的完整诊断数据收下来。用户不用找浏览器地址栏，报告里自带 session ID，开发者拿到的是结构化的内部状态而不是一段复制粘贴的乱码。

安全设计上，日志收集默认关闭，企业策略 WebRtcDiagnosticLogCollectionAllowedForOrigins 白名单才放行，PII 最小化，UA 不向站点暴露用户是否开启了日志选项。

落地三步：1）User-Agent 检测 Chrome 155 及以上；2）包装 RTCPeerConnection 构造函数，加 try/catch 兼容暂不支持的浏览器；3）生产问题反馈按钮里串 startDiagnosticLogging() → session ID → 上报。Enterprise IT 可以通过 WebRtcDiagnosticLogCollectionAllowedForOrigins 策略给自家内部工具批量授权。

目前支持情况：Chrome 155 桌面版（Windows/Mac/Linux/ChromeOS）默认启用，Android WebView 暂无信号，Firefox/Safari 均 No Signal。还在调试阶段的项目，建议渐进增强：if (pc.startDiagnosticLogging) { … }。

数据来源：Chrome Platform Status 官方 Feature 说明；W3C WebRTC Extensions 规范草案；blink-dev 邮件列表 Intent to Experiment 审核记录；生产 WebRTC 调试痛点数据。