子线程调试卡在 EADDRINUSE 是因未显式指定调试端口导致端口冲突；需为每个子线程手动配置唯一 --inspect-brk 端口（如 9230、9231），并在 launch.json 中添加对应 attach 配置，同时注意清理残留 TIME_WAIT 连接。

为什么子线程调试会卡在 EADDRINUSE？

node --inspect 启动主进程时默认监听 9229，但子线程（如 worker_threads 或 child_process.fork）若没显式指定 --inspect-brk 和端口，Node 会自动分配下一个可用端口——而这个“自动分配”常撞上主进程的 9229 或其他已用端口，尤其在 VS Code 反复启动/中断后残留套接字未释放时。错误现象是调试器连不上、断点灰色、控制台报 Error: listen EADDRINUSE: address already in use :::9230。

关键不是端口“不够用”，而是子线程没被纳入调试器统一管理，导致它自己乱抢端口。

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

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

下载

如何让每个子线程用独立且可控的调试端口？

子线程必须显式启用调试，并避开主进程和其他子线程的端口。VS Code 不会自动为子线程分配端口，你得手动算好、传进去。

• 主进程用 9229（或你设的固定端口），子线程从 9230 开始递增，比如第一个子线程用 9230，第二个用 9231
• 用 worker_threads 时，在 Worker 构造选项里传 execArgv：

  new Worker('./worker.js', {<br>  execArgv: ['--inspect-brk=127.0.0.1:9230']<br>});

• 用 child_process.fork 时，同样传 execArgv：

  fork('./worker.js', [], {<br>  execArgv: ['--inspect-brk=127.0.0.1:9231']<br>});

• 端口必须写完整地址 127.0.0.1:9230，不能只写 :9230，否则可能绑定到 0.0.0.0，触发权限或冲突问题

launch.json 怎么配才能连上子线程？

VS Code 默认只 attach 主进程，子线程要单独配置 attach 类型的 configuration，并确保 port 和子线程实际监听的一致。

• 在 .vscode/launch.json 里加一个新 configuration：

  {<br>  "type": "node",<br>  "request": "attach",<br>  "name": "Attach to Worker",<br>  "port": 9230,<br>  "address": "127.0.0.1",<br>  "restart": true,<br>  "sourceMaps": true,<br>  "outFiles": ["${workspaceFolder}/dist/**/*.js"]<br>}

• 不要依赖 "port": "${env:PORT}" —— 子线程端口必须硬编码匹配，环境变量无法动态同步到 fork 的子进程中
• 启动顺序：先跑主进程（它会拉起子线程），等几秒再手动点击 “Attach to Worker” 配置，不能同时 launch 两个进程
• 如果子线程启动太快、VS Code 还没准备好 attach，可在子线程代码开头加 debugger; 并配合 --inspect-brk，让它停住等连接

为什么 kill -9 之后还是 EADDRINUSE？

子线程进程退出时，V8 调试器 socket 常处于 TIME_WAIT 状态，尤其在 Ctrl+C 中断或调试会话异常断开时。这不是系统级端口占用，而是内核网络栈残留。

• 别只杀主进程 PID —— 子线程是独立进程，有自己的 PID，需单独查：lsof -i :9230（macOS/Linux）或 Get-NetTCPConnection -LocalPort 9230（Windows PowerShell）
• 查到 PID 后，先 kill <code>PID（发 SIGTERM），等 1–2 秒；没反应再 kill -9 <code>PID
• 更稳妥的做法：改用更高端口区间（如 9300–9400），避开 9229–9299 这个被各种工具默认扫描的范围
• 长期方案：在子线程代码里加优雅关闭逻辑，监听 process.on('SIGTERM', ...) 并调用 process._debugEnd()（非公开 API，慎用）或直接 process.exit()

真正麻烦的不是端口不够，而是每个子线程都得手动管端口、手动 attach、手动清理——稍一疏忽，9230 就变成下一个 9229。