如何通过Git autocrlf配置解决跨平台换行符不一致问题？

本文共计1026个文字，预计阅读时间需要5分钟。

在Windows系统中，用户必须设置`core.autocrlf`为`true`，在macOS/Linux系统中，用户必须设置为`input`。设置错误或留空会导致`git add`重复警告、`git diff`显示文件变更、CI构建失败，甚至脚本执行出错（如`/bin/bash: bad interpreter`）。

为什么 git add 总提示 “CRLF will be replaced by LF”

这不是 Git 在报错，而是在告诉你：你工作区的文件用了 CRLF（比如 VS Code 或记事本保存的），但 Git 暂存区里存的是 LF —— 它正准备帮你转，先打个招呼。

• 根本原因是 Git 已把旧文件按老规则缓存进 index（暂存区）了，新配置只影响后续操作，不会自动重写已有缓存
• 常见诱因：刚克隆别人在 Windows 下长期开发的老项目，对方没配 .gitattributes；或你在 macOS 上粘贴了 Windows 复制的代码，编辑器自动存成 CRLF
• 后果不只是警告：如果 deploy.sh 或 Makefile 被悄悄转成 CRLF，Linux 服务器执行时会直接报错

core.autocrlf 该设 true 还是 input

别看团队、别看服务器，只看你本地操作系统。

• Windows 用户 → git config --global core.autocrlf true ✅ 提交时 CRLF → LF（仓库干净，Linux 服务器能跑） ✅ 检出时 LF → CRLF（你在 VS Code / 记事本里看着正常） ❌ 别设 input：检出不还原 CRLF，.bat 和 .ps1 脚本会执行失败
• 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。

改完配置后警告还在？怎么让已有文件“换行符归位”

Git 不会自动重处理已缓存的文件。你得手动触发一次“重新规范化”。

• 最安全（推荐）：只修个别文件，比如刚改坏的 deploy.shgit add --renormalize deploy.sh 它只对这个文件重走一遍换行符归一化流程，不影响其他状态
• 最彻底（但危险）：git rm --cached -r . && git reset --hard ⚠️ 这会丢弃所有 git add 过但没 commit 的变更，务必先 git commit -m "wip" 或确认无重要暂存

注意：core.safecrlf 默认为 true，它会在检测到混合换行符时直接拒绝 add；设成 false 只是掩盖问题，不解决根源。

为什么光靠 core.autocrlf 还不够

因为 core.autocrlf 是全局、粗粒度的开关，它无法区分 .sh（必须 LF）、.bat（必须 CRLF）、.png（禁止转换）——这些都得靠 .gitattributes 精准控制。

• .gitattributes 规则优先级高于 core.autocrlf，但很多人根本没配它
• 二进制文件（如 .png、.zip）一旦被当成文本转了换行符，就直接损坏
• 必须放在仓库根目录，且要先 git add .gitattributes 提交，否则不生效
• 典型内容示例：

  * text=auto eol=lf *.sh text eol=lf *.bat text eol=crlf *.png binary

真正跨平台稳定的项目，.gitattributes 是必选项，不是可选项；它把换行策略从“靠人记”变成“靠 Git 执行”。