windows用户应设core.autocrlf为true，macos/linux用户设为input；设错或为空会导致git add警告、diff异常、ci失败及脚本执行错误。
Windows 用户必须设 core.autocrlf 为 true，macOS/Linux 用户必须设为 input；设错或留空会导致 Git 在 git add 时反复警告、git diff 显示整文件变更、CI 构建失败，甚至脚本执行出错。
为什么 git add 总提示 “CRLF will be replaced by LF”
这不是 Git 在“报错”，而是在告诉你：工作区文件用的是 CRLF（比如你用记事本、VS Code 或 PowerShell 编辑保存的），但 Git 暂存区里存的是 LF —— 它正准备帮你转，但先打个招呼。
- 常见诱因：刚克隆别人在 Windows 下长期开发的老项目，对方没配
.gitattributes；或你在 macOS 上粘贴了 Windows 复制的代码，编辑器自动存成 CRLF - 根本原因：Git 已把旧文件按老规则缓存进 index（暂存区）了，新配置只影响后续操作，不会自动重写已有缓存
- 后果不只是警告：如果你的
deploy.sh或Makefile被悄悄转成 CRLF，Linux 服务器执行时会报/bin/bash^M: bad interpreter
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 不会自动重处理已缓存的文件。你得手动触发一次“重新规范化”：
- 最彻底（但危险）：
git rm --cached -r . && git reset --hard⚠️ 这会丢弃所有git add过但没commit的变更，务必先git commit -m "wip" - 更安全（推荐）：只修个别文件，比如刚改坏的
deploy.sh：git add --renormalize deploy.sh它只对这个文件重走一遍换行符归一化流程，不影响其他状态
注意：core.safecrlf 默认为 true，它会在检测到混合换行符时直接拒绝 add；设成 false 只是掩盖问题，不解决根源。
光靠 core.autocrlf 还不够，必须配 .gitattributes
个人配置只能管住你自己，跨平台协作必须靠声明式规则。在项目根目录加一个 .gitattributes 文件：
* text=auto eol=lf *.bat text eol=crlf *.ps1 text eol=crlf *.sh -text
说明：
-
* text=auto eol=lf：绝大多数文本文件自动识别 + 强制按 LF 存储（Windows 检出会转 CRLF，除非core.autocrlf=false） -
*.bat text eol=crlf：批处理文件必须保留 CRLF，否则双击打不开 -
*.sh -text：标记为二进制，彻底跳过换行符处理（比关autocrlf更安全）
这个文件本身也得用 LF 保存，否则 Git 会先报它自己的换行符警告。
