调试Express必须用"type": "node"而非"pwa-node"，因后者对app.listen()支持不稳定；推荐attach模式配合node --inspect-brk手动启动，并确保app.listen()仅在./bin/www中调用、env变量手动注入或通过envFile加载。
调试前必须确认 launch.json 里用了 node 类型而非 pwa-node
VSCode 默认调试器在较新版本中会倾向用 pwa-node，但它对 Express 的 app.listen() 启动方式支持不稳定——常见现象是断点不命中、进程秒退、console.log 不输出。必须手动指定为 node 类型。
操作路径：.vscode/launch.json → configurations 数组中确保 "type": "node"，不是 "pwa-node"。
- 如果项目用 TypeScript，需额外配
preLaunchTask编译，否则调试的是 .ts 源码而非生成的 .js - 若用
nodemon启动（如nodemon ./bin/www），不能直接调试，得改用node --inspect-brk启动原始入口 -
port字段默认是 9229，若被占用需显式改写，比如"port": 9230
attach 模式比 launch 更稳，尤其配合 npm start
Express 项目常通过 npm start（背后是 node ./bin/www 或 node app.js）启动，此时用 launch 容易因路径或工作目录错位失败。推荐用 attach 模式：先手动启服务，再让 VSCode 连上去。
关键配置项：
"request": "attach"-
"processId": 0（留空，靠自动发现）或删掉该字段 -
"port": 9229必须与启动时的--inspect端口一致 - 启动命令示例：
node --inspect=9229 ./bin/www（Linux/macOS）或node --inspect=9229 .\bin\www（Windows）
断点不生效？检查 Express 入口是否被 require 多次
Express 默认模板（如 express-generator）常把 app.listen() 放在 ./bin/www，而 app.js 只导出 app 实例。如果在 app.js 里加了 app.listen() 又在 www 里也调了一次，会导致 Node 进程启动两次——调试器只 attach 到第一个，第二个无调试上下文。
正确做法：
-
app.js只负责定义和配置app，**不调用listen** -
./bin/www负责require('./../app')并调用app.listen() - 调试时，断点应打在
./bin/www的app.listen()行，或路由处理函数内部
环境变量没加载？别依赖 .env 自动读取
VSCode 调试器默认不加载 .env 文件，process.env 里看不到 PORT、NODE_ENV 等值，导致 Express 启动端口错乱或配置失效。
两种可靠方案：
- 在
launch.json的configurations中加"envFile": "${workspaceFolder}/.env"（仅 VSCode 1.75+ 支持） - 更通用的做法：加
"env": { "NODE_ENV": "development", "PORT": "3000" }手动注入 - 若用
dotenv，确保它在app.js最顶部执行：require('dotenv').config()，且.env在项目根目录
调试 Express 的核心其实是控制好 Node 进程生命周期和调试通道对齐——不是配得越全越好，而是让 VSCode 的 debugger 和 Express 的实际启动方式严丝合缝。最容易被忽略的是 app.listen() 的归属位置和 env 加载时机，这两处一错，断点就形同虚设。
