中间件断点不触发？先确认它是否真被调用：Express执行顺序是线性的，若前面中间件未调用next()、调用next('route')或直接res.send()，后续中间件将彻底跳过；需检查挂载位置、路径匹配、异步处理、环境变量及runtimeExecutable配置。
中间件断点不触发？先确认它是否真被调用
在 app.use() 或路由级中间件里打了断点却跳过，大概率不是调试配置问题，而是中间件根本没执行。Express 的执行顺序是线性的，一旦前面的中间件 next() 没调用、或调用了 next('route')、或直接 res.send()，后续中间件就彻底跳过。
实操建议：
- 检查中间件注册位置：全局中间件必须写在
app.get()之前；路由级中间件（如router.use()）要确保该router已通过app.use('/path', router)挂载 - 确认请求路径匹配：比如
app.use('/api', middleware)，但你访问的是/user，中间件就不会进 - 避免在中间件里漏掉
next()：尤其自定义日志、权限校验类中间件，忘记调用会导致请求挂起，VSCode 调试器也会卡住 - 动态路由参数不影响中间件触发：但若中间件挂载在
/user/:id这种具体路由上（非常规），需确保 URL 含有效:id值
launch.json 中 runtimeExecutable 必须指向实际运行器
VSCode 不会自动猜你用的是 node 还是 nodemon，更不会继承终端的 nvm 环境。如果用 nodemon --inspect-brk=9229 app.js 启动，但 launch.json 里 runtimeExecutable 还是空着或填了 node，调试器连不上，所有断点都无效。
实操建议：
- 在终端运行
which nodemon（macOS/Linux）或where nodemon（Windows），把输出路径完整填进runtimeExecutable -
program字段只写入口文件名，如"program": "app.js"，别带路径或命令前缀 - 如果用
npm run dev启动，launch.json的console设为"integratedTerminal"，否则 VSCode 可能无法转发SIGUSR2信号，导致热重载失败 - 多版本 Node 用户务必验证：VSCode 终端里
node -v和which node输出的路径，要和runtimeExecutable一致
中间件里读文件/查数据库时断点失效？检查异步处理
在中间件中调用 fs.readFileSync() 打断点通常没问题，但换成 fs.readFile() 或 await db.query() 后断点跳过，往往是因为没正确 await 或没处理 Promise rejection，导致中间件提前退出。
实操建议：
- 异步中间件函数必须声明为
async，且调用处必须await：例如app.use(async (req, res, next) => { const data = await fs.promises.readFile('config.json'); next(); }) - 不要在
try/catch外层漏掉next(err)：Promise reject 若没被捕获，Express 默认 500，但断点不会停在中间件内部 -
skipFiles别误伤：如果launch.json里设置了"skipFiles": ["**/node_modules/**"]，而你用的 ORM（如 Prisma）生成代码在node_modules下，它的回调可能也被跳过——临时注释这行再试 - 调试时加一句
console.log('middleware hit')对比：如果 log 有、断点没停，基本锁定是异步流或调试器未 attach 成功
环境变量未生效导致中间件行为异常
中间件常依赖 process.env.NODE_ENV 或 process.env.JWT_SECRET，但 VSCode 默认不加载 shell 的 .zshrc 或 .bash_profile，env 字段又没显式配置，结果开发时走测试逻辑、生产时才走真实流程，断点位置完全不对。
实操建议：
-
launch.json的env字段必须手动写全："env": { "NODE_ENV": "development", "PORT": "3000", "JWT_SECRET": "dev-secret" } - 别依赖
export：即使你在终端export NODE_ENV=development后启动 VSCode，内置终端也不会继承这个变量 - WSL 用户额外注意：若服务监听
127.0.0.1，但中间件里写了req.ip判定逻辑，可能因代理头缺失返回::1，这不是断点问题，但会让中间件分支走偏
