简单来说，CRLF 和 LF 都是用来告诉计算机"这一行结束了，该换行了"的标记，但不同的操作系统用了不同的标记方式。为了让大家更直观地理解，我整理了一个对比表格：
核心区别对比表
| 特性 | CRLF (\r\n) |
LF (\n) |
|---|---|---|
| 全称 | Carriage Return + Line Feed (回车+换行) | Line Feed (换行) |
| 十六进制 | 0D 0A |
0A |
| 主要使用者 | Windows 系统 | Linux , macOS, Unix 系统 |
| 字节数 | 2 个字节 | 1 个字节 |
| 键盘对应 | 早期的 Enter 键逻辑 | 现代编程中的标准 |
通俗理解：
- CRLF 像是老式打字机的操作：
\r（把打印头移回行首）+\n（纸张上卷一行）。 - LF 则是现代电子化的简化：直接把光标移到下一行，不需要特意移回行首。
这种区别会影响哪些东西？
虽然对我们肉眼看起来都是"换行"，但在开发、运维和协作中，这种差异会引发不少问题：
1. Git 版本控制的混乱（最常见）
这是程序员最头疼的问题。假设你和同事在不同系统上开发同一个项目：
- 虚假的代码变更：你在 Windows 上用 CRLF，同事在 Mac 上用 LF。当你提交代码时，Git 可能会自动把 LF 转成 CRLF，或者反过来。这会导致
git diff显示整篇代码都被修改了（其实只是换行符变了），干扰代码审查。 - 合并冲突：在合并分支时，换行符的差异可能被误判为冲突，增加解决成本。
2. 脚本文件无法执行（Linux 环境）
如果你在 Windows 上写了一个 Shell 脚本（.sh）或者 Python 脚本，然后上传到 Linux 服务器运行：
- 报错：Linux 内核读取脚本时，如果发现换行符是 CRLF，它会把
\r当作命令的一部分。这通常会导致报错^M: command not found或者语法错误，导致脚本根本跑不起来。
3. 文件大小与传输
- 体积膨胀：在 Windows 使用 CRLF 时，每个换行都比 LF 多占用 1 个字节。虽然单个文件微不足道，但在超大日志文件或海量文本数据传输时，这种差异会累积，导致文件体积变大。
4. 程序读取文件的逻辑错误
如果你的程序是用二进制方式读取文件，或者按字节偏移量处理数据：
- 数据错位：程序可能会把
\r当作一个普通字符读取。比如你预期每行 10 个字符，但在 Windows 下读出来可能是 11 个（多了个\r），导致后续的数据解析全部错位。
5. 数据分析与正则匹配
- 匹配失败：在写正则表达式时，如果你只考虑了
\n，但在 Windows 文件里遇到了\r\n，多出来的\r可能会破坏你的匹配逻辑，导致提取数据失败。
如何避免这些问题？
- 统一团队规范：在项目初期，约定统一使用 LF（目前是跨平台开发的主流选择）。
- 配置 Git：
- Windows 开发者设置：
git config --global core.autocrlf true（提交时转 LF，拉取时转 CRLF）。 - Mac/Linux 开发者设置：
git config --global core.autocrlf input（提交时转 LF，拉取时不转）。
- Windows 开发者设置：
- 使用 .gitattributes 文件：在项目根目录放一个这个文件，强制规定文本文件用 LF，二进制文件不转换，这样能覆盖个人的本地设置，保证仓库里格式统一。
- 编辑器设置：现在的编辑器（如 VS Code）通常会在右下角显示当前文件的换行符格式（显示
CRLF或LF），你可以手动点击切换。