code --disable-extensions是唯一可信的排查起点，它强制跳过所有插件加载流程，不读settings.json、不扫描.extensions.json、不执行任何activate()函数，可100%确认是否为插件导致崩溃。
code --disable-extensions 是唯一可信的起点
VSCode 插件调试时进程崩溃，90% 的情况不是代码逻辑错，而是插件在 activate() 阶段就触发了 Node.js 层面异常（比如访问已销毁对象、调用废弃 API、原生模块加载失败），导致 exthost 进程直接退出。此时 UI 上点“禁用全部扩展”根本无效——配置还没读完，崩溃已经发生。
必须用命令行强制跳过所有插件加载流程：code --disable-extensions。它不读 settings.json、不扫描 .vscode/extensions.json、不执行任何插件的 activate() 函数。如果这时能正常打开并调试你的插件，说明 100% 是某个已启用插件干扰了调试环境。
- Windows/macOS/Linux 全平台有效，注意拼写是
extensions（不是extension） - macOS 若提示
command not found: code，先去 VSCode 菜单选 Shell Command → Install 'code' command in PATH - 这个命令只影响本次启动，不会改动任何配置或缓存
Developer: Open Extension Host Log 看最后一行 ERROR
日志比弹窗可靠得多。崩溃弹窗只写 “Extension host terminated unexpectedly”，但真实线索藏在 exthost*.log 末尾的 ERROR 行里。哪怕只有一行报错，也大概率指向肇事插件。
按 Ctrl+Shift+P（macOS 是 Cmd+Shift+P），输入并运行 Developer: Open Extension Host Log，滚动到底部找类似这样的记录：
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阶段 - 日志路径可直接访问：
%APPDATA%Codelogs\exthost1.log（Windows）、~/Library/Application Support/Code/logs//exthost1.log（macOS） - 搜索关键词：
Activating extension、Failed to activate extension、SIGSEGV、FATAL ERROR: Ineffective mark-compacts
code --disable-extension 精准隔离高危插件
确认是插件问题后，别全关再一个个开——组合冲突很常见（A 和 B 单独 OK，一起开就崩）。用 --disable-extension 参数逐个排除最直接，尤其适合连插件面板都打不开的情况。
先查已装插件：code --list-extensions，然后优先试这些高危类型：
-
ms-python.python（启动早、依赖多、常因 Python 解释器路径或权限失败） -
esbenp.prettier-vscode（格式化钩子易与语言服务器竞争） -
bradlc.vscode-tailwindcss（CSS 类名扫描耗内存，Node.js 版本低时易崩） -
rust-lang.rust-analyzer或ms-python.pylance（LSP 客户端，对磁盘 I/O 和内存敏感）
测试命令示例：
code --disable-extension ms-python.python
若还不行，可一次禁用多个：
code --disable-extension esbenp.prettier-vscode --disable-extension dbaeumer.vscode-eslint
注意：--disable-extension 只对本次启动生效，不影响插件文件本身；禁用后仍需重启 VSCode 才能验证效果。
删插件目录比禁用更彻底
某些插件（尤其是旧版 Python、SFTP、AI 补全类）即使被“禁用”，也会在启动时尝试 spawn 外部进程。如果路径含空格、中文或权限不足，会静默失败——UI 不报错，日志也不留痕迹，只在 exthost 日志末尾出现一行模糊的 spawn ENOENT 或 Permission denied。
这时禁用只是假象，必须物理删除对应目录：
- Linux/macOS：
rm -rf ~/.vscode/extensions/ms-python.python-*（通配符匹配版本号） - Windows：进
%USERPROFILE%.vscodeextensions，手动删掉名称含ms-python.python-的整个文件夹 - 删完不用重启系统，直接再运行
code即可——VSCode 启动时发现目录不存在，自然跳过加载
真正麻烦的不是插件多，而是某些插件会在启动早期劫持主进程入口（比如 patch main.js 或改 argv.json），这类行为不会在设置里体现，也不会弹提示，只会在日志里静默失败。每次 VSCode 升级后，如果某个老插件突然不工作，优先查它的 package.json 里 "engines": {"vscode": ""} 是否锁死了旧版本。
