小tip：换行符CRLF 和 LF 的区别以及二者在实际项目中的影响

简单来说，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 可能会破坏你的匹配逻辑，导致提取数据失败。

如何避免这些问题？

1. 统一团队规范：在项目初期，约定统一使用 LF（目前是跨平台开发的主流选择）。
2. 配置 Git：
   • Windows 开发者设置：git config --global core.autocrlf true（提交时转 LF，拉取时转 CRLF）。
   • Mac/Linux 开发者设置：git config --global core.autocrlf input（提交时转 LF，拉取时不转）。
3. 使用 .gitattributes 文件：在项目根目录放一个这个文件，强制规定文本文件用 LF，二进制文件不转换，这样能覆盖个人的本地设置，保证仓库里格式统一。
4. 编辑器设置：现在的编辑器（如 VS Code）通常会在右下角显示当前文件的换行符格式（显示 CRLF 或 LF），你可以手动点击切换。