如何在VSCode中配置Node环境并结合PM2实现项目负载均衡测试-VSCode-PHP中文网

pm2负载均衡测试在vscode跑不起来，主因是启动方式与调试上下文错配：需显式指定进程数（如-i 4）、禁用守护进程（--no-daemon），并避免在集群模式下用attach调试；真实并发须用ab或autocannon，而非postman runner。

如何在vscode中配置node环境并结合pm2实现项目负载均衡测试

pm2 负载均衡测试在 VSCode 里跑不起来，大概率不是配置漏了，而是启动方式和调试上下文没对齐——你得让 pm2 真的跑出多个进程，同时 VSCode 别试图去 attach 单个实例。

确认 PM2 是否真起了多进程

pm2 start app.js -i max 看似正确，但容易被忽略的是： - -i max 依赖当前 CPU 核数，如果在 Docker 容器或 CI 环境里跑，可能只识别到 1 核，结果只起 1 个进程 - 没加 --no-daemon 时，pm2 list 可能显示状态为 online，但实际进程已 fork 后 detach，导致你在终端看不到输出，误以为没生效 - pm2 show @#@#@#@#@#@#@#@#@#@0 多次，再看 pm2 logs test-load --n 20，确认日志来自不同 id 的进程

VSCode 调试时别混用 attach 和 cluster 模式

你不能一边用 pm2 start -i 4，一边在 launch.json 里配 "request": "attach" 去连某个端口——因为每个 worker 默认不会暴露独立调试端口，--inspect 参数只作用于 master 进程（除非显式透传）。

常见错误现象：

断点不命中，控制台提示 Connection refused
pm2 monit 显示内存/CPUs 分布不均，但日志全挤在 id=0 的进程里

正确做法是：

如果只想测负载均衡行为（不调试），就不用 VSCode attach，直接用 curl 或 jmeter 打并发请求
如果非要调试某一个 worker，先停掉集群：pm2 stop test-load，再单实例启动：pm2 start app.js --node-args="--inspect=9229" --name debug-worker，然后 VSCode 配 attach 到 9229
切记不要在 launch.json 里写 "port": 9229 同时又跑 -i 4，那只会连上第一个 worker，其余 3 个根本没开调试通道

本地测试并发请求时，Postman Runner 不等于并发

很多同学用 Postman 的 Runner 发 100 次请求，发现所有日志都进同一个 id，就以为 pm2 负载没生效。其实 Postman Runner 是串行执行的，HTTP 请求之间有毫秒级间隔，PM2 的 round-robin 调度根本来不及切换。

真实并发需要：

VSCode 1.118

微软正式发布 Visual Studio Code 1.118 版本。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控。

下载

ab -n 100 -c 10 @#@#@#@#@#@#@#@#@#@1（Apache Bench）
或 autocannon -c 10 -d 5 @#@#@#@#@#@#@#@#@#@1（Node 原生工具）
注意：目标接口响应时间要足够短（比如纯返回 {ok: true}），否则长阻塞会掩盖调度效果

另外，Node.js 的 event loop 本身不处理“请求分发”，那是 pm2 在 master 进程里做的 TCP 层负载，所以测试接口千万别带同步死循环（比如 while(true){j++}），否则那个 worker 会卡死，后续请求全 fallback 到其他实例，看起来像“自动均衡”，其实是故障转移，不是正常调度。