VSCode终端node -v显示旧版本是因为启动时固化shell环境快照，nvm切换后主进程不刷新PATH；macOS需Quit后用code .启动，Windows需结束Code.exe进程并重启，nvm-windows用户须执行Reload Shell Environment。
VSCode 终端 node -v 显示旧版本，但系统终端是对的
这不是 PATH 没配对，而是 VSCode 启动时固化了 shell 的环境快照。nvm 切换后主进程不刷新 PATH，导致终端继承的是旧值。
- macOS：必须 Dock 右键 → Quit（不是关窗口），再从终端执行
code .启动，确保加载当前 shell 的~/.zshrc - Windows：在任务管理器中结束所有
Code.exe进程，再重启 - nvm-windows 用户：每次
nvm use后，必须在 VSCode 中执行Terminal: Reload Shell Environment（Ctrl+Shift+P） - 验证方式：在 VSCode 终端运行
which node，输出应为类似~/.nvm/versions/node/v20.18.0/bin/node
插件报 Cannot find module './build/Release/xxx.node'
这是 ABI 不兼容的典型症状，本质是原生模块编译时用的 napi_build_version 与 VSCode 内置 Node 不匹配——不是版本号差一点就行，而是 process.versions.napi 必须完全一致。
- VSCode 1.90+ 对应 Electron 34 + Node.js 22.4.0，
napi_build_version=9 - 若你系统 Node 是 v20.x（
napi=8），直接npm rebuild生成的二进制无法被加载 - 重编译必须带完整参数：
npm rebuild --napi-build-version=9 --runtime=electron --target=34.0.0 - 务必先清空插件目录下的
node_modules/.pnpm和out/，否则旧缓存会被优先加载
launch.json 里设了 runtimeExecutable 还是断点灰掉
runtimeExecutable 只控制调试会话的主进程，不影响扩展主机（Extension Host）和含原生模块的插件。断点灰掉、require() 失败，说明插件实际跑在 VSCode 内置 Electron 的 Node 上。
- 在插件输出通道或调试器控制台打印
process.version和process.versions.napi，确认真实运行时版本 - 不要试图用
runtimeExecutable“修复”插件兼容性——它管不了 Extension Host - 真正要匹配的是 VSCode 自带的 Node 版本（即
process.versions.napi），不是你which node找到的那个 - 如果插件依赖
fsevents或数据库驱动等原生模块，必须按 Electron 版本重新构建，不能只看系统 Node 版本
Code Runner 运行 JS 文件报 Unexpected token 'export'
这是模块类型错配：你写了 ES Module 语法（如 export default），但 Code Runner 默认用 node script.js 启动，Node 把它当 CommonJS 解析。
- 解法一：把文件后缀改成
.mjs，Code Runner 会自动用node --experimental-modules（Node v12+）或直接支持 ESM（v14+） - 解法二：在
package.json加"type": "module"，但所有require()调用必须改import，且不能再用__dirname - 解法三：在 CommonJS 文件中用
await import('./utils.mjs')动态加载，安全且无需改主入口类型 - 注意：
createRequire(import.meta.url)构造的require仍不能加载.mjs，只能加载.cjs或未设type: module的.js
VSCode 里“版本升级后报错”这件事，核心从来不是 Node.js 新不新，而是谁在哪个上下文里用了哪个 ABI —— 插件、调试器、终端、Code Runner 四者各自认的 Node 可能完全不同，而它们之间又不共享模块缓存或 process.versions.napi。最容易漏掉的，就是没意识到 Extension Host 根本不读 runtimeExecutable，也不理你 nvm use 了什么。
