node -v 报错时应先确认系统级node.js安装及path配置，而非急于配置插件；需在系统终端验证node -v和npm -v，windows检查add to path选项，macos/linux推荐nvm管理，并确保vscode继承正确环境。

node -v 报错时别急着配依赖

VSCode 里装再多插件、写再全的 package.json，只要 node -v 在终端里报“command not found”，所有依赖管理都跑不起来——这不是配置问题，是环境没到位。

• 先在系统终端（不是 VSCode 集成终端）运行 node -v 和 npm -v，确认 Node.js 真的装好了
• Windows 用户检查安装时是否勾选了 Add to PATH；macOS/Linux 强烈建议用 nvm 管理版本，避免权限和路径冲突
• 即使终端能跑，VSCode 有时会继承错误 shell 环境，可尝试关闭重开集成终端，或在设置里显式填入 "node.runtimePath"（值为 which node 输出的绝对路径）

launch.json 中的 program 字段怎么填才不炸

program 字段填错，调试器直接卡在 Cannot find module 或静默退出，根本不会加载依赖——它连入口文件都找不到，更别说解析 node_modules 了。

OC SSH Tunnel Node Recovery

诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。

下载

• 默认生成的 "${workspaceFolder}/index.js" 很容易不存在，改成 "${workspaceFolder}/app.js" 并确保该文件真实存在
• 想临时调试当前打开的 JS 文件？用 "${file}"，不是 ${fileBasename}，也不是 ${relativeFile}
• TS 或 ESM 项目必须指向编译后 JS（如 dist/index.js），不能写 src/index.ts，否则会触发 ERR_REQUIRE_ESM

npm install 后模块仍标红？检查这三处

VSCode 里 import 的包名底下持续波浪线，不是插件没装，而是类型定义或路径解析没对上。

• 确认已执行 npm install（不是 npm i 缩写，某些旧版 npm 对缩写支持不稳定）
• 检查 jsconfig.json 或 tsconfig.json 是否启用了 "typeRoots" 或 "types"，尤其用了 @types/xxx 时
• ESM 项目若用 require() 加载 CommonJS 包，可能触发类型不匹配，优先改用 import，或加 "type": "module" 到 package.json

依赖更新后调试失效？重启 VSCode 的时机很关键

npm update 或 npm install xxx 完，VSCode 不会自动重载类型定义和路径索引——你看到的“未找到模块”提示，大概率是旧缓存还在。

• 修改 node_modules 后，务必重启 VSCode（不只是 Reload Window），否则 IntelliSense 和调试器仍按旧快照工作
• 如果用了 npm-check 交互式更新，更新完立刻关掉所有打开的 JS/TS 文件，再重新打开，避免编辑器持旧引用
• 大型项目中，node_modules/.vscode 目录偶尔会残留错误缓存，可手动删掉（不影响依赖本身）

依赖管理不是装完插件就一劳永逸的事。最常被跳过的其实是：确认 node 可执行、program 指向真实文件、更新后真正重启编辑器——这三个动作看着琐碎，但漏掉任何一个，后面所有操作都在给错误状态打补丁。