根本原因是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')执行完毕或消息通道就绪
execArgv遗漏、autoAttachChildProcesses未启用，这三处任一出错，你看到的就只是“断点不生效”的假象。
