vscode运行node.js需确保node命令在终端可用，否则所有操作失败；验证需在系统终端执行node -v和npm -v；path未生效或路径含空格/中文会导致报错；改环境变量后必须重启vscode；推荐用内置终端而非code runner执行脚本；调试时应在launch.json中显式配置runtimeexecutable以避免多版本冲突；eslint与prettier需配置协同规则。
VSCode 能直接跑 Node.js，但必须确保 node 命令在终端里能被识别，否则所有后续操作都会卡在第一步。
验证 node 和 npm 是否可用
这是整个流程的基石。很多人以为装完 Node.js 就万事大吉，结果在 VSCode 终端里输 node -v 报错“不是内部或外部命令”，本质是 PATH 没生效。
- 打开系统终端（不是 VSCode 内置终端），运行
node -v和npm -v—— 必须都能输出版本号 - 如果失败，说明安装时没勾选
Add to PATH，或手动安装路径未加入环境变量；Windows 用户尤其注意不要装在含空格或中文的路径（如C:Program Files odejs或D:软件 odejs） - VSCode 启动后会读取当前系统的 PATH，但不会自动刷新——改完环境变量后，必须完全关闭并重启 VSCode，否则内置终端仍不可用
用内置终端而非 Code Runner 运行脚本
Code Runner 插件默认用 node 执行 JS 文件，但它绕过项目上下文，不加载 package.json 中的 type 字段或 exports 配置，容易在 ES Module 场景下报错 Cannot use import statement outside a module。
- 直接用 VSCode 内置终端（
Ctrl+`）执行node index.js，行为与命令行一致，可复现真实部署环境 - 若项目用了
"type": "module"，需确保文件扩展名为.mjs或在package.json中明确声明，否则node会按 CommonJS 解析 -
Code Runner的快捷键（Ctrl+Alt+N）适合快速验证单文件逻辑，但正式开发中应禁用或仅用于非模块化脚本
调试时别漏掉 launch.json 的 runtimeExecutable
本地调试依赖 VSCode 自动调用 node，但如果系统有多个 Node.js 版本（比如通过 nvm 管理），VSCode 可能调用错版本，导致断点不触发、源码映射失败或 require 行为异常。
- 在项目根目录创建
.vscode/launch.json，配置项里显式指定runtimeExecutable，例如："runtimeExecutable": "/usr/local/bin/node"（macOS/Linux）或"runtimeExecutable": "C:\nodejs\node.exe"（Windows） - 不写这个字段时，VSCode 会按 PATH 顺序找
node，而 PATH 里的node可能和终端里看到的不是同一个 - 配合
console.log输出路径验证：console.log(process.execPath)，对比调试器里打印的路径是否与runtimeExecutable一致
插件装得越少越稳，ESLint 和 Prettier 要配好冲突规则
VSCode 自带 JavaScript 支持已足够跑 Node.js，强行装一堆“Node.js 插件”反而可能干扰语言服务，比如自动注入错误的 tsconfig.json 或覆盖 node_modules 解析逻辑。
- 真正需要的只有
ESLint（检查语法/逻辑）、Prettier（格式化）、GitLens（看提交历史）——其他如 “Node.js Extension Pack” 建议跳过 -
ESLint和Prettier默认打架：一个想加分号，一个想删分号。必须在.eslintrc.js里加"prettier"到extends，并用eslint-config-prettier关闭所有和 Prettier 冲突的规则 - VSCode 设置里关掉
editor.formatOnSave，改用保存时运行 ESLint 的eslint --fix脚本，避免格式化覆盖代码逻辑
环境变量、PATH 加载时机、调试器调用路径——这些不是“高级技巧”，而是每天都会撞上的硬门槛。多花两分钟确认 process.execPath 和终端 which node 是否一致，比事后查半小时断点失效原因更省时间。
