WebSocket断点不触发，绝大多数情况是调试器未连上真实代码：program路径错误、未加--inspect-brk、source map未对齐或断点打在异步回调外；需检查launch.json配置、源码映射及手动插入debugger语句验证。
WebSocket 断点在 VS Code Node 环境里不触发，绝大多数情况不是 WebSocket 本身的问题，而是调试器根本没连上你真正运行的那行代码——尤其是 ws 或 socket.io 的连接处理逻辑常被中间件、异步时机或路径映射绕过。
为什么在 ws.on('connection', ...) 里打的断点完全不进
常见现象：服务启动成功、console.log('server listening') 正常输出，但用 wscat -c ws://localhost:3000 连接后，断点毫无反应，甚至调试控制台里连请求日志都没有。
-
program指向的是index.js，但实际入口是bin/www或src/server.js—— 调试器跑了“假入口”，压根没加载 WebSocket 相关逻辑 - 用了
express-ws或socket.io，但ws实例是挂载在 Express 中间件之后才初始化的，而你的断点写在顶层require()后面，此时ws对象还没创建 - Node 进程启动时没带
--inspect-brk（尤其当你用npm run dev封装了命令），VS Code 默认 launch 模式无法注入调试器 - WebSocket 连接被反向代理（如 Nginx）或前端跨域拦截，请求根本没到达 Node 进程 —— 先用
curl -i http://localhost:3000确认 HTTP 路由通，再换wscat
launch.json 必须填对的三项（Node + WebSocket 场景）
别套通用模板。以下配置直接对应典型 Express + ws 手写方案：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug WebSocket Server",
"program": "${workspaceFolder}/src/server.js",
"env": { "NODE_ENV": "development" },
"runtimeArgs": ["--inspect-brk"],
"console": "integratedTerminal",
"skipFiles": ["<node_internals>/**"]
}
]
}
-
program必须指向真实启动文件，且该文件里已执行const wss = new WebSocket.Server(...)或等价初始化 -
runtimeArgs显式加--inspect-brk：避免某些 npm script 包装器（如ts-node-dev）吞掉调试参数 -
console设为integratedTerminal：方便第一时间看到WebSocket server running on ws://...日志，确认服务真起来了
WebSocket 连接建立后的断点为何跳到 .js 而非 .ts 源码
TypeScript 项目里，在 src/ws/handler.ts 的 on('message', ...) 打断点，结果停在 dist/ws/handler.js 且变量名是 _a、_b —— 这是 source map 完全失效的表现。
-
tsconfig.json中必须有"sourceMap": true，且"outDir"和launch.json中的outFiles路径严格匹配，例如："outFiles": ["${workspaceFolder}/dist/**/*.js"] - 如果用
ts-node直接跑 TS 源码（不编译），则launch.json里要改"type": "pwa-node"，并加"runtimeExecutable": "npx"和"runtimeArgs": ["ts-node", "--project", "tsconfig.json"] - 验证是否生效：启动调试后，在「调试控制台」搜
Loaded source map from，看到类似Loaded source map from 'file:///xxx/dist/ws/handler.js.map'且无 404，才算真正就绪
如何精准命中 on('message') 这类动态回调里的断点
WebSocket 的消息处理函数是运行时注册的，VS Code 有时会因作用域延迟或闭包丢失而无法绑定断点。不要只依赖行号点击。
- 在回调函数第一行写
debugger;语句，比 GUI 断点更可靠 —— 它强制在 V8 层暂停，不受 source map 解析失败影响 - 右键断点 →「编辑断点」→ 输入条件如
data && data.toString().includes('ping')，避免每次发消息都中断 - 若用
socket.io，注意它封装了底层ws，断点应设在socket.on('event', ...)内部，而非原始ws.on('message', ...) - 检查
ws实例是否被复用：多个连接共用一个wss，但每个ws是独立对象；断点打在连接实例上（ws.on('message', ...)）比打在wss.on('connection', ...)更易观察单次通信
最常被忽略的一点：WebSocket 是长连接，断点只在首次连接或收到消息时触发。如果你改了代码又热重载（比如用 nodemon），旧连接不会自动销毁，新断点对已有 socket 无效 —— 必须手动关闭客户端再重连，或重启整个调试会话。
