必须开启autoattachchildprocesses:true，因为它是vs code自动附加fork子进程和worker threads的唯一开关，否则子进程无--inspect参数，断点不触发、变量不可查；需配合execargv传参、端口配置及sourcemap。
VSCode 无法直接调试多端通信本身，但能分别调试每个 Node 进程，并通过正确配置让它们在调试中“可感知彼此”——关键不是连通性，而是各端独立可断点、变量可查、调用栈不丢失。
为什么autoAttachChildProcesses必须开启
多端通信（如主进程 ↔ Worker Thread、parent ↔ child_process.fork()）本质是多个独立 Node 进程间通信。若只启动主进程调试，子进程默认无 --inspect 参数，VS Code 根本看不到它们——断点不触发、变量不可查、console.log 和 debugger 都失效。
-
autoAttachChildProcesses: true是唯一让 VS Code 主动监听并自动附加新子进程的开关，不是可选项 - 它仅对
child_process.fork()和new Worker()生效；spawn()必须手动加--inspect才被识别 - 若项目用
ts-node或esbuild-node启动，该机制会失效——因为它们绕过了标准 Node 启动流程
Worker线程调试必须传execArgv参数
Node 的 Worker 默认不暴露调试端口，即使开了 autoAttachChildProcesses，也会跳过附加。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 错误写法：
new Worker('./worker.js')→ 子线程无调试能力 - 正确写法：
new Worker('./worker.js', { execArgv: ['--inspect-brk=9230'] }) -
launch.json中需匹配："port": 9230，且确保该端口未被占用 - 多个 Worker 实例共用同一端口会导致只连上第一个——建议不指定端口，让 Node 自动分配（即用
--inspect-brk不带端口号）
fork()子进程调试失败的常见原因
用 fork() 启动子进程却无法断点？大概率是没传调试参数。
- 错误：
fork('./sub.js')→ 子进程完全不知道自己该被调试 - 正确：
fork('./sub.js', [], { execArgv: ['--inspect=9231'] }) - macOS/Linux 下若用
nvm管理 Node 版本，launch.json中必须显式指定"runtimeExecutable"，否则子进程可能用错 Node 版本 -
--inspect和--inspect-brk区别：后者会在第一行暂停等待调试器连接；前者直接执行，容易错过断点
调试跨进程通信逻辑时容易忽略的点
即使所有进程都成功附加，postMessage()、send()、on('message') 这类通信代码仍难定位问题——因为断点在发送端命中，接收端未必同步停住。
- 不要依赖“两端同时断点”，而应分别在发送方和接收方加
debugger或断点，观察各自执行时机 -
Worker内部的self.postMessage()和主线程的worker.onmessage是两个独立上下文，变量作用域不共享 - 检查
message序列化限制：函数、循环引用、undefined会被丢弃，调试时可用console.dir()查看实际传递内容 - 若用
child_process的send()/message，确保父子进程都监听了'message'事件，且未被process.on('uncaughtException')意外吞掉错误
