indentationerror总在运行时报而非编辑时标红，是因为python将缩进视为语法而非风格；vscode默认不校验缩进合法性，仅靠解释器执行时发现缩进层级不匹配才报错，如“unindent does not match any outer indentation level”。
Python 缩进报错（IndentationError）几乎全是空格和制表符混用导致的，不是代码逻辑错，而是编辑器没管住输入行为。
为什么 IndentationError 总在运行时报，而不是编辑时就标红？
Python 把缩进当语法，不是风格建议。VSCode 默认不校验缩进合法性，只做基础高亮。它不会因为某行多两个空格就报错——直到 Python 解释器执行时发现：unindent does not match any outer indentation level 或 unexpected indent。
常见诱因包括：
- 从网页/文档复制代码，带隐藏
\t或全角空格 - 打开一个老文件，VSCode 自动探测出
Tab Size: 4，但你后续按 Tab 插入的是空格（insertSpaces: true），结果新旧缩进字符不一致 - 团队成员编辑器配置不同，有人开
detectIndentation，有人关，拉代码后缩进“自动变形”
如何立刻看到哪行混用了空格和制表符？
靠肉眼对齐根本不可靠。必须让 VSCode 显形：
- 按
Ctrl+Shift+8（Windows/Linux）或Cmd+Shift+8（macOS）开启空白字符渲染 - 或在设置里搜
renderWhitespace，设为"all" - 此时：空格显示为
·，制表符显示为→
看到同一缩进层级里既有 · 又有 →，就是混用铁证。尤其注意函数体、if 块、for 循环内部——这些地方最容易漏掉某一行。
怎么一劳永逸避免新文件再混用？
关键不是“修旧”，而是“防新”。必须在项目根目录建 .vscode/settings.json，写死三件事：
-
"editor.insertSpaces": true—— 按 Tab 键插入空格，不是\t -
"editor.tabSize": 4—— 每级缩进用 4 个空格（PEP 8 推荐） -
"editor.detectIndentation": false—— 关掉自动探测，否则打开含\t的 README.md 都可能污染整个工作区
别信“它自己会判断”。Python 对缩进零容忍，detectIndentation 在混合项目中是定时炸弹。
已混用的文件怎么安全转成纯空格？
别手动删、别全局替换 \t —— 容易误伤字符串或注释里的合法制表符。
正确做法是用 VSCode 内置命令：
- 全选代码（
Ctrl+A） - 按
Ctrl+Shift+P→ 输入Convert Indentation to Spaces→ 回车 - 或右下角状态栏点击当前缩进标识（如
Tab Size: 4）→ 选Convert Indentation to Spaces
这个命令只处理行首缩进，严格按当前 tabSize 值换算（比如 tabSize: 4，一个 \t 就转成 4 个 ·），不会碰行中内容。
真正容易被忽略的是：转换后 Git 会标记所有行的缩进变更。务必先提交一次快照，否则 code review 时分不清是逻辑改动还是格式修复。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
