CRLF与LF的作用、含义及实际表现差异有哪些？

你观察到的矛盾，本质是字符原始定义和现代系统/软件的兼容处理的区别，核心差异可以从三个维度理清：

1. 原始定义来自硬件逻辑 #

LF（换行，ASCII 0x0A）和CR（回车，ASCII 0x0D）的定义最早对应老式电传打字机（TTY）的硬件操作：

• CR的作用是让打印头（carriage）回到当前行的最左端，不会滚动纸张
• LF的作用是让纸张滚动一行，打印头保持在当前水平位置不变
  要完成“换到下一行行首”的操作，必须先后发送CR+LF两个指令，缺一个都会导致打印错位。

2. 现代系统的换行约定差异 #

后来操作系统简化了换行逻辑，不同阵营做了不同的约定，这也是两者最直观的差异：

• Windows 系列沿用DOS的设计，文本文件的换行标识固定为CRLF(\r\n)两个字符
• Linux、macOS 10及以后的类Unix系统，直接把LF(\n)定义为换行标识，隐含了“回到行首”的动作
• 早期Mac OS（9及更早版本）曾单独用CR(\r)作为换行标识

3. 你看到的\n自动回到行首是兼容处理的结果 #

C语言里打印Hello\nHELLO自动跳到下一行行首，不是LF本身的定义就是如此，而是编译器、标准库、终端三层做了隐含转换：

• 类Unix系统的终端默认开启规范化模式，遇到单独的LF会自动执行“滚动一行+回到行首”两个动作
• Windows下C标准库的文本模式输出，会自动把代码里的\n替换成\r\n再输出，所以你看不到差异

要直接观察两者的区别很简单：

• 用Windows记事本打开类Unix系统生成的纯文本文件，所有内容会挤成一行，因为记事本只把CRLF识别为换行，单独的LF不会触发换行动作
• 用Linux的cat命令打开Windows生成的纯文本文件，每行末尾会多出来一个^M标识，就是多余的CR字符
• 往二进制文件里写内容时，文本模式的自动转换不会生效，直接看二进制内容就能看到LF和CRLF的字符数量差异

内容的提问来源于stack exchange，提问作者RajinCoding2007