必须用 runtimeexecutable 硬绑定 node 路径，runtimeversion 仅校验不切换；abi 不匹配需 npm rebuild --napi-build-version=9 --runtime=electron --target=34.0.0；断点失效优先确认 process.execpath 和 type="node"；remote-ssh 要求远端 vscode-server 版本与本地严格一致。
插件调试时 Node 版本错配，不是插件写错了，而是 VSCode 调试器根本没用你期望的 Node —— 必须靠 runtimeExecutable 硬绑定路径，其他配置全是摆设。
launch.json 里 runtimeVersion 不生效？它只校验，不切换
runtimeVersion 字段在 launch.json 中仅用于启动前比对提示，不会触发任何版本切换逻辑。它只对 type: "node" 生效，且依赖系统能调用 nvm exec（Windows 上基本无效）。真正起作用的只有 runtimeExecutable。验证是否生效：在调试控制台运行 console.log(process.execPath)，输出必须和 runtimeExecutable 的值完全一致，否则配置未命中。
- macOS 示例值：
"runtimeExecutable": "/Users/xxx/.nvm/versions/node/v18.20.4/bin/node" - Windows 示例值：
"runtimeExecutable": "C:\Users\xxx\.nvm\v18.20.4\node.exe" - 别用
${env:NVM_BIN}/node：Windows 下NVM_BIN常为空；Linux/macOS 下若echo $NVM_BIN无输出，调试直接失败
原生模块报 Cannot find module './build/Release/xxx.node'？ABI 不匹配
这不是路径问题，是 Node ABI 版本冲突。VSCode 1.90+ 内置 Electron 34 + Node v22.4.0（process.versions.napi === 9），而你 npm install 装的 sqlite3、bcrypt 是按系统 Node v18（napi=8）编译的。重编译必须带三参数：
npm rebuild --napi-build-version=9 --runtime=electron --target=34.0.0- 执行前先删掉插件目录下的
node_modules/.pnpm和out/，否则旧二进制仍会被加载 - 如果插件是打包后分发的（如
.vsix），需在打包前完成重编译，否则运行时仍会找错 ABI
F5 断点灰掉？ESM 配置和 V8 Inspector 协议差异才是元凶
常见于 type: "module" 项目混用 CommonJS 调试配置。断点失效往往不是代码问题，而是调试器协议层没对齐：
- 确认
launch.json中type是小写"node"（不是"pwa-node"），request是"launch"（不是"attach"） - 若项目含
"type": "module"，需加runtimeArgs: ["--loader", "ts-node/esm"]（TS）或手动跑node --experimental-specifier-resolution=node index.js验证 - Node v22 和 v18 的 V8 Inspector 协议有细微差异，断点映射失败时优先检查
process.execPath是否真为 v18，再排查 sourcemap 路径或outFiles配置
Remote-SSH 插件连不上？远端 vscode-server 版本必须和本地严格一致
Remote-SSH 不只是前端插件，它会在远端自动拉取并启动 vscode-server。这个二进制版本必须和本地 VSCode 主程序完全一致（如本地是 1.118.0，远端不能是 1.117.3 或 1.118.1）：
- 连接卡在
Starting VS Code Server时，先在远端执行rm -rf ~/.vscode-server - 重连后 VSCode 会自动下载匹配的 server，但前提是本地版本号与远端网络策略允许该版本分发
- 内网或锁版本环境建议提前下载对应
vscode-server-linux-x64.tar.gz手动部署，避免拉取失败
最易被忽略的是：所有这些配置都依赖 process.execPath 的真实性。只要它和你预期不符，后续所有 ABI、调试协议、远程通信都会连锁失效——先打这一行日志，再往下查。
