VS Code 调试 Node.js 无需插件，核心靠内置调试器与正确 launch.json 配置；断点失效主因是未启用 --inspect/--inspect-brk，应配置 program 直接启动而非 attach npm start 进程。
VS Code 调试 Node.js 应用不依赖插件，核心靠内置的 node 调试器和正确的 launch.json 配置；绝大多数“断点不命中”“调试器连不上”问题，都出在启动方式或运行时参数上。
为什么 npm start 启动后 VS Code 断点无效
因为 npm start 默认只是执行脚本（比如 node index.js），没启用调试模式。Node.js 从 v8.0 开始要求显式传入 --inspect 或 --inspect-brk 才允许调试器接入。
- ✅ 正确做法：在
launch.json中配置"program"指向入口文件，让 VS Code 自己启动带--inspect-brk的 Node 进程 - ❌ 错误做法：手动运行
npm start，再试图用 VS Code 的 “Attach to Process” 去连——除非你在package.json的start脚本里加了--inspect，否则连不上 - ⚠️ 注意：
--inspect-brk会让进程在第一行就暂停，适合调试启动逻辑；--inspect则不会中断，适合 attach 场景
launch.json 最简可用配置长什么样
不需要复杂字段，一个能跑起来的最小配置只需三要素：type、request、program。其他如 env、args、console 全部可选。
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch index.js",
"program": "${workspaceFolder}/index.js",
"skipFiles": ["/**"]
}
]
}
-
"type": "node"是固定值，不是"pwa-node"（后者用于新版 JS 调试器，但对纯 CommonJS 项目反而容易出兼容问题） -
"program"必须是绝对路径，${workspaceFolder}是安全写法；别写成./index.js或index.js -
"skipFiles"加上能避免跳进node_modules或内部模块，提升单步体验
调试 Express/Koa 等 Web 服务时端口被占怎么办
VS Code 默认每次调试都会新开一个 Node 进程，如果上一次没彻底退出（比如 Ctrl+C 没杀干净），新进程会因端口占用崩溃，并报错 Error: listen EADDRINUSE: address already in use :::3000。
- 先查残留进程：
lsof -i :3000（macOS/Linux）或netstat -ano | findstr :3000（Windows），再用kill -9干掉 - 更稳妥的做法：在
launch.json中加"env": { "PORT": "3001" }，避开常用端口 - 如果用了
nodemon，不要在launch.json里配"runtimeExecutable": "nodemon"—— 它和 VS Code 调试协议不兼容；改用nodemon --inspect-brk+attach模式（需额外配一个attach配置）
遇到 Cannot connect to runtime process 怎么办
这个错误基本等于“VS Code 根本没找到 Node 进程的调试端口”，常见于以下情况：
- 你正在用
yarn dev或自定义脚本启动，但脚本里没加--inspect，且没在launch.json中设"request": "attach" -
launch.json里写了"port": 9229，但实际 Node 启动时用的是默认端口（9229）以外的，比如--inspect=0.0.0.0:9230 - 项目用了
ts-node或babel-node，但type还是"node"—— 此时应改用"type": "pwa-node"并确保安装了对应调试支持
真正麻烦的永远不是配置本身，而是搞不清当前 Node 进程到底有没有暴露调试端口、暴露在哪个地址和端口。先用 ps aux | grep inspect 看一眼命令行参数最实在。
