先执行code --disable-extensions验证：若禁用后正常，则100%是插件在启动阶段崩溃所致；再按系统差异排查——macos查shell命令与sip，linux查沙盒权限与路径，windows查gpu/权限；跨平台崩溃优先检查native模块兼容性及engines.vscode字段。
Windows/macOS/Linux 都报 Extension host terminated unexpectedly 怎么办
这个错误不是系统特有，而是插件在启动阶段崩溃的通用信号。它不区分平台，但不同系统下触发条件不同：Windows 常因权限或 GPU 渲染冲突，macOS 多见于 Shell Command 未配置或 SIP 限制，Linux 则容易卡在 Wayland compositor 或缺少 libglib。关键不是看报错文字，而是先用 code --disable-extensions 验证——只要禁用后不崩，就说明问题出在插件层，而非系统本身。
macOS 上插件能装但不激活？检查 shell 命令和 SIP 状态
macOS 用户常遇到插件列表里显示“已启用”，但 Developer: Show Running Extensions 里看不到对应进程。这大概率是 code 命令没正确注入 PATH，导致 VSCode 启动时无法加载用户级扩展目录。先运行 which code，若无输出，去 VSCode 菜单选 Shell Command: Install 'code' command in PATH。若仍无效，检查是否启用了 SIP（System Integrity Protection）：某些老插件会尝试写入 /usr/local/bin 或读取受限路径，被 SIP 拦截后静默失败，此时需改用用户目录安装或换用签名合规的替代插件。
Linux 下 .vsix 安装失败且提示 Permission denied 怎么处理
Linux 的权限模型更严格，尤其当 VSCode 通过 snap 或 flatpak 安装时，~/.vscode/extensions/ 目录可能被沙盒隔离。执行 ls -la ~/.vscode/extensions/ 若返回 Permission denied，不要直接 sudo chown 整个目录——这会破坏 snap 包的只读约束。正确做法是：卸载 snap 版，改用 .tar.gz 官方包；或保留 snap 版，但把扩展改存到用户可写路径：export VSCODE_EXTENSIONS="$HOME/.local/share/code/extensions"，并在 settings.json 中加 "extensions.autoUpdate": false 避免后台覆盖。
插件在 Windows 正常、macOS/Linux 崩溃？重点查 native module 兼容性
很多插件底层依赖 Node.js 的 node-gyp 编译模块（比如文件监听、终端增强类），这些二进制模块不具备跨平台兼容性。现象是：同一插件在 Windows 上运行良好，在 macOS/Linux 启动即报 Error: Cannot find module './build/Release/<name>.node'</name>。此时别急着重装，先运行 Developer: Toggle Developer Tools，切到 Console 标签页，看报错是否含 .node 或 build/Release。确认后，唯一可靠解法是让插件作者发布预编译版本，或你自己用对应平台的 Node.js 和 Python 环境重新编译——但多数人应直接换用纯 JS 实现的替代插件，比如用 ESLint 替代带 native hook 的旧版 linter。
package.json 里写的 engines.vscode 字段，可能只测试过某一个平台，其他平台即使满足版本要求，也可能因系统 API 差异而挂掉。别光看绿色勾号，得真正在目标系统上跑一遍 Developer: Start Extension Bisect。
