--disable-extensions 是唯一真正可靠的“纯净模式”入口，跳过整个扩展加载流程，不读配置、不执行 activate()、不启动语言服务器，适用于白屏、高 cpu、崩溃及功能失效等排查场景。

排查插件冲突或启动异常时，--disable-extensions 是唯一真正可靠的“纯净模式”入口；其他所谓“一键禁用”都是配置层面的妥协，无法绕过插件初始化逻辑。

用 --disable-extensions 启动才叫真干净

这个参数不是“禁用已启用的插件”，而是跳过整个扩展加载流程——不读 .vscode/extensions.json，不执行任何 activate()，连语言服务器都不会启动。它适用于：

• VSCode 启动卡在白屏、高 CPU 占用
• 打开特定文件（如 .log、.yaml）后立即崩溃
• 格式化/补全突然失效，且无法定位是哪个插件导致

必须注意：--disable-extensions 必须放在命令末尾，例如：

code --disable-extensions /path/to/project

若同时用了 --extensions-dir，该参数会被忽略。

extensions.disabledExtensions 配置只是软禁，不是隔离

写在 settings.json 里的这个数组，看起来像批量开关，但实际行为受限：

• 只对已安装插件生效；未安装的插件不会被“禁用”，也不会抑制推荐
• 部分插件仍会初始化（比如监听 onStartupFinished 的），只是后续功能不可用
• 某些插件（如 ms-python.python）禁用后需手动执行 Developer: Reload Window 才真正卸载语言服务器
• 数组里填错 ID（比如写成 prettier 而非 esbenp.prettier-vscode）会导致静默失败，无报错提示

工作区设置里别混用 prettier.enabled 和 eslint.enable

常见错误是想“关掉 Prettier，只留 ESLint”，于是同时设：

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

"prettier.enabled": false,<br>"eslint.enable": true

但这样并不能阻止 Prettier 插件运行——它可能仍在监听保存事件，甚至和 ESLint 规则打架。更稳妥的做法是：

• 在工作区 .vscode/settings.json 中明确指定默认 formatter："[javascript]": { "editor.defaultFormatter": "dbaeumer.vscode-eslint" }
• 确保 editor.formatOnSave 开启，且 editor.codeActionsOnSave 设为 {"source.fixAll.eslint": true}
• 删掉所有关于 prettier.enabled 的配置——Prettier 插件本身没有这个 setting，它是靠是否被选为 formatter 来决定是否介入

插件更新要手动确认，别信自动更新

VSCode 默认开启插件自动更新，这在多人协作中极易引发环境不一致：

• A 同学更新了 Volar 到 v2.5，B 同学还卡在 v2.3，defineProps 类型推导行为不同
• 某次更新悄悄改了 activationEvents，导致你写的命令在旧版里能触发，新版里直接消失

建议在全局设置中关闭自动更新：

"extensions.autoUpdate": false

然后每次更新前，先用 --disable-extensions 启动，再逐个启用、验证行为是否符合预期——尤其关注格式化输出、诊断提示、光标位置响应这三类敏感行为。

真正难的不是记命令，而是每次怀疑环境有问题时，能下意识放弃“点几下设置”的路径，直接切到终端敲 code --disable-extensions。这个动作本身，就是保持环境可控的第一道防线。