WebStorm 无法直接调试 WebSocket 协议层，需通过 Chrome DevTools 的 Network → WS 标签页查看连接与帧，并在 onopen/onmessage 回调中设断点查业务逻辑；常见无法显示 WS 连接的原因包括未启用 JetBrains IDE Support 插件、内置服务器未开启或访问了非 WebStorm 启动的本地服务地址。
WebSocket 对象，且 sourcemap 正确、服务端暴露了可映射的前端资源。
也就是说：你不是在 WebStorm 里“断点进 WebSocket 协议层”，而是在它启动的 Chrome 实例中，利用 DevTools 的 Network → WS 标签页看连接、帧、关闭原因；同时靠 WebStorm 的 JS 断点，停在 onopen、onmessage 等回调里查业务逻辑。
为什么 Chrome 的 Network → WS 标签页看不到连接？
常见原因有三个，按优先级排查：
- 没装 JetBrains IDE Support 插件，或插件未启用（尤其无痕模式下默认禁用）
- WebStorm 内置服务器没开，或端口被占——检查
Ctrl+Alt+S → Build, Execution, Deployment → Debugger → Built-in server port是否为63342，且未勾选Disable built-in server - 你访问的 URL 不是 WebStorm 提供的地址（如
http://localhost:63342/index.html），而是自己启的vue-cli或vite开发服务器（比如http://localhost:5173）。这种情况下，WebStorm 完全不参与调试，Chrome 是独立连接的，DevTools 的 WS 面板能显示连接，但 WebStorm 断点不会命中
WebSocket 回调里断点跳来跳去，怎么只停在我写的代码里？
Vue 3 / React 等框架会把 onmessage 包进 Proxy 或 effect 嵌套调用中，导致单步时频繁进入框架内部。这不是 WebStorm 配置问题，而是 sourcemap 映射层级太深。解决办法只有两个：
- 在
onmessage回调第一行加debugger，然后在 Chrome DevTools 里右键该行 →Blackbox content script（把框架代码设为黑盒），之后 F8 就只在你代码里走 - WebStorm 中右键断点 →
More… → Skip all library files，强制跳过node_modules和框架源码
onopen 同样有效，但对 onclose 效果有限——因为关闭事件常由网络层触发，堆栈本身就短。
想看 WebSocket 发送/接收的原始数据帧，WebStorm 能做到吗？
不能。WebStorm 没有解析 WebSocket 数据帧的能力，也不提供十六进制视图。你必须用 Chrome DevTools：
- 打开
Network → Filter → WS - 点击对应连接 → 切到
Messages子标签页 - 所有文本帧显示为 UTF-8 字符串，二进制帧显示为
[binary]（无法展开）
Wireshark 抓包（过滤 websocket），或在服务端加日志打印 ByteBuffer.array()。
真正容易被忽略的是：WebSocket 连接生命周期和调试时机强耦合。比如你在 onopen 里发了一条消息，但服务端响应延迟，onmessage 在几秒后才触发——这时你如果只在连接建立后立刻暂停，会错过后续帧。必须把断点设在回调函数体内，而不是连接创建那一行。
