git diff显示整文件改动是因换行符不一致所致，需按系统设core.autocrlf：windows设true，linux/macos设input；并配置.gitattributes统一规则，执行git rm --cached -r .和git reset --hard修复。
core.autocrlf 设置错会导致分支 diff 全红
Git 在跨平台协作中把换行符当内容差异处理，core.autocrlf 配错直接让 git diff branch-a..branch-b 显示整文件变更——哪怕你只改了一行代码。这不是 bug，是 Git 按规则“诚实”地告诉你：工作区和暂存区的换行符不一致。
三个值的实际效果：
-
true：Windows 本地开发专用。提交时 CRLF → LF，检出时 LF → CRLF。但若分支历史里已有 LF 文件，首次拉取会触发全量转换警告，diff 失真 -
input：Linux/macOS 或 CI 机器首选。提交时 CRLF → LF，检出不做转换（保持 LF）。避免工作区被 Git “偷偷改”，分支对比干净 -
false：禁用所有自动转换。适合已统一用 LF 的项目，但要求所有人编辑器也设为 LF，否则协作中 CRLF 会直接入库
验证命令必须执行：git config --get core.autocrlf，输出应明确为 true、input 或 false，空值等于未生效。
.gitattributes 优先级高于 core.autocrlf
团队里有人设 true、有人设 input，靠口头约定没用。.gitattributes 放在项目根目录后，Git 会无视全局 core.autocrlf，按文件类型逐个处理。
关键配置项必须写清楚：
-
* text=auto eol=lf：默认所有文本文件入库用 LF，检出时按系统转（Windows 变 CRLF，Mac/Linux 保持 LF） -
*.sh text eol=lf：Shell 脚本强制 LF，避免^M执行失败 -
*.bat text eol=crlf：Windows 批处理必须 CRLF，否则echo报错 -
*.png binary：二进制文件加binary，禁止任何换行符处理，防止损坏
写完文件后立刻执行：git add --renormalize .，否则旧文件仍按老规则缓存，新规则不生效。
VS Code 和 WebStorm 默认会悄悄改换行符
编辑器“自动检测换行符”功能是隐形冲突源。VS Code 状态栏显示 CRLF 时，哪怕你没动内容，保存也会把 LF 改成 CRLF；WebStorm 默认按系统设置，Windows 下新建文件就是 CRLF。
必须关掉或锁定：
- VS Code：设置里搜
files.autoSave关闭自动保存，再搜files.eol设为\n（即 LF） - WebStorm：Settings → Editor → General → Line Separators → 选 Unix and macOS (\n)
- Sublime Text：View → Line Endings → 选 Unix
改完重启编辑器，再打开任意文件确认状态栏显示 LF，不是 CRLF 或 Auto。
已污染的仓库怎么救
如果已经出现大量虚假修改，git status 显示几百个“modified”，别删重 clone——那是治标不治本。
两步清干净：
- 先清除 Git 缓存：
git rm --cached -r .（注意空格和点） - 再强制重载规则：
git reset --hard
执行后所有文件会按当前 .gitattributes 规则重新归一化。如果 git status 还有变化，说明某些文件被编辑器锁死或权限问题，单独对它们执行 git add --renormalize <file></file>。
真正麻烦的不是配置本身，而是不同工具链对换行符的“各自为政”：Git 认为该转，编辑器认为该存，CI 环境又按另一套规则跑。唯一能兜底的，是 .gitattributes 里那几行明确到后缀的声明——它不猜，不妥协，只执行。
