1. 为什么缩进风格总在 vi/vim 里翻车
如果你维护过多人协作的仓库，大概率遇到过这种场景：本地跑得好好的 Python 脚本，提交后 CI 报TabError: inconsistent use of tabs and spaces in indentation；或者改一个 Makefile，明明逻辑没动，make却突然报missing separator。这两类问题的根子都是同一个——tab 和空格混用。
tab 在编辑器里显示成几个字符宽，取决于tabstop；但它实际只占一个字节\t。空格则是实打实的多个0x20。当一份文件里既有 tab 又有空格，肉眼看着对齐，解析器看到的却是两套缩进体系。Python 3 直接拒绝混用，Makefile 则强制要求命令行前必须是真正的 tab，一旦被转成空格就彻底失效。
vi/vim 作为 Linux 下最常打交道的编辑器，处理这件事其实很干净：靠.vimrc里的几个选项定义「tab 怎么显示、按 tab 键插入什么」，再用:retab做批量转换。这篇就把expandtab、tabstop、shiftwidth、softtabstop这套配置讲透，并给出用:set list和cat -A验证结果的具体动作，让你改完能立刻确认到底转没转成功。
适合谁看：需要统一团队缩进风格的开发者、经常在 Python 和 Makefile 之间切换的人、以及被TabError折腾过想彻底搞明白的运维和测试同学。
2. 先把 TaoToken 的接入准备做掉
配置本身不依赖任何外部服务，但如果你想让 AI 帮你批量审查仓库里的缩进问题、或者生成.vimrc模板，可以先把 TaoToken 的调用环境准备好。它的 API 地址是https://taotoken.net/api，官网在https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=。
拿 Key 的入口在控制台的 API Keys 页面，直接访问https://taotoken.net/console/api-keys就能创建。创建后建议先别急着写代码，用模型对话页https://taotoken.net/models发一条测试消息，确认 Key 和网络都通，再进入下面的配置环节。这样排障时能快速区分是「Key 问题」还是「vim 配置问题」。
注意：
.vimrc的缩进配置和 API Key 是两件独立的事。Key 只在你需要 AI 辅助分析时才用得上，纯本地转换不需要联网。
3. 可复制的 .vimrc 配置骨架
先给一份能直接抄的配置。在用户主目录创建或编辑~/.vimrc：
" 基础缩进：tab 显示宽度 set tabstop=4 " 按 tab 键时插入的空格数（配合 expandtab） set softtabstop=4 " 自动缩进时每级缩进的宽度 set shiftwidth=4 " 把 tab 展开成空格 set expandtab " 让退格键能一次删掉 softtabstop 个空格 set smarttab " 显示不可见字符，方便验证 set list set listchars=tab:>-,trail:.,extends:>四个选项的分工要理清，否则很容易配出「看着对、实际错」的状态：
| 选项 | 作用 | 常见取值 |
|---|---|---|
tabstop(ts) | 一个真实\t在屏幕上显示多宽 | 4 或 8 |
softtabstop(sts) | 插入模式下按 Tab 键，插入几个空格 | 与 ts 一致 |
shiftwidth(sw) | >>、<<、自动缩进时移动的列数 | 与 ts 一致 |
expandtab(et) | 是否把 tab 转成空格 | 开/关 |
关键点：expandtab只影响新输入的内容。已经存在的 tab 不会因为你设了expandtab就自动变空格，必须用:retab手动转换。这也是很多人配完发现「没生效」的真正原因。
如果你希望 Python 用空格、Makefile 保留 tab，可以在.vimrc里按文件类型区分：
autocmd FileType python setlocal expandtab tabstop=4 shiftwidth=4 autocmd FileType make setlocal noexpandtab tabstop=8setlocal保证只对当前缓冲区生效，不会污染其他文件。
4. 空格与 tab 互转的完整操作
4.1 tab 转空格
打开目标文件后，在命令模式执行：
:set ts=4 :set expandtab :%retab!%表示整个文件，retab按当前tabstop重排缩进，!是关键——它让 vim 处理所有tab，包括非空白字符后面的 tab。不加!时，vim 只处理行首的 tab，行中间的 tab 会被保留，这在处理对齐的表格或注释时容易漏改。
4.2 空格转 tab
反向操作把空格压回 tab：
:set ts=4 :set noexpandtab :%retab!同样建议带!。执行后 vim 会把连续的 4 个空格合并成一个\t。注意这一步对 Python 有风险：如果原文件缩进是 2 空格一级，ts=4下不会合并，结果可能更乱。转换前先确认文件的缩进基数。
4.3 只转某几行
不想动整个文件时，用行号范围：
:10,50retab!表示只处理第 10 到 50 行。配合:set list边看边转，比盲改安全得多。
5. 验证转换结果：:set list 与 cat -A
改完不验证等于没改。vim 内置的:set list是最快的检查手段。开启后，tab 会显示成^I（或你listchars里定义的符号），行尾空格显示成$前的点。执行：
:set list如果配置里写了set listchars=tab:>-,trail:.，tab 会显示成>-，行尾多余空格显示成.。滚动一遍文件，看到>-就说明还有真 tab 残留，看到整齐的空格缩进才算转干净。
退出 vim 后，用cat -A做二次确认更硬核：
cat -A demo.py | head -20cat -A会把 tab 显示为^I，行尾显示$。如果输出里出现^I，说明该行还有 tab；全是空格加$结尾，就是纯空格缩进。对比转换前后：
# 转换前 cat -A demo.py | grep -c '^I' # 转换后应输出 0 cat -A demo.py | grep -c '^I'grep -c '^I'统计含 tab 的行数，转换成功的话结果应该是 0。这个方法适合写进 CI 脚本，防止有人再提交混用缩进的文件。
6. 本篇常见错排查
报错一：TabError: inconsistent use of tabs and spaces in indentationPython 3 对混用零容忍。先cat -A找出含^I的行，再用:%retab!统一。如果转换后仍报错，检查是否有行用了 2 空格、其他行用 4 空格——retab只处理 tab，不修正空格基数不一致。
报错二：Makefile 报missing separatorMakefile 的命令行必须以真 tab 开头。如果你全局设了expandtab，新写的规则会被转成空格。解决办法是用autocmd FileType make setlocal noexpandtab，或者对已有文件执行:set noexpandtab后:%retab!把空格压回 tab。
问题三：配了 expandtab 但按 Tab 还是插入 tab检查是否被其他配置覆盖。用:set expandtab?查询当前值，返回expandtab表示已开，noexpandtab表示被关了。另外确认你改的是~/.vimrc而不是/etc/vim/vimrc，后者可能被系统默认值覆盖。
问题四：retab 后代码对齐乱了多半是tabstop和文件原本的缩进宽度不匹配。转换前先用:set ts?确认，再根据文件实际缩进调整。对缩进基数不确定的文件，先备份再转。
问题五：:set list看不到 tab 标记可能是listchars没配或终端不支持。执行:set listchars?查看当前设置，补上tab:>-即可。某些精简版 vim 需要安装完整包才有该功能。
7. 让 AI 帮你批量治理缩进
单文件转换靠上面的命令就够了，但仓库里几十个文件混用缩进时，手动一个个开 vim 太慢。这时候可以让 AI 帮你写批量脚本、或者分析git diff里哪些文件引入了 tab。
需要长期做代码审查、Agent 自动化的同学，可以看下 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite。接入文档在https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite，里面有完整的请求示例。
如果你只是想快速验证某个模型能不能准确识别缩进问题，直接用模型对话页https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite贴一段代码问它就行。API Keys 管理入口还是https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite。
最后留一个我常用的检查习惯：提交前跑一遍git diff --check，它会直接标出尾随空格和 tab 混用的行，比事后修 CI 省事得多。配合.vimrc里的set list，基本能把缩进问题挡在提交之前。
