VSCode调试Fastify集群时断点仅主进程生效，因默认不自动连接worker子进程；须为每个worker配置独立--inspect端口及对应launch.json项，或禁用集群改单进程调试。
VSCode 调试 Fastify 集群进程时断点只在主进程生效？
不是配置错了，是默认调试器只 attach 到单个 node 进程——cluster 模式下每个 worker 都是独立进程，VSCode 默认不自动连接子进程。
必须手动为每个 worker 启用独立调试端口，否则你打的断点只会命中主进程（它基本不处理 HTTP 请求），worker 里的路由逻辑完全无法调试。
-
cluster.fork()启动子进程时，需显式传入--inspect=0.0.0.0:9230、--inspect=0.0.0.0:9231等不同端口，不能复用同一端口 - 主进程启动用
node --inspect=0.0.0.0:9229 cluster.js，worker 启动命令里要动态加端口参数，例如：fork({ execArgv: ['--inspect=0.0.0.0:923' + i] }) - VSCode 的
launch.json不能只配一个 attach，得为每个预期 worker 配独立配置项，或改用 multi-session attach（需 VSCode 1.80+） - 更稳妥的做法：先禁用集群（
process.env.NODE_ENV !== 'production'时跳过cluster.isPrimary分支），本地开发阶段用单进程 +--inspect=0.0.0.0:9229调试；压测时再开集群
autocannon 压测 Fastify 集群时 RPS 上不去？检查这三处
集群跑起来了不代表性能线性提升——常见瓶颈不在 Fastify 本身，而在 OS 层或 Node.js 运行时配置。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 确认
numCPUs没写死为1：用require('os').cpus().length动态获取，别硬编码；WSL 或 Docker 容器里可能只暴露 1 核，需通过docker run --cpus=4显式分配 - Fastify 实例不能在主进程中创建：必须在每个 worker 的
cluster.isWorker分支内调用require('./fastify')()，否则所有 worker 共享同一个实例，底层 TCP 连接池被争抢 - 检查
fastify.listen()是否用了host: '0.0.0.0'：默认host: '127.0.0.1'在某些 Linux 发行版上会触发 IPv6 回退延迟，压测时连接建立慢，RPS 直接掉 30%+
本地集群测试中 worker 进程频繁退出？看日志里的 EADDRINUSE
现象是某个 worker 启动几秒后 crash，log 出现 Error: listen EADDRINUSE: address already in use 127.0.0.1:3000 ——这不是端口冲突，而是 cluster 模块共享句柄失败的典型表现。
- 根本原因是 Fastify 实例在 fork 前就调用了
listen()：主进程已绑定端口，worker 再 bind 就报错。正确做法是只在cluster.isWorker分支里调用fastify.listen() - 如果用了
fastify.register()加载插件，确保插件内部没提前执行fastify.listen()或监听全局事件（如process.on('SIGTERM')） - Windows 下尤其敏感：启用
cluster.schedulingPolicy = cluster.SCHED_RR（轮询调度），避免默认的SCHED_NONE导致多个 worker 同时竞争 accept 队列
如何验证本地集群真正在并行处理请求？
别只看 CPU 使用率——Node.js 单线程模型下，即使开了 8 个 worker，CPU 可能只跑 120%，但吞吐已翻倍。关键看请求是否被分散到不同 PID。
- 在路由 handler 里打印
process.pid：fastify.get('/', () => ({ pid: process.pid }))，用 curl 或 autocannon 并发请求，观察返回的pid是否变化 - 用
lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows）确认多个进程都处于LISTEN状态，且PID列有多个值 - 真正压测时，加
--latency参数跑 autocannon：autocannon -c 100 -d 10 --latency http://localhost:3000/，看Latency p99是否随并发增加缓慢上升（健康曲线），而非陡升（说明某环节串行阻塞）
本地集群测试最易被忽略的点：没关掉 IDE 自带的文件监听（如 VSCode 的 file watcher）、杀毒软件实时扫描、或 macOS 的 Spotlight 索引——这些后台 I/O 会抢占 event loop，让 worker 表现得像单核一样卡顿。
