根本原因是Node.js运行时与C++扩展的ABI或构建环境不匹配，而非VSCode本身；需用node-gyp按VSCode内置Node版本（如process.version查得）重建，并匹配平台工具链与STL/Glibc版本。
Node加载C++扩展报“Cannot find module”或“undefined symbol”
根本原因不是VSCode本身，而是Node.js运行时无法定位或兼容你编译的.node文件。VSCode只是宿主，真正执行的是它内置的Node.js（版本通常固定，如18.x或20.x），和你系统里node -v看到的可能不同。
常见现象包括：Error: Cannot find module './binding.node'、Symbol not found: _ZNSt... (macOS)、undefined symbol: __cxa_throw (Linux)。这些都不是路径写错那么简单，而是ABI或构建环境不匹配。
- 确认你的C++扩展是用
node-gyp构建的，且构建命令明确指定了目标Node版本：node-gyp rebuild --target=18.18.2 --arch=x64 --dist-url=https://electronjs.org/headers（把18.18.2换成VSCode实际内嵌的Node版本，可在VSCode开发者工具控制台执行process.version查到） - Windows下必须用与VSCode同架构的MSVC工具链（比如VSCode是x64，就不能用MinGW或32位VC++ Build Tools）；macOS需用
clang++且禁用-stdlib=libc++以外的STL选项；Linux注意glibc版本，旧系统（如CentOS 7）跑新扩展会缺GLIBC_2.28 -
binding.gyp里别硬编码include_dirs指向系统全局路径（如/usr/include/node），改用——这是<code>node-gyp注入的真实头文件位置
VSCode调试时提示“Extension host terminated”且日志含C++模块错误
这不是插件崩溃本身，而是C++原生模块在Extension Host进程里触发了段错误或未捕获异常，导致整个插件宿主进程被系统杀死。VSCode不会给你堆栈，只报终止。
关键动作不是重装插件，而是隔离复现：
立即学习“C++免费学习笔记（深入）”；
- 在终端里手动运行：
node -e "require('./out/binding.node')"（路径按你项目结构调整），看是否直接崩溃并输出Segmentation fault或Illegal instruction - 如果崩溃，用
lldb（macOS/Linux）或WinDbg（Windows）附加到该node进程，run后bt看卡在哪行C++代码——大概率是Napi::String::New传了空指针，或GetArrayBufferViewData没判null - VSCode里禁用所有其他插件，只留你的扩展，再开一个最小工作区（单个
.ts文件+package.json），排除其他插件干扰
“Error: Module did not self-register”或“Invalid access to memory location”
这是Node原生模块注册阶段失败，90%是因为模块导出函数签名不对，或跨线程调用违反N-API约束。
- 检查
Init函数是否严格按N-API规范定义：NAPI_MODULE_INIT(/*...*/) { return Init(env, exports); }，不能漏掉return，也不能在Init里调用uv_thread_create之类异步操作 - Windows上尤其注意：若用了
std::thread或std::async，必须链接/MD（动态CRT），不能用/MT（静态CRT）——否则多个CRT实例冲突，malloc/free混用直接崩 - macOS启用
node-gyp configure --enable-static-libraries=false，避免libstdc++.a静态链接引发符号重复定义
c_cpp_properties.json配置对Node+C++开发没用，但容易误导人
c_cpp_properties.json只影响VSCode的IntelliSense和语法高亮，**完全不参与Node运行时加载.node文件的过程**。很多人花几小时调这个文件，结果跟报错毫无关系。
真正要盯住的只有三处：
-
package.json里的"main"字段是否指向正确的JS入口（比如./index.js），且该文件里require('./binding')路径是否和node-gyp rebuild生成的.node文件名、位置一致 -
process.arch和process.platform是否匹配构建目标（比如你在arm64 Mac上构建却试图在x64 VSCode里加载） - VSCode启动时是否设置了
env.NODE_OPTIONS=--no-warnings之类参数，掩盖了真实的ABI警告——去掉它，让错误浮出来
复杂点不在配置，而在Node原生模块天生的脆弱性：一次std::string移动构造、一个未检查的Napi::TypedArray边界、甚至VSCode升级带来的Node版本小版本跳变，都可能让之前好好的模块突然挂掉。别信“一次编译，到处运行”。
