vs code本身不自带node.js运行时，必须先在系统安装并确保node -v和npm -v在终端可用；若报错，需检查path配置或用nvm管理版本，再显式设置node.runtimepath；launch.json中program应填${file}或具体路径如app.js，且须指向真实js文件，esm项目还需添加"env": {"node_options": "--enable-source-maps"}。
VS Code 本身不自带 Node.js 运行时，必须先在系统中安装 Node.js，否则所有调试、插件、终端命令都会失败——这是最常被忽略的前提，不是 VS Code 配置问题，而是环境缺失。
node -v 命令报错或找不到时怎么处理
这说明 VS Code 根本没看到 Node.js，后续任何插件（包括调试器）都起不来。不要急着装插件，先解决这个底层依赖：
- 在终端直接运行
node -v和npm -v，确认系统级是否可用；如果报“command not found”，说明 Node.js 没装或没进PATH - Windows 用户检查安装时是否勾选了
Add to PATH；macOS/Linux 用户建议用nvm管理版本，避免权限和路径冲突 - 即使终端能跑，VS Code 集成终端有时会继承错误的 shell 环境，可尝试关闭再重开终端，或在 VS Code 设置里显式配置
"node.runtimePath"，值为which node输出的绝对路径（如/usr/local/bin/node）
launch.json 中 program 字段填什么才不会启动失败
VS Code 调试器靠 program 字段定位入口文件，填错就直接报 Cannot find module 或空转不执行：
- 默认生成的是
"${workspaceFolder}\index.js"（Windows）或"${workspaceFolder}/index.js"（macOS/Linux），但多数项目用的是app.js或src/index.js - 推荐写成
"${workspaceFolder}/app.js"并确保该文件真实存在；若想临时调试当前打开的文件，改用"${file}"（注意不是${fileBasename}） - 如果用了 TypeScript 或 ESM，
program必须指向编译后 JS 文件（如dist/index.js），而不是源码；否则会报ERR_REQUIRE_ESM
Node.js Extension Pack 插件到底要装哪些子项
这个合集包（@vscode/node-extension-pack）里真正影响调试体验的只有几个核心组件，其余可按需开关：
- 必装：
Debugger for Node.js（调试器本体）、ESLint（代码检查）、Prettier（格式化），三者配合才能实现保存即修复+格式化 - 可选：
JavaScript (ES6) code snippets提升编码速度，npm Intellisense补全require()路径，但对纯 ESM 项目支持弱 - 慎用：
Auto Import类插件在大型项目中容易误导入，反而干扰import排序逻辑
断点不触发或调试控制栏灰掉的常见原因
断点打了却没停，F5 按下没反应，大概率是 launch.json 的 request 类型或工作区状态不对：
-
"request": "launch"适用于本地直接运行脚本；如果项目用npm start启动（比如 Express），得改成"request": "launch"+"runtimeExecutable": "npm"+"runtimeArgs": ["start"] - 检查左下角状态栏是否显示 Node.js 版本号，没显示说明 VS Code 没识别到运行时，
Debugger for Node.js插件会静默失效 - 使用 ES modules（含
type: "module"的package.json）时，必须加"env": { "NODE_OPTIONS": "--enable-source-maps" }，否则断点映射失败
真正卡住人的从来不是插件装得多不多，而是 node 命令能不能被 VS Code 终端和调试器同时看到，以及 launch.json 里的 program 是否指向一个真实可执行的 JS 文件——这两点没对齐，后面所有功能都是空中楼阁。
