Git 提示“CRLF will be replaced by LF”是因换行符不一致触发的自动转换警告：Windows用CRLF，Unix/Linux/macOS用LF，Git按core.autocrlf配置在提交/检出时自动转换，避免diff混乱、CI失败等问题。
为什么 Git 总提醒 “CRLF will be replaced by LF”？
这不是报错，是 Git 在“悄悄帮你修文件”——它发现你本地文件用了 Windows 风格的 \r\n（CRLF），但仓库约定用 Unix 风格的 \n（LF），于是打算在提交前自动转成 LF。警告本身不阻断操作，但会导致 diff 里全是换行符差异、合并冲突虚高、CI 构建失败（比如 shell 脚本在 Linux 上因 CRLF 报 ^M: command not found）。
常见诱因：
- 编辑器（如 VS Code、PHPStorm）默认按系统设换行符，Windows 用户装了 Linux 风格插件，或 macOS 用户误存为 CRLF
- 从 Windows 复制粘贴代码进 macOS/Linux 终端编辑的文件
- 克隆别人没配
.gitattributes的老项目，且对方长期在 Windows 下开发
该设 core.autocrlf 为 true 还是 input？
看你的操作系统，不是看团队、不是看服务器：
Windows 用户 →
git config --global core.autocrlf true
✅ 检出时把 LF 自动变 CRLF（你在记事本/VS Code 里看着正常）
✅ 提交时把 CRLF 自动变 LF（仓库干净，Linux 服务器能跑）
❌ 别设false：除非全队只用 Windows，否则等于埋雷macOS / Linux 用户 →
git config --global core.autocrlf input
✅ 提交时把 CRLF 强制转 LF（防 Windows 同事塞进来的脏文件污染仓库）
✅ 检出时不碰换行符（你本地本来就是 LF，保持原样）
❌ 别设true：Git 会试图把 LF 转 CRLF，结果你编辑器可能再转回 LF，形成无意义震荡
验证当前设置：git config --global core.autocrlf，输出必须是 true 或 input，不是空或 false。
怎么让已有文件立刻“换行符归位”？
改完 core.autocrlf 后，Git 不会自动重处理已缓存的文件。得手动触发一次“重新规范化”：
- 先清空暂存区（不删工作区文件）：
git rm --cached -r . - 再重新检出（此时 Git 按新规则转换）：
git reset --hard - 最后确认状态：
git status应该显示“working tree clean”
⚠️ 注意：这个操作会丢弃所有未 commit 的暂存变更（git add 过但没 commit 的），务必先 git commit -m "wip" 或确认无重要暂存。
如果只想修个别文件（比如刚改坏的 deploy.sh）：git add --renormalize deploy.sh 更安全。
二进制文件和脚本文件怎么区别对待？
core.autocrlf 是全局开关，对图片、zip、exe 等二进制文件也生效——这是危险的。它们不该被换行符转换，否则直接损坏。
正确做法是在项目根目录加 .gitattributes 文件，明确分类：
* text=auto *.png binary *.jpg binary *.sh text eol=lf *.py text eol=lf *.md text eol=lf
这样：
- 所有文本文件由 Git 自动判别是否需换行符处理（比
core.autocrlf更准） -
.png/.jpg被标为binary，Git 绝不碰其字节 -
.sh强制用 LF，避免在 Linux 上执行失败
别漏掉 .gitattributes 本身——它得先被 git add 进去，否则规则不生效。
最常被忽略的一点：编辑器换行符设置和 Git 配置要对齐。比如 macOS 用户设了 core.autocrlf input，但 VS Code 仍默认保存为 CRLF，那每次保存都在制造下一次警告。编辑器里搜 “end of line” 或 “line endings”，强制设成 LF 才算闭环。
