launch.json 中 program 必须为相对于 workspaceFolder 的路径，如 "${workspaceFolder}/src/index.js"；env 会覆盖 envFile 同名变量；TS/Babel 项目需正确配置 sourceMap 和 outFiles 才能命中断点。
VS Code 调试 Node.js 应用不靠“教程套路”，而靠理解 launch.json 里每个字段的真实作用——配错一个参数，Debugger attached 可能永远不来，或者断点直接失效。
为什么 launch.json 里的 program 必须是相对路径？
VS Code 的调试器启动时，工作目录默认是当前打开的文件夹（即 workspaceFolder），program 是相对于这个路径解析的。写成绝对路径或错误的相对路径，Node 进程根本找不到入口文件，会报 Cannot find module 或直接退出。
-
program值应为类似"${workspaceFolder}/src/index.js"，不能是"./src/index.js"（某些旧版 Node 启动器不识别） - 如果入口是 TypeScript，必须先编译，或改用
ts-node：把program换成"${workspaceFolder}/node_modules/.bin/ts-node"，再加"args": ["${workspaceFolder}/src/index.ts"] - 使用
npm start启动？别在launch.json里硬写命令——改用runtimeExecutable+runtimeArgs，但更推荐用compounds或直接调试构建后的 JS
env 和 envFile 到底谁优先？
env 字段定义的环境变量会覆盖 envFile 中同名变量。这不是“补充”，而是明确的覆盖关系。很多开发者以为 envFile 会自动加载 .env 并合并，结果本地 NODE_ENV=development 被 env 里写的 "NODE_ENV": "test" 静默覆盖，导致配置读取异常。
-
envFile只支持单个文件，路径也是相对于workspaceFolder，比如".env.local" - 若项目有多个环境（dev/staging/prod），不要堆砌多个
envFile——用不同 launch 配置分别指定，或在代码里用dotenv手动加载 -
env中避免写敏感值（如 API_KEY），调试配置容易被误提交；敏感项一律走envFile或系统级环境变量
断点不命中？先检查 sourceMaps 和 outFiles
TypeScript 或 Babel 编译项目中，断点打在 TS/JSX 文件上却无效，90% 是因为调试器没找到正确的 source map 映射。VS Code 不会自动猜你用了哪种构建工具，必须显式告诉它。
- TS 项目：确保
tsconfig.json中"sourceMap": true且"outDir"与launch.json中outFiles匹配，例如"outFiles": ["${workspaceFolder}/dist/**/*.js"] - Babel 项目：生成 source map 后，
outFiles要指向编译输出目录，同时设"sourceMaps": true，必要时加"resolveSourceMapLocations": ["${workspaceFolder}/**","!**/node_modules/**"] - 用 ESM +
node --loader ts-node/esm？目前 VS Code 官方调试器对这种 loader 支持不稳定，建议降级到 CJS +ts-nodeCLI 模式更可靠
最常被忽略的一点：修改 launch.json 后，必须重启调试会话（不是重载窗口），否则改动不生效；而且断点只在「启动调试」时加载一次，运行中动态加的断点，若源码已执行过，不会回溯触发。
