VSCode 因扩展损坏崩溃的核心问题是 exthost 进程被插件拖垮，应先通过 Developer: Open Extension Host Log 定位 ERROR 日志中的插件 ID，再用 code --disable-extensions 验证，最后精准禁用或删除对应扩展并清理缓存。
VSCode 因扩展损坏崩溃，核心问题几乎总出在 exthost 进程被某个插件拖垮——不是“装不上”，而是“一启动就崩”，连命令面板都打不开。直接删插件或重装 VSCode 是下策；先定位、再隔离、最后清理，才是稳住编辑器的最快路径。
怎么看日志确认是哪个扩展在搞鬼
崩溃弹窗没用，真正线索藏在 exthost 日志里。别猜，立刻打开：
按 Ctrl+Shift+P（macOS 用 Cmd+Shift+P），输入并运行 Developer: Open Extension Host Log。滚动到底部，找最后一行带 ERROR 的记录，例如：
ERROR Error: Cannot read property 'onDidChangeTextDocument' of undefined
at activate (/home/user/.vscode/extensions/ms-python.python-2026.3.1/dist/extension.js:1)
重点看两处：ms-python.python 是插件 ID，extension.js 是出问题的文件——这就是你要处理的对象。
如果日志为空或根本打不开，说明崩溃发生在日志初始化之前，得退到命令行阶段排查。
用 code --disable-extensions 快速验证是否为扩展问题
这是最轻量、最可靠的判断动作：
- 终端执行
code --disable-extensions，VSCode 会以纯净模式启动，不加载任何扩展 - 如果这时秒开、界面正常、控制台无报错，那 100% 是扩展引发的崩溃
- 如果依然闪退或白屏，问题可能在
settings.json语法错误、用户数据目录损坏，或 VSCode 本体异常
注意：Windows 用户点击图标前按住 Shift 再松开，也能触发等效行为；但命令行方式更可控、可复现。
禁用或删除高危扩展的实操方式
UI 界面点来点去太慢，尤其当崩溃导致扩展面板无法加载时。优先用命令行精准操作：
- 查已装插件：
code --list-extensions - 单个禁用测试：
code --disable-extension ms-python.python（替换为你怀疑的 ID） - 多个禁用：
code --disable-extension esbenp.prettier-vscode --disable-extension dbaeumer.vscode-eslint - 彻底清除（推荐）：
Linux/macOS：rm -rf ~/.vscode/extensions/ms-python.python-*
Windows：进%USERPROFILE%\.vscode\extensions\，手动删掉对应文件夹（名称含版本号）
删完不用重启系统，直接再运行 code 即可。VSCode 启动时发现目录不存在，自然跳过加载，比“禁用”更干净。
清缓存比重装插件更关键
卸载重装后还崩？大概率旧缓存没清干净，或者配置项本身触发了底层异常：
- 删扩展缓存：
%USERPROFILE%\.vscode\extensions（Windows）或~/.vscode/extensions（macOS/Linux），清空内部所有子文件夹（保留文件夹本身） - 删下载缓存：
%USERPROFILE%\.vscode\cachedExtensions（Windows）或~/.cache/Code/CachedExtensions（Linux/macOS） - 检查异常配置：比如
sftp.json里写了非法密钥路径，或C_Cpp.default.compilerPath指向已删除的编译器 - 某些插件（尤其含 WebAssembly 或加密模块的）会卡在 Node.js 初始化阶段——运行
node -v确认是否 ≥18，建议升级到 v20.x LTS
真正容易被忽略的是：扩展崩溃常不是插件“坏了”，而是它和当前 VSCode 内嵌的 Node.js 版本不兼容，或调用了已被废弃的 API（如 vscode.workspace.rootPath）。这类问题不会报红字，只会在日志末尾静默失败。
