调试子进程IPC前必须确认三件事：一是fork时指定execArgv: ['--inspect-brk=9230']，二是主子进程均启用sourceMaps，三是IPC消息体避免循环引用；否则VS Code无法正确显示数据结构与序列化行为。
子进程IPC调试前必须确认的三件事
VS Code 默认不监听 process.send() 和 process.on('message') 的通信内容，光靠断点停在 send 或 on 行，看不到实际传输的数据结构、序列化副作用或跨进程时序问题。调试 IPC 高频交互，首先要确保底层通信通道本身可观察——这依赖三个硬性前提：
-
child_process.fork()必须带execArgv: ['--inspect-brk=9230']（不能只靠autoAttachChildProcesses: true） - 主进程和子进程都启用
sourceMaps，否则message对象展开后全是[Object]，无法看到原型链或 Symbol 属性 - IPC 消息体不能是循环引用对象，Node.js 的
process.send()会静默丢弃它，但 VS Code 不报错，只显示空消息
launch.json 中 autoAttachChildProcesses 的真实行为边界
autoAttachChildProcesses: true 只对两类创建方式生效：child_process.fork() 和 Worker 构造函数。它不会捕获 spawn('node', [...]) 或 exec() 启动的子进程，除非你手动加 NODE_OPTIONS='--inspect-brk=9231' 到 env。更关键的是：它只附加进程，不自动注入 IPC 监听逻辑——你仍需在子进程中手动写 process.on('message', console.log) 才能在 Debug Console 看到原始 payload。
常见误判场景：
- 用
fork('./worker.js')启动，但没传execArgv→ 子进程无调试端口，autoAttachChildProcesses彻底失效 - 子进程里用了
setInterval(() => process.send({ ts: Date.now() }), 10)→ VS Code 断点能停，但 Debug Console 不自动打印每次 message，需手动加日志 - 主进程用
child.send({ data: new Map([['a', 1]]) })→ 子进程收到的是 plain object，Map 被序列化丢失，但断点看不出区别
高频 IPC 下如何避免调试器卡死或消息丢失
当每秒发送 >50 条消息时，VS Code 的调试器 UI 会因频繁刷新 Variables 面板而明显延迟，甚至触发 timeout: 10000 中断。这不是代码问题，而是调试协议本身的吞吐限制。真正有效的缓解方式只有三条：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 在子进程入口处加
process.on('message', m => { if (m.debug === false) return; console.dir(m, { depth: 10 }); })，把关键消息导出到 Terminal，而非全靠 Debugger 面板 - 关闭 launch.json 中的
trace: true（它会记录所有 DAP 协议帧，加剧卡顿） - 用
process.send()前加节流：高频场景下，宁可丢几条中间状态，也要保证至少一条完整消息能抵达 Debugger —— 比如用setTimeout去抖动发送，而非setImmediate
IPC 数据结构差异导致的断点“命中却无数据”
最隐蔽的问题不是断点不触发，而是触发后 message 变量为空或类型错误。根本原因在于 Node.js IPC 底层使用 serialization（非 JSON），它支持 Date、RegExp、ArrayBuffer，但不支持 function、undefined、Symbol 或循环引用。这些值在跨进程时被静默过滤或替换成 null，而 VS Code 的 Variables 面板不会标出“此字段已被序列化截断”。
验证方法很简单：
- 在子进程
process.on('message', msg => { console.log('raw:', msg); debugger; })，对比 Terminal 输出和 Variables 面板里的msg - 若 Terminal 有
{ time: 2026-06-30T12:00:00.000Z }，Variables 里却是{ time: null }→ 说明Date被序列化为字符串再反序列化失败，需改用time.getTime()传数字戳 - 若消息含
new Error('oops')→ 它会被降级为 plain object，stack字段丢失，必须手动JSON.stringify(error.stack)再传
IPC 调试真正的复杂点不在连接，而在序列化契约——你得亲手验证每一类业务数据是否能完整穿越进程边界，VS Code 不会替你做这件事。
