整个文件都显示被改过：换行符 CRLF 与 LF 的混乱怎么终结

2026-07-29

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

**大多数人第一反应是骂格式化器或者骂 AI 把文件重排了，这个归因通常是错的。**当你只改了一行、git diff 却告诉你 400 行全变了，最高频的成因是文件的行尾符在某个环节被整体重写——从 LF 变成 CRLF，或者反过来。行尾符是不可见字符，任何 UI 都不会主动告诉你它变了，所以你看到的是”内容一样但 git 说全改了”这种看起来不讲道理的现象。它跟缩进、引号、分号那类风格问题完全不是一回事，排查路径也不一样。

站内另外两篇处理相邻但不同的问题：格式化器互相打架讲的是多个工具对同一份代码的排版规则不一致，冲突发生在语法层；AI 参与下的 Git 冲突处理讲的是冲突已经爆出来之后怎么收拾。本篇只管字节层面的一件事：文件里的每一行到底以什么字节结尾，以及这个字节是谁改的。看完这篇，前两篇里那些”莫名其妙的整文件冲突”会少掉一大半。

一、先确定这真的是行尾符问题

不要一上来就改配置。改配置之前你需要一个确定的判定，否则你会在错误的方向上折腾一整个下午。

第一步看规模。git diff --stat 如果输出的插入行数和删除行数几乎相等，而且约等于文件总行数，这就是整文件重写的特征。风格类改动很少这么整齐。

第二步做排除性验证。git 自带一个专门忽略行尾差异的开关：

git diff --stat
git diff --ignore-cr-at-eol -- path/to/file

如果加上 --ignore-cr-at-eol 之后 diff 变成空的，判定就结束了：内容没变，变的只有行尾。这条命令只忽略行末的回车符，不会掩盖真实的代码改动，所以它的结论是可信的。

第三步看 git 眼里的实际状态：

git ls-files --eol -- path/to/file
git check-attr -a -- path/to/file
git config --show-origin --get core.autocrlf

git ls-files --eol 会打印类似 i/lf w/crlf attr/text=auto 的结果，i/ 是仓库索引里存的形式，w/ 是你工作区里现在的形式。两者不一致本身不一定有问题（这正是自动转换在起作用），但配合后面两条命令，你能看出这个转换是谁配置的、有没有失控。--show-origin 会告诉你 core.autocrlf 是从系统级、用户级还是仓库级配置文件里读出来的，这一点很关键，因为大部分人只查了仓库级。

想要更原始的证据，直接数字节：

python -c "d=open('src/app.py','rb').read();crlf=d.count(b'\r\n');print('CRLF',crlf,'LF',d.count(b'\n')-crlf,'CR',d.count(b'\r')-crlf)"

三个数字里有两个非零，说明这个文件本身就是混合行尾——同一个文件里既有 CRLF 又有 LF。这种文件最难缠，因为任何工具重新保存它都会产生大面积改动。

顺便说清楚”diff 全绿”。有两种情况会让你在评审界面里只看到绿色：一种是界面默认折叠了纯空白差异，删除侧被吃掉，只剩新增侧显示出来；另一种更彻底，这个文件在 git 眼里根本就是个新文件——路径大小写变了，或者被某个工具先删后建，重命名检测没有命中。第二种和行尾问题经常同时出现，因为会把整个文件重写一遍的工具，往往也顺手统一了行尾。判断方法很直接：git log --follow -- path/to/file 追不到这个路径之前的历史，就是第二种。注意 --follow 必须跟且只跟一个路径，不给路径 git 会直接报错退出。

二、一张表把现象和成因对上

现象	大概率成因	怎么验证	处置动作
只改一行，diff 显示全文件增删行数相等	保存时行尾被整体转换	`git diff --ignore-cr-at-eol` 结果为空	按第四节用 .gitattributes 收口后 renormalize
拉取代码后工作区立刻变脏，没动过任何文件	`core.autocrlf` 与仓库内已存的行尾形式冲突	`git ls-files --eol` 看 i/ 与 w/ 是否与配置预期一致	统一配置，删除个人级的历史遗留设置
同一文件里部分行变、部分行不变	混合行尾文件被局部编辑	用 python 数 CRLF/LF，两者都非零	单独对该文件做一次全量规范化并单独提交
脚本在 Linux 上报 bad interpreter 且路径带奇怪符号	shebang 行尾是 CRLF	`file deploy.sh` 输出含 CRLF line terminators	该类文件强制 eol=lf，见第四节
环境变量值比对总是失败，肉眼看完全一样	配置文件行尾是 CRLF，值末尾多了一个回车符	打印时看长度，或用 python 数字节	配置文件按 LF 存，读取侧顺手 strip
文件首行显示异常，或首个键名读不出来	编码 BOM 问题，不是行尾问题	检查文件前三个字节	转到文件编码与 BOM 的处理
diff 全绿且历史追不到	文件被先删后建，重命名检测未命中	`git log --follow -- 该文件` 只剩最近一次提交	恢复原路径大小写，重做改动

这张表的用法是从左往右走，不要跳过验证列。行尾问题最容易的误判就是把编码问题、权限位变更（文件模式从 644 变 755 也会让 git 报文件变更）都算在它头上。

