VSCode 官方不提供插件崩溃率数据，因微软未开放 extension host 聚合崩溃指标，日志仅本地存储且默认不上传；第三方网站无稳定性统计，唯一可信依据是插件作者在 release note 中明确标注的崩溃修复。
VSCode 官方不公开插件崩溃率数据，也没有“插件市场崩溃率排行榜”——你查不到某个插件的 crash rate、fail-to-activate 次数或用户崩溃上报统计。所谓“监控崩溃率”本质是误用概念，实际能做的只有本地归因和风险预判。
为什么找不到公开的插件崩溃率
微软未开放 extension host 的聚合崩溃指标；插件崩溃日志（exthost*.log）只存在本地，且默认不上传；即使启用“遥测”，VSCode 也仅上报匿名错误类型（如 ERR_EXTENSION_HOST_TERMINATED），不绑定具体插件 ID 或版本号。
- 第三方网站（如 vscodecandothat.com）展示的“流行度”“评分”不含稳定性数据
- GitHub 上插件仓库的 Issues 里搜
Extension host terminated unexpectedly可反映问题密度，但无标准化统计口径 - 插件作者自己发布的 release note 若写 “fix startup crash on Windows” 才是唯一可信的崩溃修复信号
如何用本地日志反推高危插件
崩溃不是随机事件，它在你的机器上留下可追踪痕迹。重点看三处：
- 运行
Developer: Open Extension Host Log，搜索ERR!或Activation failed，往上翻找最近一次非空行里的插件路径，例如ms-python.python-2026.3.1/dist/extension.js - 运行
Developer: Show Running Extensions，筛出Activation Time > 1500且Status为空或Activation failed的插件 - 打开任务管理器，观察
exthost进程启动后是否立刻退出，再比对code --list-extensions输出，逐个--disable-extension验证
哪些插件类型天然更易触发崩溃
不是所有插件风险均等。以下几类在 VSCode 1.118 环境中已反复验证为高危：
-
ms-python.python：旧版会尝试 spawnpython进程，路径含空格或权限不足时静默失败，只在exthost*.log末尾留一行spawn EACCES -
bradlc.vscode-tailwindcss：v4+ 版本依赖大量文件监听，在node_modules未被files.watcherExclude排除时引发 inotify 耗尽，导致 exthost 直接退出 -
augment.augment或其他 AI 补全类插件：调用本地大模型时若内存超限（--max-old-space-size=2048不足），Node.js 报FATAL ERROR: Ineffective mark-compacts near heap limit后进程终止 -
liximomo.sftp：连接配置错误（如私钥路径错、sftp.json语法非法）会导致启动阶段阻塞并超时 kill，不报错但卡住整个 extension host 初始化流程
真正难处理的不是崩溃本身，而是某些插件崩溃时不抛异常、不写日志、不释放资源——它只是让 exthost 进程消失，然后 VSCode 自动重启，形成无限循环。这时候必须靠 code --disable-extensions 彻底切掉干扰，再用 Developer: Start Extension Bisect 二分逼近，别信 UI 界面里显示的“已禁用”。
