为何CR(\r)移光标至行首后，LF(\n)会被消费而非引发行重读？

要搞懂这个问题，核心是区分文本缓冲区的消费指针和屏幕显示光标——这是两个完全独立的机制，不存在绑定关系：

• 缓冲区消费指针：记录程序已经读取/处理到文本的哪个位置，是单向推进的，处理过的字符不会被回头重读，本质是跟踪文本内容的处理进度。
• 屏幕显示光标：只负责标记当前在屏幕上输出字符的位置，完全由CR/LF这类控制字符控制，和文本内容的处理进度无关。

我们以hello world\r\n为例，拆解完整逻辑：

1. 读取hello world时，消费指针从文本开头逐步移动到d的后方，同时显示光标跟着输出位置移动到d的右侧。
2. 识别到\r（回车符）：这是纯显示控制字符，作用只有一个——把显示光标移到当前行的开头。但消费指针继续向前推进到\r的后方，不会回退，所以自然不会重读前面的hello world。
3. 识别到\n（换行符）：同样是控制字符，它会把显示光标移到下一行的开头，同时消费指针继续推进到\n的后方，完成这段文本的处理。

你觉得“CR会导致重读该行”是一种错觉，实际是早期终端的特殊行为：如果CR之后紧接着输出新字符，新字符会覆盖当前行开头的原有字符，看起来像是“重读覆盖”，但本质是新内容输出到了旧的显示位置，而不是重读了缓冲区里的原有文本。比如执行echo -e "hello world\rhi"，屏幕会显示hiello world，就是因为hi被输出到了行首位置，覆盖了原有的he，但缓冲区里的hello world并没有被重读。

这种分离设计的目的很明确：让文本内容的处理（比如文件读取、网络传输）和屏幕显示逻辑解耦，文本处理只需要线性推进即可，不用关心显示位置；显示层则根据控制字符调整输出位置，各自负责各自的职责，效率更高。

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