Black和isort互相覆盖import格式的根本原因是VS Code默认让两者都响应formatOnSave：isort先排序并加空行，Black再重写全文件删空行、合并import，导致混乱；正确做法是将formatOnSave交由Black，仅通过source.organizeImports调用isort，并配置--profile black和fromEnvironment策略确保风格一致且本地包识别准确。
Black 和 isort 为什么会互相覆盖 import 格式
根本不是插件“不兼容”，而是 VS Code 默认让两者都响应 editor.formatOnSave，结果 isort 先排好 import、加了空行，Black 紧跟着重写整文件，把空行删了、把多行 import 合并成单行、甚至把本地模块误判为第三方——最终 import 看起来“没排序”或“格式错乱”。
关键点在于：Black 不处理 import 分组逻辑，isort 也不管代码缩进和括号换行。它们职责不同，但默认配置下被当成同一类操作反复触发。
-
editor.formatOnSave是总开关，但它不区分“只动 import”还是“重写全文件” - VS Code 的
source.organizeImports动作才是 isort 的正确入口，不是formatDocument - 如果
python.formatting.provider设为isort，它会接管整个格式化流程，反而和 Black 冲突
必须改 settings.json 的三个核心配置项
pyproject.toml 里的 [tool.isort] 配置 VS Code 根本不读（除非你手动指定 --config），所有控制权必须收归 settings.json。
-
"python.formatting.provider": "black"—— 明确把格式化主控权交给 Black，isort 只负责 import 整理 -
"isort.args": ["--profile", "black"]—— 让 isort 模拟 Black 的风格：不加空行、单行多 import、force_sort_within_sections = true -
"editor.codeActionsOnSave": { "source.organizeImports": "explicit" }—— 这是唯一能让 isort 在保存时生效的路径；设为explicit才启用 Ctrl+Shift+O 或自动触发
漏掉任意一项，isort 就不会在保存时运行，或者运行了但风格和 Black 对不上。
常见错误现象与对应修复
这些表现背后几乎都是配置错位，不是插件装错了：
- 保存后 import 完全没变化 → 检查
"source.organizeImports": "explicit"是否在"editor.codeActionsOnSave"下，且没被工作区设置覆盖 - import 排序了但本地模块（如
from mypkg.utils import foo）被塞到third_party区 → 必须设"isort.importStrategy": "fromEnvironment"，否则 isort 不会扫描当前 Python 环境识别src/或mypkg/ - 保存一次弹出两个格式化提示，或控制台报
Command 'python.sortImports' not found→ 删掉所有含python.sortImports的 keybindings.json 条目，该命令已在 VS Code 1.20+ 废弃 - 右下角状态栏显示
autopep8或空白 → 说明"[python]"块里没写"editor.defaultFormatter"，全局设置无效
为什么不能靠 pyproject.toml 自动生效
VS Code 的 ms-python.isort 扩展在启动时只检查 settings.json 和环境变量，完全忽略 pyproject.toml 中的 [tool.isort]。哪怕你写了 known_first_party = ["mypkg"]，只要没通过 "isort.importStrategy": "fromEnvironment" 让 isort 关联当前解释器，它就无法解析项目结构。
更麻烦的是：pyproject.toml 里用 --config ./pyproject.toml 传参，在 VS Code 启动子进程调用 isort 时容易路径解析失败，尤其在多工作区或远程开发场景下。直接用 --profile black 更稳定，也省去维护两套配置的麻烦。
