IndentationError常因混用TAB和空格导致，虽显示对齐但字节不同；应开启空白字符显示、禁用自动检测、统一设为4空格缩进，并用.editorconfig与pre-commit钩子从源头防控。
为什么IndentationError总在看似“对齐”的地方报错
Python 把缩进当语法，不是风格。报错时提示 IndentationError: unindent does not match any outer indentation level，往往不是因为你“少缩进”，而是混用了 TAB 和空格——编辑器显示对齐，实际字符不同。Python 解释器逐字节解析，\t 和四个 完全不等价。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 在编辑器中开启“显示空白字符”（VS Code：Ctrl+Shift+P → “Toggle Render Whitespace”；PyCharm：File → Settings → Editor → General → Appearance → ✔ Show whitespaces）
- 用
python -m tabnanny your_script.py扫描整个文件，它会明确指出哪一行混用了 Tab - 别依赖“自动转空格”开关的默认行为——有些编辑器只对新键入生效，已有 Tab 不变
如何让所有 Python 文件强制使用 4 空格且禁用 Tab
关键不在“换掉已有 Tab”，而在切断后续污染源。不同编辑器配置路径不同，但目标一致：插入缩进时输出 4 个空格，且不响应 Tab 键的缩进逻辑。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- VS Code：在工作区或用户设置中添加
"editor.insertSpaces": true、"editor.tabSize": 4、"editor.detectIndentation": false（⚠️ 必须关掉自动检测，否则打开旧文件仍沿用原缩进） - PyCharm：Settings → Editor → Code Style → Python → Tabs and Indents → ✔ Use tab character 去勾选；Tab size / Indent → 设为 4；Smart tabs → 取消勾选
- 终端下快速修复单个文件：
sed -i 's/\t/ /g' script.py（Linux/macOS），但仅作临时补救，不解决根源
flake8 和 black 对缩进的处理差异
两者都默认要求 4 空格，但角色完全不同：flake8 是检查器，只报错不修改；black 是重写器，会直接覆盖缩进格式。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
flake8 --select=E111,E114,E115,E116 your_file.py聚焦缩进类错误（E11x 系列），避免被其他 lint 信息干扰 - 运行
black your_file.py后，缩进会被重写为纯空格，但注意：它也会改行宽、括号换行等——若团队未统一用black，慎用于共享代码 - CI 中建议组合使用：
flake8卡住 PR，black --check确保格式一致，二者互补
从 Git 提交历史里揪出缩进污染源头
如果某次合并后突然大面积报 IndentationError，大概率是有人提交了含 Tab 的文件。Git 本身不区分空格和 Tab，但可以靠 diff 工具暴露。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
git show --whitespace=fix HEAD~1:your_file.py | head -20查看上一版是否含 Tab（输出中若出现^I即 Tab 字符） - 配置 Git 显示空白：
git config --global core.whitespace trailing-space,space-before-tab,tab-in-indent，再执行git diff时，Tab 行首会标红警告 - 团队应把
.editorconfig加入仓库根目录，内容包含indent_style = space和indent_size = 4——主流编辑器会自动读取，比口头约定可靠得多
最麻烦的情况不是不会修，而是修完又冒出来：某个协作者的编辑器没关 Tab，或者从网页复制了一段代码带上了不可见的缩进字符。与其反复救火，不如把 .editorconfig + pre-commit hook（调用 black --check）设成硬门槛。
