VSCode调试Node.js后端只需内置调试器和正确launch.json配置：确保Node已安装、禁用旧配置、路径匹配、启用sourceMap；使用--inspect-brk、端口一致、避免端口冲突。
VSCode 调试 Node.js 后端应用不需要装一堆插件，核心靠内置的 node 调试器 + 正确的 launch.json 配置。只要入口文件路径对、运行模式匹配、源码映射没断，断点就能稳稳停住。
确认已启用 Node.js 调试支持
VSCode 1.70+ 默认自带 Node.js 调试器（vscode-js-debug），无需手动安装扩展。如果断点显示为空心圆或提示“未加载符号”，先检查：
-
Node.js已正确安装并可在终端中执行node -v - 工作区根目录下没有残留的旧版
.vscode/launch.json写死过时配置（比如protocol: "inspector"在新版中已弃用） - 项目未在 Docker 或 WSL 中运行却用了宿主机路径——调试器无法映射源码
用 launch.json 启动带 --inspect 的进程
直接运行 node app.js 不会开启调试端口；必须让 Node 进程启动时带上 --inspect 参数，VSCode 才能连接。推荐用以下 launch.json 配置：
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Server",
"runtimeExecutable": "node",
"runtimeArgs": ["--inspect-brk", "app.js"],
"port": 9229,
"console": "integratedTerminal",
"skipFiles": ["<node_internals>/**"]
}
]
}
关键点：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
-
--inspect-brk比--inspect更可靠：它会让进程在第一行就暂停，确保断点来得及注册 -
runtimeArgs里写app.js，不是npm start——后者需额外配npm类型调试器 -
port值必须和--inspect后指定的端口一致（默认 9229）；若改了端口（如--inspect=3001），这里也要同步改
调试 Express/Koa 等框架时注意入口和源码映射
很多后端项目用 npm start 启动，脚本里可能是 ts-node、nodemon 或 babel-node。这类情况不能直接用 node 类型调试器：
- 用
ts-node？改用type: "pwa-node"+runtimeArgs: ["-r", "ts-node/register", "src/index.ts"] - 用
nodemon？别在launch.json里调它——它会重启进程导致调试断连；改用attach模式，在终端先跑nodemon --inspect-brk app.js，再配一个request: "attach"配置连过去 - TypeScript 项目务必确认
tsconfig.json中"sourceMap": true和"outDir"设置合理，否则断点打在.ts文件上但实际运行的是.js，调试器找不到对应位置
常见断点不生效原因和快速验证法
断点变空心、控制台无 Debugger attached 提示、F5 后直接跑完——大概率是下面某个环节断了：
- 检查终端输出：成功启用调试时，第一行应有类似
Debugger listening on ws://127.0.0.1:9229/... - 打开
chrome://inspect，看能否看到本地 Node 实例；能看见说明--inspect生效，VSCode 连不上则是配置端口或路径问题 - 在
app.js最顶部加一行debugger;，运行后看是否暂停——这是绕过 UI 断点、验证调试通道是否通的最快方式 - Windows 用户注意路径分隔符：
runtimeArgs中不要混用反斜杠，一律用正斜杠/或双反斜杠\
最常被忽略的是：以为配好 launch.json 就万事大吉，却没关掉其他正在监听 9229 端口的进程（比如上次调试没杀干净的 node 实例），端口冲突会导致调试器静默失败。