三、行尾是在哪一环被改的

定位到成因之后，你要找到具体是哪个环节动的手。按我处理这类问题的经验，改写点就四个，逐个排查很快。

git 自身的自动转换。core.autocrlf 有三种取值：一种是双向都转，签出到工作区时转成 CRLF、提交进索引时再转回 LF；一种是单向转，只在提交时把 CRLF 折成 LF，签出时原样给你；还有一种是彻底关闭，两头都不动。取值名称和默认值在不同平台的安装包里可能不同，别凭记忆写进文档，用下面的命令当场读出来才作数。麻烦在于它可以配在系统级、用户级、仓库级三个地方，团队里每个人的取值可能都不一样。同一个仓库，A 的机器提交时转 LF，B 的机器不转，仓库里就会同时存在两种形式的文件。用 --show-origin 把三层都查一遍，比猜快得多。

**编辑器和 IDE 的保存行为。**编辑器通常会记住”这个文件原来是什么行尾”并保持不变，但一旦你新建文件、或者用了某个批量替换功能，它就按默认值写。默认值又跟操作系统走。这是跨平台团队里最隐蔽的一个源头，因为它只在新文件上发作。

**AI 编码工具的整文件写回。**这一点在现在的工作流里权重越来越高。很多工具在改动代码时不是做行级补丁，而是把整份文件读进去、改完再整体写出来。写出来的时候用的是运行时的默认行尾，不是原文件的行尾。你只让它改一个函数，它却顺带把全文的行尾统一了，diff 自然爆炸。这属于改动范围失控的一种典型表现，更系统的控制方法在 AI 改动范围失控怎么收敛里讲得更细。判断方法：把那次改动单独 git stash，看剩下的差异还在不在。

**CI 与容器环境。**流水线里的 sed、模板渲染、以及跨系统的目录挂载都可能改写行尾。Windows 上创建的脚本挂进 Linux 容器执行，是 bad interpreter 报错的经典来源。这类问题的特征是本地一切正常、只有流水线上炸，所以你会在本地怎么试都复现不了。

四、终结方案：把 .gitattributes 立为唯一事实源

core.autocrlf 是每个人机器上的个人配置，它天然无法统一。真正能收口的是仓库里的 .gitattributes，因为它跟着代码走，对所有人生效，优先级也高于个人配置。这是唯一值得投入的方向。

在仓库根目录建 .gitattributes：

* text=auto eol=lf

*.sh    text eol=lf
*.bash  text eol=lf
*.bat   text eol=crlf
*.cmd   text eol=crlf
*.ps1   text eol=crlf

*.png   binary
*.jpg   binary
*.pdf   binary
*.woff2 binary

三条规则的含义：第一行让 git 自己判断哪些是文本文件，文本文件在工作区一律用 LF；中间几行是必须区分对待的例外——Linux 侧执行的脚本必须是 LF，Windows 批处理和部分脚本宿主对 CRLF 更稳妥；最后几行把二进制文件明确标出来，防止 git 误判成文本后做转换，那会直接损坏文件。

写完之后，text=auto 只影响新的提交，仓库里已有的文件不会自动变。要让存量文件对齐，做一次规范化：

git add .gitattributes
git commit -m "chore: 用 gitattributes 统一行尾"

git add --renormalize .
git status
git commit -m "chore: 规范化存量文件行尾"

--renormalize 会按新规则重新处理所有已跟踪文件。关键在于它必须是一个独立提交，提交信息里写清楚这是纯行尾变更，不夹带任何逻辑改动。这样将来有人用 git log 追问题时，看到这个提交可以直接跳过；评审的人也不用逐行看几千行绿色。

再补一层保险：项目里放 .editorconfig，让编辑器在保存阶段就按对的行尾写，而不是等到提交时由 git 兜底。

root = true

[*]
end_of_line = lf
insert_final_newline = true
charset = utf-8

[*.{bat,cmd,ps1}]
end_of_line = crlf

insert_final_newline 顺手解决另一个高频噪声：文件末尾缺换行导致最后一行永远显示为一增一删。

对于单个已经坏掉的脚本，不需要动全仓库：

sed -i 's/\r$//' deploy.sh
file deploy.sh

file 的输出里如果不再出现 CRLF 相关的描述，就修好了。这条 sed 写法针对的是 GNU sed（Linux、Git Bash 里都是它）；macOS 自带的是 BSD sed，-i 后面必须紧跟一个备份后缀，而且它不把 \r 当转义符解释，照抄过去会得到一个意外的结果。跨平台的稳妥做法是不用 sed，改用一行 Python 读成二进制、把 \r\n 替换成 \n 再写回，行为在哪个系统上都一致：

python -c "p='deploy.sh';d=open(p,'rb').read();open(p,'wb').write(d.replace(b'\r\n',b'\n'))"

改完记得确认文件权限位没被顺手改掉，尤其是可执行脚本；权限位变了 git 同样会把它报成一处改动，容易和行尾问题混在一起看不清。

五、什么情况下别再折腾

