如果 VS Code 中的某项项目任务突然失败（如格式化、代码检查/linting、调试或文件导航），请使用“扩展二分法”（Extension Bisect）来缩小范围，找出是哪个已启用的扩展引起的。在 Mac 上，使用 ⇧⌘P 打开命令面板，运行 帮助: 启动扩展二分查找 (Help: Start Extension Bisect)，并在每次更改后重复相同的任务。如果问题仍然存在，请选择 This is bad；如果问题消失，请选择 Good now。VS Code 会测试扩展分组，并根据这些回答缩小搜索范围。VS Code 扩展二分查找指南

在测试前复现相同的故障

首先记录下能够可靠触发该问题的最短步骤序列：例如，打开某个特定文件，保存它，然后检查是否执行了代码格式化。记录下你的预期结果以及实际发生的情况。在每一轮二分查找期间，保持相同的项目、文件和操作步骤。这能为每个回答提供一致的判断基础；如果症状是断断续续出现的，或者你中途改变了任务操作，测试结果可能就无法可靠地确定根本原因。

检查该现象是仅限于单个工作区，还是在多个工作区中都会发生。扩展可以在全局禁用，也可以仅针对当前工作区禁用，因此特定于某个项目的故障可以在工作区范围内进行测试并在日后加以解决。“扩展”视图可以通过 ⇧⌘X 打开。VS Code 针对工作区和全局扩展控制的官方文档。

从命令面板运行扩展二分查找

在 macOS 上，按 ⇧⌘P，输入 Help: Start Extension Bisect（帮助: 启动扩展二分查找），然后选择该命令。VS Code 会禁用部分扩展组，并提示你判断问题是否仍然存在。在选择 This is bad 或 Good now 之前，请执行你事先记录的复现步骤。二分查找会利用这些反馈来选择下一组扩展；请始终基于相同的症状进行回答，直到 VS Code 找出有问题的扩展，或者在未发现问题扩展的情况下结束。官方指南详细解释了分组排查的过程。

当启用了大量扩展时，通过折半排查来缩小搜索范围，所需的检查次数远少于逐个禁用它们。这一过程依赖于准确的反馈：在问题依然存在时误报“Good now”，或者在问题停止时误选“This is bad”，都会误导排查方向。二分查找指南中还提到，排查会先从检查在禁用扩展的情况下问题是否依旧存在开始，因为原因可能出在 VS Code 本身。

在更改配置之前确认结果

当 VS Code 确定了候选扩展后，请分别在该扩展启用和禁用的状态下重复原始任务。在“扩展”视图中找到该扩展，选择其齿轮图标菜单，然后选择相应的禁用选项。VS Code 可能会提示重启扩展宿主（extension host）；确认该提示后，再次尝试复现问题。重新启用该扩展并再次检查。如果启用时该症状必定复现，而禁用时消失，你就有更有力的证据证明该扩展与问题相关。禁用操作是可逆的；诊断问题时无需卸载扩展。VS Code 针对禁用和启用扩展的文档。

某个扩展涉及其中，并不意味着它是唯一的诱因。它的设置、依赖项或与另一个扩展的相互作用可能都是关键。请阅读其在应用市场的详细信息和 README 文件，查看其提供的配置项和依赖项，然后检查最近的更新或配置更改是否与工作流发生变化的时间吻合。如果你需要保留该扩展，尽量仅针对受影响的工作区将其禁用；否则，保持其启用状态，并将可复现的步骤和扩展 ID 报告给其发布者。

如果二分查找未找到可疑扩展

尝试进行一次干净的环境对比。VS Code 配置文件（Profiles）可以隔离扩展和设置：从配置文件编辑器中创建一个 空配置文件 (Empty Profile)，用它打开受影响的项目，然后重复该任务。空配置文件会禁用扩展和修改过的设置，因此如果故障仍然存在，原因可能是 VS Code 核心程序、项目工具链或环境的其他部分。如果故障消失，则说明与扩展或自定义设置有关，但仅靠空配置文件本身无法证明具体是哪一个。VS Code 配置文件文档。

当终端位于项目目录中时，你还可以通过终端运行 code --disable-extensions . 来启动一个诊断窗口。在 Mac 上，终端的默认 Shell 是 zsh；该命令不包含需要特殊转义的 Shell 元字符。这会在本次启动中禁用所有扩展，非常适合用于快速对比。该方法不会定位到具体某个扩展；要定位具体扩展，请使用二分查找或工作区级别的禁用控制。你的 Shell PATH 中必须能够调用 code 命令。VS Code 针对此启动选项的文档；Apple 针对终端默认 Shell 的文档。

当禁用扩展后项目的故障表现依然相同时，请检查项目自身的脚本和工具、VS Code 设置，以及该问题是否在其他编辑器或环境中也会发生。将这些作为下一步的诊断线索，而不是某个特定组件存在问题的定论。

来源