再探换行符：C/C++中'\n'的解析是否依赖执行环境？

首先明确各主流系统的原生文本换行规则：

• Windows 系统原生采用 CR+LF 双字符作为换行标记，对应 ASCII 编码的 13（\r）+10（\n）
• 类 Unix 系统（包括 Linux、现代 macOS/OS X）原生采用单个 LF 字符作为换行标记，对应 ASCII 编码的 10（\n）
• 早已停止维护的经典 Mac OS（9 及更早版本）曾采用单个 CR 字符作为换行标记，对应 ASCII 编码的 13（\r），该规则在当前所有主流 macOS 版本中已被废弃。

你的判断是对的：C 和 C++ 标准从未对'\n'的底层字节取值做强制固定，它的实际映射逻辑完全由程序的目标运行环境决定。
K&R 在《C程序设计语言》1.5.3 节行计数示例中提到“'\n'代表换行符，ASCII 编码下取值为10”，只是针对写作时普遍使用的 ASCII 编码、Unix 运行环境的具体场景说明，并非适用于所有环境的通用强制规定。

这里要区分两层核心逻辑：

• 代码抽象层：在你编写的C/C++逻辑中，'\n'永远是“换行”语义的统一抽象，你不需要为不同环境单独修改代码里的换行写法。
• 底层映射层：当你通过标准库以文本模式打开文件进行读写时，标准库实现会自动完成环境原生换行字节序列和'\n'的双向转换。举个例子，在Windows环境下，你代码里写入一个'\n'，底层实际会向磁盘写入\r\n两个字节；读取文件时，磁盘上连续的\r\n字节对也会被自动转换为单个'\n'返回给上层代码。

  如果你选择以二进制模式打开文件，上述自动转换逻辑会完全失效，程序读写的内容和磁盘存储的原始字节完全一致，这种场景下才需要手动处理不同系统的换行符差异。

一个实用的编码建议：永远不要在代码里硬编码换行符的固定字节值（比如直接写10指代换行），直接使用标准定义的'\n'即可，跨平台适配工作会由标准库自动完成，硬编码反而会导致多环境下的兼容问题。

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