convert indentation to spaces错位的根本原因在于其依赖三个隐性状态：tab_size必须与文件中原始\t的视觉宽度一致、文件不能混用\t和空格、右下角必须显示spaces: 4；任一缺失都会导致缩进塌缩或撑开，而非命令本身失效。
Convert Indentation to Spaces 为什么转完缩进错位
根本原因不是命令本身坏了，而是它依赖三个隐性状态：当前 tab_size 必须和文件里原始 \t 的视觉宽度一致；文件不能混用 \t 和空格；右下角状态栏必须显示 Spaces: 4（不是 Tabs: 4）。缺一就会塌缩或撑开。
常见现象：if 块缩进突然变浅、函数体整体左移两列、注释对不齐。这不是“转换失败”，是换算逻辑按错宽度做了替换——比如原始 \t 占 4 列，但当前 tab_size 是 2，结果只替换成 2 个空格。
- 执行前务必点右下角状态栏 → 选
Indent Using Spaces→ 再设宽度（如 4） - 打开文件后先看右下角是否显示
Spaces: 4，不是就说明没生效 - 混用缩进的 Python 文件，该命令会直接灰掉，别硬点
detect_indentation 开启时老文件永远不听设置
Sublime 默认开启 detect_indentation，打开文件瞬间扫描前 200 行，只要发现一个行首 \t，就静默覆盖你的 translate_tabs_to_spaces 和 tab_size，切到 Tab 模式——你改的设置全被无视。
表现就是：全局设置了 "translate_tabs_to_spaces": true，但打开旧 .py 文件，按 Tab 还是插 \t，右下角显示 Tabs: 4。
- 必须在
Preferences → Settings – User中显式加"detect_indentation": false - 加完后已打开的文件不会自动刷新，需手动
Ctrl+Shift+P→ 输入Reload Syntax回车 - 关掉后，缩进行为才真正由你写的配置决定，而不是被文件内容反向劫持
批量处理整个目录时别信 Sublime 界面操作
菜单里的 Convert Indentation to Spaces 只作用于当前活动标签页，哪怕你 Ctrl+P 多选了 10 个文件，也只改最前面那个。所谓“批量”纯属幻觉。
真正可靠的方式只有命令行，且必须区分场景：
- 只处理行首缩进（安全）：
find src/ -name "*.py" -exec expand -t 4 {} \; -exec mv {} {}.tmp \; -exec mv {}.tmp {} \; - 替换所有
\t（危险）：python3 -c "import pathlib; [p.write_text(p.read_text().replace('\t', ' ' * 4)) for p in pathlib.Path('src').rglob('*.py')]"—— 会误伤字符串、正则、日志模板里的\t - Windows 用户可用 PowerShell：
Get-ChildItem src\ -Recurse -Include *.py | ForEach-Object { (Get-Content $_.FullName) -replace "^\t+", ' ' | Set-Content $_.FullName }
EditorConfig 或语法专属设置正在悄悄覆盖你
即使你把全局设置调得再完美，项目根目录的 .editorconfig 文件或某语言的语法专属配置仍可能劫持行为。比如 .editorconfig 里写了 indent_style = tab，EditorConfig 插件就会无视所有 Sublime 设置。
同样，Python 语言包自带硬编码："tab_size": 2 和 "translate_tabs_to_spaces": false，你的全局设置会被直接覆盖。
- 检查方法：打开目标文件 →
Preferences → Settings – Syntax Specific，看右边是否有冲突项 - 确认
.editorconfig是否启用，且indent_style和indent_size与团队规范一致 - Python 文件必须单独进
Settings – Syntax Specific，手动写入"tab_size": 4和"translate_tabs_to_spaces": true
实际批量处理前，先用 draw_white_space 开启空格可视化，一眼就能看出哪行混用了 \t 和空格——这才是排版错位最常被忽略的起点。