全量规范化不是免费的，下面几种情况我建议你停手，选别的路。

发版窗口期内不做。--renormalize 会触碰几乎所有文件。此时任何一个尚未合并的长期分支，在合并回来时都会遇到大面积冲突。止损判断很简单：数一下当前活跃且落后主干超过一周的分支，超过三个就往后推，等它们合完再做。

**共享历史已经推送出去之后，不要用重写历史的方式来”清理”行尾。**用 filter 类工具把历史里的行尾全改一遍，技术上可行，代价是所有人的本地仓库全部作废、所有开着的评审请求全部失效。这个代价基本不可能被行尾问题的收益覆盖。做一次 --renormalize 新提交就够了，历史里的旧形式让它留着。

**回滚点要提前定好。**规范化提交之前先确认工作区干净，git status 必须是空的。做完之后如果发现哪里不对，提交前用 git reset --hard HEAD 直接丢弃，提交后用 git revert 反向提交而不是 reset。这两条路的区别以及事后状态错乱怎么处理，回滚之后状态不一致的收拾办法里有更完整的流程。

**如果只有一两个人在特定文件上踩坑，别上全仓库方案。**给那几个文件在 .gitattributes 里单独写一行规则，成本几分钟，影响面可控。全量规范化是给”团队里持续有人被咬”准备的。

**判断是否换路的依据：**你已经改了配置、清了缓存、重新克隆，问题还是复现，那多半不是行尾，回到第二节的表重新走一遍验证列。花在错误方向上的时间超过半小时就该回头，这类问题的正确路径通常十分钟内能见到确定性证据。

六、避坑清单

**把 core.autocrlf 写进新人入职文档，以为这样就统一了。**会踩是因为个人配置无法被强制，新人照做了，但他机器上还留着几年前配的用户级或系统级设置，优先级和覆盖关系一乱就失效。避法是完全不依赖它，改用 .gitattributes，并且在文档里明确写”不要设置 autocrlf”。

**规范化提交里夹带了业务改动。**会踩是因为做规范化那天顺手改了个 bug，觉得反正一起提交。后果是这个几千行的提交永远没法被跳过，出问题时二分定位直接失效。避法是规范化提交前先 git stash，提交后再取回来。

**二进制文件没标 binary，被 text=auto 误判。**会踩是因为某些文件（尤其是自定义扩展名的资源包、部分证书和字体文件）在启发式判断下会被当成文本，一转换就永久损坏，而且损坏后不报错，等到运行时才发现。避法是把项目里所有二进制扩展名都显式列进 .gitattributes，宁可多写几行。

**给需要在 Linux 上执行的脚本设了 CRLF。**会踩是因为写规则时按”这是 Windows 项目”一刀切。后果是 shebang 行末多一个回车符，系统去找一个名字带控制字符的解释器，报出的错误信息看起来像路径写错了，很误导。避法是按用途而不是按开发机操作系统分类：谁执行它，就按谁的规矩来。

**配置文件用 CRLF 存，值末尾混进回车符。**会踩是因为读取代码大多按行切分后直接用，回车符留在了值的末尾。表现是字符串比对失败、拼出来的路径不存在，但打印出来肉眼完全看不出区别。避法有两条，一是这类文件强制 LF，二是读取侧无条件做一次去空白处理，两条都做才稳。

**忽略文件里排除了 .gitattributes 或 .editorconfig。**会踩是因为有人把编辑器配置整目录忽略掉了，连带把这两个应该入库的文件也挡在外面，于是规则只在他自己机器上生效。避法是提交后用 git ls-files 确认它们确实在库里；关于哪些文件被意外挡住以及怎么定位，可以顺带看该提交的文件却提交不上去。

**只在本地验证，没验证流水线。**会踩是因为本地和 CI 的检出配置不一样，本地拿到 LF、CI 拿到别的形式。避法是在流水线里加一步廉价的检查，比如对关键脚本跑一次 file，输出里出现 CRLF 就直接失败，比等到部署阶段炸掉便宜得多。

收束

行尾符问题的难点从来不是修复，修复只要一个配置文件加一次提交；难点是它伪装成别的问题——伪装成格式化器乱改、伪装成 AI 重写文件、伪装成路径写错、伪装成配置读不到。只要你养成”整文件变更先跑一次 --ignore-cr-at-eol”的条件反射，这类问题的排查时间可以从半天压到十分钟。

留一份自检清单，下次再看到整屏绿色时按顺序过：

git diff --stat 的增删行数是否接近相等且接近文件总行数。
git diff --ignore-cr-at-eol 是否变空——空了就到此为止，是行尾问题。
git ls-files --eol 看索引与工作区的形式差异，git config --show-origin --get core.autocrlf 把三层配置都查一遍。
仓库根目录有没有 .gitattributes，里面有没有 * text=auto eol=lf，二进制扩展名列全了没有。
需要在 Linux 上执行的脚本有没有被单独锁成 LF。
如果决定做全量规范化：工作区是干净的、活跃分支不多、不在发版窗口、提交单独且不夹带业务改动。
做完之后在 CI 里加一道行尾检查，防止半年后同一个坑再来一次。