VSCode插件报“Cannot find module”是因扩展主机使用内置Node.js且隔离插件node_modules，需在插件目录安装依赖、确认package.json声明、清理pnpm缓存、重启全进程；.node文件失败多因ABI版本不匹配，须用VSCode内置Node重编译。
VSCode插件报“Cannot find module”但本地 node -v 正常
这不是你系统 Node 没装好，而是插件运行在 VSCode 扩展主机进程里，它用的是 VSCode 内置 Node.js，不是你终端里的那个。插件自身的 node_modules 必须在插件源码目录下安装，和你的业务项目完全隔离。
- 打开插件开发目录（比如
my-extension/），确认里面有没有node_modules；没有就进该目录执行npm install或pnpm install - 检查
package.json的dependencies是否列出了报错模块（如"vscode-languageclient"），漏写会导致require失败 - 如果用了
pnpm，确保没误删node_modules/.pnpm缓存目录——旧缓存可能让 TS Server 加载了错误版本的类型定义 - 改完后必须重启 VSCode 全进程（不只是 Reload Window），否则扩展主机仍跑着旧环境
require('./xxx.node') 静默失败，控制台只显示“Cannot find module”
这几乎肯定是 ABI 版本不匹配：VSCode 1.90+ 内置 Node.js 22.4.0（napi_build_version=9），而你预编译的 .node 文件大概率是用 Node.js 20.x（napi=8）构建的，VSCode 直接拒绝加载，连错误堆栈都不抛。
- 在 VSCode 开发者工具 Console 中执行
process.versions.napi，输出"9"即确认是 ABI 问题 - 别用
npm rebuild——它默认调系统 Node，生成的仍是napi=8模块；必须显式调 VSCode 自带的 Node 可执行文件来重编译 - macOS 示例命令：
~/.vscode/Code.app/Contents/Frameworks/Code Helper \(Renderer\).app/Contents/MacOS/Code Helper \(Renderer\) --type=extensionHost node /usr/bin/npm rebuild --napi-build-version=9 --runtime=electron --target=34.0.0 - 重编译后删掉插件目录下的
out/和node_modules/.pnpm，避免缓存干扰
离线安装 .vsix 后仍提示依赖缺失或启动失败
.vsix 不是 zip 解压就能用，VSCode 会校验签名和兼容性字段，尤其 1.85+ 之后更严格。常见卡点不在“装不上”，而在“装上了却跑不动”。
- 用 ZIP 工具打开 .vsix，检查根目录
extension/package.json里是否有engines.vscode，值是否匹配你当前 VSCode 版本（如"^1.90.0"） - 确认
package.json的main字段指向的入口文件真实存在，且路径大小写与磁盘一致（Windows 上容易忽略这点） - 某些语言插件（如 Python、Go）依赖额外的 LSP 服务器二进制，它们通常不打包进 .vsix，需单独下载并配置
python.defaultInterpreterPath或go.toolsGopath - 手动解压 .vsix 后放入
extensions/目录时，文件夹名必须为publishername.extensionname-version格式（如ms-python.python-2024.6.0），否则无法识别为本地扩展
插件运行时报错 code=3221225781（Windows）
这个错误码对应 Windows 的 STATUS_DLL_NOT_FOUND，本质是插件尝试加载某个 DLL 时，系统在标准路径中找不到它。不是插件代码错了，是宿主环境缺运行时。
- 先运行 PowerShell 命令：
Get-ChildItem 'C:\Windows\System32\vcruntime*.dll' | Select-Object Name, LastWriteTime，确认vcruntime140.dll等关键 VC++ 运行库存在 - 常见缺失项：
python3.dll（Python 后端插件）、cudart64_110.dll（GPU 加速）、.NET Framework 4.7.2+（部分旧插件） - 不要全局安装依赖——插件无法访问系统 PATH 中的 DLL，必须把对应 DLL 放到插件目录下，或注册到系统目录（推荐前者，避免污染）
- 若插件含
nativeDependencies字段，说明它明确声明了原生依赖，此时必须按其文档提供对应平台的二进制，不能靠“凑合能跑”
package.json，后者得查 process.versions 和 engines 字段。两者混在一起时，最容易反复试错。 
