--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”，于是同时设：
"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。这个动作本身，就是保持环境可控的第一道防线。
