绝大多数windows开发者应设core.autocrlf为true，即提交时crlf→lf、检出时lf→crlf，确保本地编辑体验自然且仓库统一用lf；设input会导致检出不还原crlf，易使.bat/.ps1脚本执行失败。
Windows用户该设 core.autocrlf 为 true 还是 input？
绝大多数 Windows 开发者应该设成 true，不是 input。设成 input 后，Git 在提交时会把 CRLF 转成 LF，但检出时不转回来——结果是你编辑器里看到的文件全是 LF 换行，和 Windows 默认行为不一致，容易导致批处理（.bat）、PowerShell（.ps1）脚本执行失败，或某些老旧工具报“无法识别的行尾”。
-
git config --global core.autocrlf true：提交时 CRLF→LF，检出时 LF→CRLF，本地体验自然，仓库统一用 LF -
git config --global core.autocrlf input：只做单向转换，适合 WSL 或纯 Linux 工具链用户，普通 Windows 用户慎用 - 如果团队里有人用 macOS/Linux，别指望靠个人设置解决全部问题——必须配合
.gitattributes
为什么改了 core.autocrlf 还有换行符警告？
因为 Git 已经把旧文件按老规则缓存进暂存区（index）了。新配置只影响后续操作，不会自动重写已缓存的换行符状态。你看到的警告其实是 Git 在提醒：“这个文件工作区是 CRLF，但暂存区存的是 LF，我要帮你转，但先打个招呼”。
- 运行
git rm --cached -r . && git reset --hard强制刷新全部文件的暂存状态（⚠️会丢弃未提交的本地修改） - 只想修某个文件？用
git checkout -- <file></file>从暂存区重载，再git add <file></file> - 警告里提到的
core.safecrlf默认为true，它会在检测到换行符不一致时直接拒绝add；设成false可绕过检查，但只是掩盖问题
如何让 Git 完全不管某个文件的换行符？
用 .gitattributes 把它标记为 binary。Git 对 binary 文件不做任何文本处理，包括换行符转换、diff 比较、合并逻辑——这才是真正“不碰”的方式。
- 在项目根目录新建
.gitattributes，加一行：*.inf binary（假设你要保护.inf文件） - 不要写
*.inf text或留空，那反而会触发默认的 auto 推断，可能误判为文本 - 已提交过的
.inf文件需先清除缓存：git rm --cached *.inf && git add *.inf，否则规则不生效 - 注意：
binary是别名，等价于-text -diff -merge，它比单纯关掉autocrlf更彻底、更安全
.gitattributes 里 eol=lf 和 text=auto 有什么区别？
text=auto 是 Git 的自动探测机制：它读取文件内容判断是否像文本，再决定是否换行符归一化；而 eol=lf 是强制指令，只要匹配上，无论内容是什么，都按 LF 存储并检出（Windows 下检出会转成 CRLF，除非 core.autocrlf 是 false）。
- 推荐组合：
* text=auto eol=lf—— 大部分文本文件走自动识别 + 统一 LF 存储 - 对必须保留 CRLF 的文件（如
.bat），单独写：*.bat text eol=crlf - 别写
* eol=lf（没text=auto），Git 会把二进制文件也当文本处理，可能损坏图片、压缩包等 - 规则顺序重要：
.gitattributes从上到下匹配，靠后的规则可覆盖前面的
Git 的换行符问题从来不是“配对就完事”，关键在于配置、规则、缓存三者同步。最容易被忽略的是：改完 core.autocrlf 后不清理暂存区，或者写了 .gitattributes 却忘了 git rm --cached 刷新——这两步漏掉，90% 的警告和冲突都会照常出现。
