VSCode中Node环境针对Express/Koa中间件异常的链路诊断

调试 Node.js 服务时，最让人抓狂的场景莫过于：断点明明设好了，调试器也启动了，但代码就是不停。你盯着那个红色圆点看了半天，最后发现根本原因——请求还没走到那行代码，中间件栈已经提前终结了。这种情况在 Express 和 Koa 项目里尤其常见，今天就来拆解几个最容易被忽视的环节。

断点不触发？先验证请求是否进入中间件链

在 Express 或 Koa 里设了断点却始终不触发，这大概率并不是调试器出了故障，而是请求压根就没有走到那行代码——比如 express.json() 因为 body 格式错误直接返回 400，后续所有中间件和路由自然都不会执行；又或者某个鉴权中间件提前 return res.status(401).end()，直接把响应链掐断了。

具体怎么操作？第一个中间件里加个 console.log('middleware hit') 或者直接设断点，然后用 curl -v http://localhost:3000/api/users 触发请求，看终端有没有输出。没输出？那说明请求连入口都没进。另外，检查一下 app.set('trust proxy', true) 是否误配，这玩意儿会导致 req.ip 解析失败，让下游的频率限制或白名单中间件直接 return。还有一个容易忽略的点：确保错误处理中间件 app.use((err, req, res, next) => { ... }) 放在所有 app.use 之后，再在里面设断点，看看是不是有未捕获的异常提前中断了流程。

launch.json 的 program 必须指向可执行的 .js 文件

VSCode 不会帮你编译 TypeScript，也不理解 ESM 的 import 语法。program 字段只能填能被 node 直接运行的路径。如果你写成 "${workspaceFolder}/src/server.ts" 或 "${workspaceFolder}/index.mjs"，调试器启动后不会报错，但断点就是静默失效——节点根本找不到可执行入口。

三种场景分别处理：TypeScript 项目，用 tsc 编译出 dist/，把 program 指向 "${workspaceFolder}/dist/server.js"，同时确保 tsconfig.json 中开启了 "sourceMap": true。ESM 项目，Node 版本需要 ≥18.17，且 package.json 中有 "type": "module"，此时 program 可以指向 .mjs，但必须同步在 launch.json 里追加 "runtimeArgs": ["--loader", "ts-node/esm"]（如果用了 ts-node）。如果项目是通过 npm start 启动的，别硬写 program——改用 "runtimeExecutable": "npm" 搭配 "args": ["start"]，这样能避免入口路径和实际运行逻辑脱节。

用 attach 模式比 launch 更稳，尤其对 Web 服务

Express 或 Koa 这类长期监听端口的服务，如果用 request: "launch"，很容易卡在端口占用、环境变量隔离、子进程 fork 这些坑上。而 request: "attach" 的逻辑更纯粹：你先手动把服务跑起来，VSCode 再连上去调试，控制权完全在你手里。

实操步骤很简单：终端执行 node --inspect-brk ./bin/www（注意加 --inspect-brk 让进程停在第一行），然后在 VSCode 里选 attach 配置启动。必须确保 launch.json 中的 "port" 和启动命令一致——如果用了 --inspect=9230，配置里就得写 "port": 9230，否则连不上。Windows 下 cmd 有时连不上，换成 PowerShell；Mac/Linux 若连不上，试试 --inspect=0.0.0.0:9229 并配 "address": "0.0.0.0"。最后切记：不要同时跑两个 --inspect 进程，第二个会报 Could not connect to debug target 错误。

中间件异常时，调试器可能根本没机会介入

有些错误发生在 Node 启动阶段或模块加载期——比如 require() 失败、process.env 缺失导致配置解析崩溃。这种情况下服务甚至没走到 app.listen()，调试器自然无法注入。这类问题在 attach 模式里更难捕获，因为进程压根没起来。

建议启动时加 --trace-warnings 或 --throw-deprecation，把隐性警告变成显性错误，方便定位早期失败点。同时在入口文件顶部加一句 console.log('server starting...')，确认是否执行到这一行——没输出说明卡在 require 或顶层代码里。还要检查 process.env.PORT 是否被正确读取，尤其是代码里写了 app.listen(process.env.PORT || 3000)，但忘了在 launch.json 里配 "env": { "PORT": "3001" }，这会导致端口冲突或绑定失败。

真正卡住调试的，往往不是断点设得不对，而是请求还没穿过中间件栈、代码还没执行到可调试位置、或者调试器根本没连上那个进程。盯着红点不动之前，先确认服务是否真收到了请求、入口是否被正确加载、调试端口是否唯一可用。