必须重载窗口才能彻底停用格式化插件——禁用仅标记状态，插件仍在内存中响应事件；重载后若仍格式化，需检查 editor.defaultformatter 或插件自身开关；vscode 1.85+ 可用 unwanteddependencies 彻底阻止加载。
想彻底停掉某个格式化插件的自动行为，光在扩展面板里点“Disable”没用——它还在内存里跑着，照样响应保存、粘贴甚至重命名事件。
禁用插件后还在格式化？必须重载窗口
VSCode 的禁用操作只是标记状态，不卸载运行实例。右键插件选了 Disable (Workspace) 或 Disable (User) 后，插件仍驻留在 Extension Host 进程中，继续监听 onSave、onDidPaste 等事件。
- 执行
Developer: Reload Window（Ctrl+Shift+P 输入后回车）才能真正卸载插件及其语言服务器 - 重载后，插件图标旁会出现灰色 “Workspace” 或 “User” 标识，表示已生效
- 若仍触发格式化，说明有其他配置兜底：比如
editor.defaultFormatter指向该插件 ID，或插件自身开关（如prettier.enable）仍为true
比禁用更彻底：用 unwantedDependencies 阻止启动
VSCode 1.85+ 支持 unwantedDependencies，它不是禁用，而是让插件根本不会被加载——连 activate() 函数都不会执行，适合屏蔽语言服务器类插件。
- 在工作区根目录创建或编辑
.vscode/extensions.json - 写入准确的插件 ID（如从市场 URL 提取：
esbenp.prettier-vscode），例如：{"unwantedDependencies": ["esbenp.prettier-vscode"]} - 生效需重新打开文件夹或重载窗口；该插件不会出现在“已禁用扩展”列表中，因为它压根没被激活过
- 旧版本 VSCode（
关格式化 ≠ 关插件：优先改插件自身开关
很多格式化插件提供细粒度控制开关，优先级高于 VSCode 的全局或工作区禁用逻辑，且不依赖重载。
-
prettier.enable设为false，比加到extensions.disabledExtensions更可靠 -
eslint.format.enable和eslint.autoFixOnSave必须显式关掉，否则即使禁用插件，ESLint 仍可能通过codeActionsOnSave触发修复 - Python 项目中，
python.formatting.provider设为null或删掉该行，比禁用ms-python.black-formatter更干净 - 这些开关通常在设置搜索框里可直接找到，名称带插件名前缀，不易漏配
为什么 --disable-extensions 是终极排查手段
当多个插件行为交织、配置层层覆盖时，唯一能 100% 隔离干扰的方式，就是从启动阶段跳过所有扩展加载逻辑。
-
code --disable-extensions /path/to/project（macOS/Linux）或code --disable-extensions "C:\project"（Windows） - 该参数必须放在命令末尾；若与
--extensions-dir同时使用，--disable-extensions会被忽略 - 它不读取任何扩展目录、不解析
package.json、不触发任何activationEvents，连右下角的“扩展正在激活…”提示都不会出现 - 适合诊断启动卡死、高 CPU 占用、打开特定文件崩溃等底层问题；但不能用于日常开发，因为连语法高亮和跳转都可能丢失
最常被忽略的点是：插件禁用状态和格式化触发路径是两套独立机制。你看到插件被标为“已禁用”，不代表它注册的保存钩子已被清除——重载窗口、检查 defaultFormatter、关闭插件专属开关，这三步缺一不可。
