根本原因是VS Code默认只连接主进程，Worker进程因未暴露--inspect端口且未被识别而“隐身”；必须在cluster.fork()中显式注入唯一--inspect-brk端口、启用autoAttachChildProcesses并确保主进程port与runtimeArgs一致。

Cluster模式下Worker进程状态同步为何无法断点调试

根本原因不是代码逻辑问题，而是VS Code默认只连接主进程，所有Worker进程处于“隐身”状态——它们既没暴露--inspect端口，也没被调试器识别为可附加目标。你看到的“状态没同步”“变量查不到”，其实是调试器压根没连上对应Worker，自然看不到它的堆栈、闭包或process.send()收发内容。

必须在cluster.fork()中显式注入execArgv并分配唯一端口

Node.js的cluster.fork()不会继承主进程的--inspect参数，也不能靠autoAttachChildProcesses自动捕获——它需要你手动喂参数。端口重复是高频失败点，9229不能复用，否则第二个Worker启动时会报Error: listen EADDRINUSE或静默失败。

用于自动切换项目中适合的node 版本

根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。

下载

• 每个Worker必须带独立--inspect-brk端口，例如['--inspect-brk=9230']、['--inspect-brk=9231']
• 不要写execArgv: ['--inspect-brk']（无端口号），Node会随机分配，但VS Code无法预知，导致autoAttachChildProcesses失效
• 若用ts-node或esbuild-node启动主进程，execArgv会被忽略——此时必须改用node --loader ts-node/esm或直接编译后运行

launch.json里autoAttachChildProcesses必须设为true且port与主进程一致

autoAttachChildProcesses: true不是可选项，它是开关；而port字段只控制主进程监听端口，和Worker端口无关。很多人误以为这里要填Worker端口，结果主进程连不上，整个调试链就断了。

• "port": 9229 → 必须和主进程启动时的--inspect-brk=9229完全一致
• "runtimeArgs": ["--inspect-brk=9229"] → 确保主进程挂起等待连接，否则Worker还没起来主进程就跑完了
• 缺"autoAttachChildProcesses": true，VS Code根本不会扫描子进程，哪怕Worker带了--inspect-brk也白搭

Worker间状态同步调试的关键观察点

真正要验证状态是否同步，不能只看单个Worker里的变量值——得确认消息是否发出、是否被接收、是否被正确解析。断点打在process.on('message')里比打在业务逻辑里更可靠，因为前者能明确告诉你“这条消息进来了没”。

• 在主进程worker.send()后加断点，检查worker.isDead和worker.isConnected是否为true
• 在Worker的process.on('message')回调开头打断点，确认process.pid是否匹配预期Worker
• 避免在cluster.on('online')里打点——它只表示Worker已启动，不代表require('./worker.js')执行完毕或消息通道就绪

Worker进程间状态同步的调试难点不在逻辑本身，而在调试器能否真实“看见”每个Worker的运行上下文。端口冲突、execArgv遗漏、autoAttachChildProcesses未启用，这三处任一出错，你看到的就只是“断点不生效”的假象。