在 JavaScript 中调试 WebSocket 应直接在 onmessage 回调入口和 send() 调用出口设断点，以捕获原始收发报文；配合 Network 面板 Frames 标签验证帧级细节，并注意监听时机、连接状态及二进制数据解码。
在 JavaScript 中调试 WebSocket 实时通信报文，关键不是“等消息来了再断点”，而是把断点精准卡在消息进出的**第一现场**——即原生 API 的事件回调入口和发送出口。浏览器开发者工具已经为此提供了直接支持，不需要额外插件或代理。
在 onmessage 里设断点，捕获服务端推送的原始数据
WebSocket 的 onmessage 回调是服务端消息到达浏览器后的第一个可执行 JS 位置。在这里打断点，能直接看到未经业务逻辑处理的原始 payload：
- 打开 DevTools → Sources 面板 → 找到初始化 WebSocket 的代码（比如
const ws = new WebSocket(...)） - 在
ws.onmessage = function(event) { ... }的花括号第一行加断点（或直接在事件监听器内部写debugger;） - 触发服务端推送后，执行会停住，
event.data就是原始报文——它可能是字符串、Blob 或 ArrayBuffer，类型取决于服务端发送方式 - 右键
event.data→ “Store as global variable”，就能在 Console 里用temp1查看内容；如果是 Blob，可用await temp1.text()解析成文本
在 send() 调用前设断点，观察客户端发出的报文结构
所有发往服务端的消息都必须经过 ws.send()。在这个方法调用前打断点，可以确认你传进去的数据是否符合预期：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 在调用
ws.send(msg)的那一行左侧 gutter 点击设断点 - 运行到此处时，检查
msg变量：是纯字符串？JSON.stringify 过的？还是已序列化的 ArrayBuffer？ - 注意：WebSocket 不自动做 JSON 序列化，如果你传的是对象，会抛错；必须手动
send(JSON.stringify(obj)) - 如果项目用了封装层（如 socket.io-client），断点要下在最终调用原生
send()的地方，而不是业务层的emit()
用 Network 面板辅助验证，看清帧级细节
DevTools 的 Network 面板虽不显示每帧内容，但能确认连接状态和消息计数，配合断点更可靠：
- F5 刷新页面，在 Network → Filter 输入
ws或点击 WS 标签，找到你的 WebSocket 连接 - 点击该连接 → 右侧 Frames 标签页：能看到每条消息的时间、方向（→ 客户端发出，← 服务端推送）、数据长度和预览（对文本类 payload 会显示前 100 字符）
- 如果 Frames 为空，说明消息没走 WebSocket（可能被拦截、降级或连接已断），此时断点可能根本不会触发
- 若发现某条消息在 Frames 里有记录，但在
onmessage断点没停住，大概率是事件监听器绑定晚于消息到达（常见于未等open就发了订阅指令）
避免常见干扰：确保断点落在真实通信路径上
很多“收不到消息”的问题其实和断点无关，而是监听时机或连接状态不对：
- 不要在
new WebSocket()后立刻绑定onmessage，应优先监听open事件，确保连接就绪后再设监听 - 如果使用
addEventListener('message', ...)，注意它和onmessage是互斥的——设了后者，前者不会触发 - 某些 CDN 或代理会静默关闭空闲 WebSocket 连接，导致
onclose触发但你没设断点，建议同时在onclose和onerror加debugger - 服务端若发送二进制帧（如
ArrayBuffer），event.data不是字符串，直接console.log会显示[object ArrayBuffer]，需用new TextDecoder().decode(event.data)查看内容
