唯一可靠方法是终端执行 node -v，VSCode不主动检测Node版本，仅执行命令行能运行的命令；输出即当前环境实际生效版本，不受状态栏、插件或package.json中engines字段影响。
终端里执行 node -v 是唯一可靠入口
VSCode 不会主动“检测” Node 版本，它只执行你命令行里能跑通的东西。打开集成终端（Ctrl + `），直接敲 node -v，输出结果就是当前环境实际生效的版本——别信状态栏小字、别信插件提示、更别信 package.json 里的 "engines" 字段。
常见错觉：
- 终端显示 v18.19.0，但 F5 调试却跑在 v16.20.2 → 没配
launch.json的runtimeExecutable，调试器走的是系统 PATH 里的 node -
package.json写着"node": ">=20.0.0"，但node -v输出 v18.19.0 → 这字段纯属声明，不拦人、不切换、不报错 - 用了 nvm，
nvm use 20.12.0成功，但新终端里node -v还是旧版 →terminal.integrated.inheritEnv没设为true，或 shell 初始化文件（如~/.zshrc）没 sourcenvm.sh
npm audit 是查依赖漏洞的默认且最准方式
VSCode 没内置漏洞扫描器，npm audit 就是事实标准。在项目根目录终端运行它，会列出所有已知高危/中危漏洞，包括路径、修复建议和是否可自动修复。
关键实操点：
- 必须确保
node_modules和package-lock.json是当前安装状态，删了重装后要再跑一次 - 默认只检查生产依赖，加
--dev参数才能包含devDependencies中的漏洞 -
npm audit --fix能自动升级到兼容的最小修复版；npm audit --fix --force强制升到最新版（可能破坏兼容性） - 如果公司用私有 registry（如 Nexus），需提前设
npm config set registry https://your-registry.com，否则漏报
VSCode 插件只是辅助，不能替代命令行判断
像 Version Lens 或 Node.js Extension Pack 这类插件，顶多在 package.json 行尾标个“→ 4.19.2”，但它不跑 npm audit，也不读 node_modules 里的真实包结构，更不会告诉你 lodash 的某个子依赖 ansi-regex 正在被 CVE-2021-28079 影响。
插件容易误导的场景：
- 插件显示“up to date”，但
npm audit报出一个高危漏洞 → 那是因为漏洞出现在间接依赖里，插件只看直接声明的版本 - 插件缓存未刷新，刚发布的安全补丁还没同步 → 此时
npm audit已能查到，插件却还显示“no update needed” - 用了 pnpm/yarn，插件仍按 npm 逻辑解析 lockfile → 可能漏掉 workspace 或 hoisted 依赖的漏洞路径
调试时版本不对？先验证 runtimeExecutable 是否生效
F5 启动后 process.version 和终端不一致，90% 是 launch.json 配错了。别改来改去，就盯住这一行：
"runtimeExecutable": "${env:NVM_BIN}/node"
验证三步：
- 在集成终端执行
echo $NVM_BIN，必须有输出（如/Users/xxx/.nvm/versions/node/v18.19.0/bin） - 关掉所有终端、完全退出 VSCode、重开，再检查
echo $NVM_BIN—— 否则环境变量可能为空 - 在调试控制台打印
process.env.NVM_BIN，和终端输出比对，不一致说明${env:NVM_BIN}展开失败，fallback 到系统默认 node
Windows PowerShell 用户额外注意：$PROFILE 必须加载了 nvm.ps1，否则 NVM_BIN 根本不存在。
