git报conflict(content)但未改同一行，八成是crlf/lf换行符不一致导致的二进制差异；需按系统设core.autocrlf（windows用true，macos/linux用input），配合.gitattributes精准控制，并重置缓存生效。
Git 报 CONFLICT (content) 但明明没改同一行
这八成是换行符惹的祸。Windows 默认用 CRLF（\r\n），Linux/macOS 用 LF（\n）。Git 在比较文件时，若两端换行符不一致，哪怕内容完全相同，也会被识别为“行内容不同”，从而触发 CONFLICT (content) ——不是逻辑冲突，是二进制层面的差异。
常见诱因：
- 团队混用操作系统，且未统一配置
core.autocrlf - 编辑器（如 VS Code、Notepad++）自动转换保存时的换行符
- 从 Windows 拉取的仓库在 macOS 上执行
git merge，或反之
core.autocrlf 应该设成什么值
这个配置决定 Git 如何处理换行符的“工作区 ↔ 暂存区”转换，必须按系统类型设，不能一刀切：
- Windows 用户：运行
git config --global core.autocrlf true（检出CRLF，提交转LF） - macOS / Linux 用户：运行
git config --global core.autocrlf input（检出不变，提交转LF） - 纯跨平台项目（含 Windows 开发者）：推荐全队统一设为
input，并配合.gitattributes精确控制
设错会导致反复冲突：比如 Windows 用户设了 false，每次 git add 都把 CRLF 原样塞进暂存区，别人拉下来立刻报冲突。
用 .gitattributes 锁死关键文件的换行符行为
core.autocrlf 是全局兜底，.gitattributes 才是精准手术刀。它能告诉 Git：“哪些文件必须用 LF，哪些允许 CRLF，哪些禁止转换”。项目根目录下建文件：
* text=auto eol=lf *.sh text eol=lf *.py text eol=lf *.md text eol=lf *.bat text eol=crlf *.ps1 text eol=crlf *.gitattributes text eol=lf *.gitignore text eol=lf
注意点：
-
text=auto让 Git 自动判断是否为文本文件；eol=lf强制检出和提交都用LF - Windows 脚本（
.bat、.ps1）必须保留CRLF，否则执行失败 - 设完后需重置缓存：
git rm --cached -r . && git add .，否则旧换行符仍留在暂存区
已发生的换行符冲突怎么快速清理
别手动删 \r。先确认是不是纯换行符问题：
- 用
git diff --no-index --word-diff=color 测试终端能否识别 <code>\r - 用
file -i <filename></filename>查看实际编码与行尾（输出含crlf或lf）
若确认是换行符导致的假冲突：
- 临时关闭换行符转换：
git -c core.autocrlf=false merge <branch></branch>，让 Git 按字节比对 - 或直接用编辑器批量转：VS Code 右下角点击
CRLF→ 选LF→ 全局保存 - 之后
git add <file></file>提交，冲突即消失
真正麻烦的不是换行符本身，而是它藏得太深——报错信息里不提 \r，git status 看不出异样，只有 git diff --cached 或 hexdump 才暴露真相。每次遇到“没动过却冲突”，先查换行符。
