验证插件冲突需先执行code --disable-extensions，若格式化恢复则确认为插件冲突；再用Developer: Start Extension Bisect二分定位问题插件，并清理旧版插件残留目录。
code --disable-extensions 是第一验证动作
插件更新后格式化突然失效、保存变慢、代码被反复重排，别急着改配置。先终端执行 code --disable-extensions 启动 VSCode。如果这时保存正常、右下角状态栏显示预期的格式化器（如 Black 或 Prettier），说明 100% 是插件冲突，不是配置丢失或环境损坏。
顺手按 Ctrl+Shift+I 打开开发者工具，切到 Console 标签页，留意是否刷出：Command 'editor.action.formatDocument' is already registeredConflict detected for language 'python'
这类报错直接指向注册冲突源头，不是警告，是铁证。
Developer: Start Extension Bisect 自动二分定位
手动禁用太慢，尤其更新后插件面板都打不开时。按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入 Developer: Start Extension Bisect 并回车。VSCode 会自动分组启用/禁用插件，并每次问你“问题是否复现”。你只需点“是”或“否”，3–5 轮就能缩到 1–2 个嫌疑插件。
这个命令比人眼分组更可靠，因为它绕过了插件 UI 层，直击 extension host 的激活链。特别适合以下情况：
• 启动卡在“Activating Extensions…”
• 某个语言（如 .py 或 .vue）的格式化完全不触发
• Format Document With 命令列表里出现多个同类型格式化器（比如同时有 ms-python.black-formatter 和 ms-python.autopep8）
[python] 和 [javascript] 语言块配置必须显式写
很多人只在全局设置里写了 "editor.defaultFormatter": "esbenp.prettier-vscode"，结果 .js 文件格式化正常，.py 文件却还是乱跳——因为 VSCode 不会把全局设置当作语言专属默认值。它查的是语言块配置。
必须在 .vscode/settings.json 中写成：
"[python]": {
"editor.defaultFormatter": "ms-python.black-formatter",
"python.formatting.provider": "black"
},
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
注意：
• "[python]" 是固定语法，不能写成 "python" 或 "Python"
• python.formatting.provider 必须和 editor.defaultFormatter 匹配，否则 VSCode 会 fallback 到其他已注册的提供者
• 如果用了 Pylance，确保已禁用旧版 ms-python.python，否则它的语言服务器会干扰 provider 识别
更新后残留逻辑比插件本身更危险
插件更新不是覆盖安装，而是并存新旧版本目录。比如 ms-python.python-2026.4.1 更新为 ms-python.python-2026.7.0 后，旧目录仍留在 ~/.vscode/extensions/ 下。某些插件（尤其是旧版 Python、Tailwind CSS）即使被“禁用”，启动时仍会尝试加载旧版逻辑，导致 extension host 反复崩溃。
安全做法是：
• Linux/macOS：运行 rm -rf ~/.vscode/extensions/ms-python.python-*
• Windows：进 %USERPROFILE%\.vscode\extensions\，手动删掉所有带 ms-python.python- 前缀的文件夹
• 然后再重启 VSCode，不要只依赖 UI 禁用
真正麻烦的不是哪个插件没生效，而是哪个插件“看似禁用了，其实还在后台抢资源”。这点在 VSCode 1.118 升级后尤其明显——新版本对 extension activation lifecycle 更严格，旧插件残留的初始化钩子更容易触发静默失败。
