vscode调试node.js核心在于launch.json精准匹配运行时行为：program须指向js入口文件（如"${workspacefolder}/src/index.js"），子进程调试必设autoattachchildprocesses:true并配合--inspect-brk及唯一端口，ts/esm项目需额外配置node_options启用source-maps。
VSCode 调试 Node.js 的核心不在装多少插件，而在 launch.json 是否精准匹配运行时行为——错配 program、漏设 autoAttachChildProcesses、或混淆 --inspect 与 --inspect-brk，都会导致断点失效、子进程不可调试、甚至调试器连接超时。
launch.json 中 program 和 runtimeExecutable 到底该填什么？
很多人把 program 当成“要跑的文件”，但实际它只在 request: "launch" 且 type: "node" 时生效；一旦你用 nodemon 或 ts-node 启动，就得靠 runtimeExecutable + runtimeArgs 控制真正执行的命令。
-
program应始终指向 JS 入口文件（如"${workspaceFolder}/src/index.js"），不能是 TypeScript 文件（.ts）或打包产物（dist/index.js），否则 source map 映射失败，断点变空心 -
runtimeExecutable填绝对路径或可执行名：本地安装的nodemon要写"${workspaceFolder}/node_modules/.bin/nodemon"（Windows 下加.cmd后缀），全局安装则写"nodemon"，但后者在 macOS/Linux 下可能因 nvm 环境不一致而启动失败 - 如果项目用
pnpm或yarn，别硬套 npm 路径 ——runtimeExecutable可直接设为"pnpm"，runtimeArgs设为["run", "dev"]，前提是package.json里"scripts.dev"真的启用了--inspect
为什么 Worker Threads 或 fork() 子进程总不进断点？
不是 VSCode 不支持，而是 Node.js 默认不暴露调试端口给子进程 —— autoAttachChildProcesses: true 是开关，但没配套参数等于白开。
- 主进程必须带
--inspect-brk（不是--inspect），否则子进程启动时主进程还没跑完初始化，来不及监听子进程创建事件 - Worker 构造时必须显式传
execArgv：new Worker('./worker.js', { execArgv: ['--inspect-brk=9230'] })；fork()同理，fork('./child.js', [], { execArgv: ['--inspect-brk=9231'] }) - 端口不能复用：多个 Worker 若共用同一端口（如都写
9229），VSCode 只能连上第一个，后续连接被拒绝。建议省略端口号，让 Node 自动分配（--inspect-brk不带端口），或用环境变量动态生成 - TS/ESM 项目额外加
"env": { "NODE_OPTIONS": "--enable-source-maps" }，否则 Worker 内部的 source map 路径解析失败，断点仍不命中
attach 模式连不上 node --inspect？先查这三件事
"request": "attach" 看似简单，但失败几乎全因端口或网络层错位，和代码本身无关。
- 启动服务时必须明确指定端口：
node --inspect=9229 app.js，不能只写--inspect（会随机端口，你根本不知道连哪） -
launch.json中"port"必须和启动命令完全一致；"address"默认"localhost"，但若服务绑定了0.0.0.0或 Docker 容器内网，则需同步改成对应 IP - 检查是否有其他进程占用了该端口：
lsof -i :9229（macOS/Linux）或netstat -ano | findstr :9229（Windows），杀掉冲突进程再试 - Chrome DevTools 若已连过同一端口，会独占 WebSocket 连接，关掉所有 Chrome 标签页再重试
调试时控制台输出乱码、输入卡死？console 配置别偷懒
"console": "integratedTerminal" 是最常用选项，但它依赖终端底层行为 —— 错配会导致 stdin/stdout 失控。
- 设为
"integratedTerminal"时，确保internalConsoleOptions: "neverOpen"，否则 VSCode 可能弹出独立调试控制台抢输入焦点 - 如果脚本需要交互式输入（如
readline），"console": "integratedTerminal"是唯一可靠选择；"externalTerminal"在 Windows 上常无法捕获输入 - 遇到中文乱码（尤其 Windows），不是编码问题，而是终端未继承系统 locale —— 在
launch.json的env中补一句："env": { "NODE_ICU_DATA": "${workspaceFolder}/node_modules/full-icu" }（需提前npm install full-icu）
真正卡住人的从来不是“怎么配”，而是配完后发现断点不触发、子进程消失、或 attach 一直 pending —— 这些几乎都指向 launch.json 里某一行参数的隐式约束没被满足。多看一眼 debugger listening on ws://... 输出里的端口和路径，比反复重启 VSCode 有效得多。
