最直接的判断方式是执行 code --disable-extensions 启动 VSCode，若资源管理器秒出则问题 100% 出在插件上；否则需排查工作区路径或 VSCode 状态损坏。
用 code --disable-extensions 快速验证是不是插件导致的
这是最直接的判断方式。终端执行 code --disable-extensions 启动 VSCode，不加载任何第三方扩展（但保留 TypeScript、JSON 等内置支持）。如果资源管理器秒出、文件树不再卡在“正在加载…”或空白，那问题 100% 出在插件上。
注意：code --disable-extensions 不等于重装或清理配置，它只是临时绕过所有扩展加载流程。如果这步仍卡顿，问题大概率在工作区路径本身（比如挂载点失效、权限异常）或 VSCode 自身状态损坏（可后续试 code --clean）。
用 Developer: Start Extension Bisect 二分定位具体插件
手动禁用插件效率低，尤其当你装了 50+ 个时。VSCode 内置的二分排查命令才是真解法：按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（macOS），输入并运行 Developer: Start Extension Bisect。
- 它会自动把插件分成两组，禁用其中一组，重启后让你测试是否复现卡顿
- 你只需回答“是”或“否”，3–4 轮就能缩到单个插件
- 特别适合 GitLens、Path Intellisense、Auto Rename Tag 这类常驻监听文件系统的插件——它们不动声色就把 inotify 句柄占满
看 Developer: Show Running Extensions 里 Activation Time 超长的插件
有些插件没报错，也不崩溃，就是卡在激活阶段不动，拖慢整个启动链。运行 Developer: Show Running Extensions，重点关注两列：
-
Activation Time (ms)：超过 1000 毫秒的插件高度可疑，尤其是 rust-analyzer、volar、Pylance 这类语言服务器 -
Status：显示Activation failed或为空白，说明它根本没正常加载，却可能残留监听器持续消耗 CPU
这类插件往往不会出现在控制台错误里，光看 Developer: Toggle Developer Tools 的 Console 标签页容易漏掉。
检查插件是否触发额外文件扫描（比如 python.defaultInterpreterPath）
某些语言扩展会在初始化时主动扫描路径，不是监听文件变化，而是读取元数据。例如 Pylance 会根据 python.defaultInterpreterPath 去解析虚拟环境目录结构；如果该路径指向一个损坏、权限不足或已卸载的 venv，资源管理器就会卡住不动。
实操建议：
- 打开设置，搜
python.defaultInterpreterPath，确认值是否真实存在且可读 - 同理检查
rust-analyzer.serverPath、typescript.preferences.includePackageJsonAutoImports等可能触发扫描的配置项 - 临时删掉这些路径配置，看文件树是否恢复——再逐个加回来验证
真正难缠的不是报错的插件，而是那种静默卡在中间、不释放控制权、也不抛异常的插件。它会让所有后续插件排队等它，而你只看到“正在加载…”一直转。
