写代码这么多年几乎每个人都碰见过这种怪事在 Windows 上写好的脚本丢到 Linux 服务器上执行结果报错$\r: command not found或者用 Vim 打开一个从 Windows 拷过来的文件每行结尾都挂着一个^M再或者用串口往终端发数据时光标明明已经移到行首但下一行内容却把上一行盖掉了。这些坑的源头往往就是两个又小又容易被忽视的字符\r和\n。回车换行符听起来是基础中的基础但真踩进去才发现它牵扯到历史遗留、操作系统差异、协议规范、编辑器行为甚至 Git 的换行符策略。这篇文章会把\r和\n的前因后果、实际表现、转换工具和排查技巧一次性讲清楚让你以后再遇到行尾符相关的问题时不用靠猜直接按图索骥就能解决。适合所有写代码的人、做文本处理的人以及经常在不同系统之间倒腾文件的人读一读。1. 回车和换行的前世今生为什么会有两个字符1.1 从打字机时代说起CR 和 LF 的原始含义要理解\r和\n不能只把它们当成两个没头没脑的转义字符它们其实是打字机时代的遗产。“回车”Carriage Return缩写 CR和“换行”Line Feed缩写 LF原本是电动打字机上的两个机械动作。老式电传打字机在打印内容时纸张是横向移动的打印头或者说“字车”每打一个字符就往右挪一格。一行打满之后要开始新一行必须做两件事第一把字车推回最左边这个动作叫回车第二把纸向上卷一行让打印头对准新的空白行这个动作叫换行。这两个动作配合起来才能让下一篇内容从新的一行开始输出。后来计算机继承了这套体系并且在 ASCII 编码表里给它们分配了固定的编号回车符是 ASCII 码 13十六进制0x0D转义表示就是\r换行符是 ASCII 码 10十六进制0x0A转义表示就是\n。可以这么记忆在 ASCII 码表里\r对应M这个字母在字母表中的位置往后数一位实际上\r的十六进制0x0D和回车英文首字母 R 的编码0x52没有直接关系但用“Carriage Return 里的 R”辅助记忆挺方便\n对应Line Feed里的 N 可以让思路更顺一些。理解了这个背景你就会明白一个关键点回车和换行本来是两个独立动作。既然是两个动作那计算机在处理文本时“行结束”到底该用哪一个、还是两个都用就有了不同选择。这些选择直接催生了后面所有兼容性问题。1.2 操作系统的“三分天下”LF、CR、CRLF 是怎么来的不同操作系统对这个问题的答案完全不一样这也是整个换行符话题里最核心、最需要记住的部分操作系统 / 环境行尾符表示底层字节序列Unix / LinuxLF即\n0x0A现代 macOSOS X 及之后LF即\n0x0A经典 Mac OSSystem 9 及之前CR即\r0x0DWindows / DOS 系CRLF即\r\n0x0D 0x0A为什么会有这种差异这得从各自的历史讲起。Unix 诞生于 20 世纪 70 年代彼时内存和存储都极其昂贵设计者觉得“行结束”只需要用一个字符表示就够所以选了 LF。为什么选 LF 而不是 CR有一种说法是由于最初 Unix 终端上的回车已经有了“回到行首”的用途而换行更接近“移动到下一行”的语义加上当时人们更关注“新起一行”而不是“回到行首”于是 LF 成了 Unix 的默认选择。这个单字符方案一直延续至今Linux 和 macOS 都沿用了它。Windows 的祖先 DOS 则直接继承了 CP/M 操作系统的做法。CP/M 是 20 世纪 70 年代末在 8 位微机上非常流行的系统它最早把文本行结束定义为 CRLF也就是回车加换行。这样做的原因同样很机械要让打字机状态的设备真正到达新行起点必须先回车字车归位再换行纸张上移两个字节都写上才完整。DOS 后来被 Windows 继承于是 CRLF 这个习惯就一路留了下来。经典 Mac OS 则是另一个极端它用的是 CR 作为行尾符。好在这种特立独行在 macOS 转向 Unix 内核后已经被修正现在市面上绝大多数 Unix 系系统都统一使用 LF 了。这三套标准并存给文本处理造成了几乎每天都会遇到的困扰一个\r和\n排列组合的问题轻则让文件看起来一团乱重则让程序直接崩掉。接下来我就从实际行为入手把这些坑一个个拆开看。2. 核心细节解析\r 和 \n 在不同场景下的真实行为2.1 二进制视角下的行尾符文件里到底存了什么很多人以为在编辑器里看到一行行文字文件里就是一行行文字顺序排列实际上文件里存的只是字节序列所谓“换行”完全是由字节序列中的特殊控制字符表示出来的。我们可以用十六进制工具看一看真实存储。假设有个hello.txt里面内容很简单hello world如果这个文件是 Linux 上保存的十六进制大概是68 65 6c 6c 6f 0a 77 6f 72 6c 64 0a看到没有hello后面跟了一个0x0A也就是\n然后才是world最后又一个0x0A表示文件结束前的换行。这里的hello的 ASCII 码分别是68 65 6c 6c 6f末尾没有回车。但这个文件如果是在 Windows 上保存的十六进制就是68 65 6c 6c 6f 0d 0a 77 6f 72 6c 64 0d 0a区别一目了然每一行结束的地方多了0x0D也就是\r。这多出来的一个字节就是跨平台文件错乱的根本来源。再往深一点说文本文件行尾符的选择不仅影响存储长度还会影响很多自动判断文件类型的工具结果。比如 Linux 的file命令对一个 CRLF 换行的纯文本文件经常输出类似text.txt: ASCII text, with CRLF line terminators而对 LF 文件则只输出text.txt: ASCII text这就等于直接告诉你文件是哪种风格。如果文件里既有 CRLF 又有孤立 CRfile也会给出不同提示。所以在排查换行符问题时file命令是一个非常有用的第一手工具。2.2 编程语言里的转义\r、\n 和 \r\n 的语义差异在几乎主流编程语言里\r和\n都是转义字符分别代表 CR 和 LF。但它们在不同语境下的表现千差万别我挑几个最容易出问题的点讲。C 语言\n在 C 标准里被定义为“换行符”newline写入文本流时C 运行库会根据平台自动做转换。在 Windows 上printf(hello\n)写到文件里实际是两个字节0d 0a但在 Linux 上又是单个字节0a。这个“抽象换行”机制的好处是让开发者少操心坏处是一旦以二进制模式打开文件或者用了跨平台的文本处理库行为就不一致了。理解了这一点就能解释很多奇怪现象。Pythonprint()默认会在结尾追加\n但 Python 在读写文本文件时默认启用了“通用换行符”universal newlines模式。open(file.txt)读文件时不管遇到\r\n还是\r都会被统一翻译成\n写文件时如果你不显式指定newline参数又会被翻译回平台默认的行尾Windows 上是\r\n。所以同一个 Python 脚本在不同系统上写出的文件行尾可能不同这在做数据交换时特别容易坑到人。JavaScript字符串里的\r\n就是字面的 CRLF但像String.prototype.split(/\r?\n/)这种正则就是为了同时兼容 LF 和 CRLF 而写的。处理从接口拿回来的文本时很多人只按\n分割结果 Windows 来源的每一行末尾都残留一个\r不仔细看根本发现不了。Java / C#System.lineSeparator()或Environment.NewLine会返回当前平台的行尾符这是推荐用法。直接写死\n也不是不行但如果这个程序要生成配置文件供其他系统读取写死就埋下隐患。终端上的\r行为又跟文件完全不同。在终端里\n通常会被终端驱动翻译成“回车换行”两个动作这也是为什么你打印a\nb时b 会出现在新一行的开始。而单独输出\r则只把光标移回当前行行首不换行。这个特性被广泛用于实现进度条、动态加载动画和命令行交互界面。比如打印\rProgress: 50%就会在同一行反复覆盖显示而不是每次新增一行刷屏。2.3 网络协议中的 CRLF一个都不能少除了文件系统\r\n在网络协议里也是硬性规定。HTTP 协议规定头部字段的每一行必须以\r\n结束请求行、状态行、各个 Header 之间都靠 CRLF 分隔最后用一个空行也就是\r\n\r\n表示头部结束。SMTP邮件协议、FTP、POP3 也同样遵循 CRLF 规范。为什么网络协议也选 CRLF这是为了向前兼容时代的产物。早期网络设备很多是从电传终端演化来的CRLF 更能准确表达“一行真正结束”的语义于是 RFC 文档就把 CRLF 定为标准。实际开发中如果你手动拼接 HTTP 请求时只用\n一些严格实现的服务器会直接解析失败返回 400 错误。这种问题在写底层 socket 协议时最容易碰到因为高层框架往往已经帮你处理了但一旦手动拼包一个\r的缺失就能让整个包报废。3. 实操查看、转换和处理换行符的完整方案3.1 跨平台查看行尾符编辑器、命令行、二进制工具处理换行符问题第一步是准确知道当前文件的行尾风格这一步别全靠肉眼猜用工具看最靠谱。VS Code打开一个文件后看右下角状态栏会显示类似UTF-8、LF或CRLF的字样。点一下那个LF或CRLF可以在两种模式之间切换。另外可以通过设置files.eol: \n或\r\n来控制新文件的默认行尾符团队协作时一般建议统一成\n。Notepad菜单栏选择“视图 → 显示符号 → 显示行尾符”开启后 CRLF 会显示为CR LF或↵符号LF 单独显示为LF。也可以看右下角状态区域会显示当前文档是Windows (CRLF)还是Unix (LF)。Vim使用命令:set list可以显示隐藏字符其中^M就代表 CR$代表 LF 位置Vim 对行尾的标记。使用:set ff?可以查看当前文件格式常见值有unix、dos、mac。注意 Vim 的mac格式是指经典的 CR 行尾而不是现代 macOS 的 LF。命令行Linux / macOS 下用cat -A file.txtCRLF 会被显示为^M$CR 会显示为单独的^MLF 则是$。用less file.txt查看时CRLF 文件行尾会多出一个^M。更直接的是用xxd或hexdump -C看十六进制这是最权威的方式适合想要精确确认的场景。3.2 批量转换行尾符dos2unix、sed、perl 和 Python知道了行尾风格下一步就是转成你需要的格式。我按工具给大家列一个“抄作业清单”。方法一dos2unix / unix2dos这是最直观的专用工具Linux 发行版一般通过包管理器安装。用法dos2unix input.txt # CRLF 转 LF unix2dos input.txt # LF 转 CRLF dos2unix *.txt # 批量转当前目录下所有 txt dos2unix -n old.txt new.txt # 转完后输出为新文件不覆盖原文件macOS 上用 Homebrew 安装即可。Windows 上 Git Bash 自带这些工具也可以用 WSL 里的 Linux 版本。方法二sed 处理没有专用工具的时候sed 也很好用。去掉所有 CR 字符sed -i s/\r$// file.txt # 把行尾的 \r 删掉其他位置的 \r 保留 sed -i s/\r/\n/g file.txt # 把文件里所有 CR 都换成 LF适合处理经典 Mac 格式注意第一行是“只删除行尾的\r”这是最常用的清理 CRLF 操作。如果文件里还有孤立 CR比如老 Mac 格式s/\r$//就不够用得用tr \r \n整体替换。方法三tr 命令cat file.txt | tr -d \r newfile.txt # 删除所有 CR tr \r \n old.txt new.txt # 把所有 CR 替换成 LFtr -d \r是所有“隐藏^M清理”里面最无脑、最不容易出错的做法前提是你要确认这些 CR 都是行尾符而不是有意的数据。方法四Python 脚本如果你在写自动化脚本直接写个 Python 文件更灵活。一个小示例with open(input.txt, r, newline) as f: content f.read() # 统一换成 LF content content.replace(\r\n, \n).replace(\r, \n) with open(output.txt, w, newline) as f: f.write(content)关键在于newline它会禁用 Python 的通用换行符自动转换让你读到原始内容这样自己控制转换结果最稳定。方法五Git 配置策略如果你遇到的问题是“Git 老是提示 CRLF 会被替换成 LF”那责任不一定在你的文件而在 Git 的换行符策略。常用的配置有三种git config --global core.autocrlf true # Windows 开发者提交时转 LF检出时转 CRLF git config --global core.autocrlf input # Linux/macOS 开发者提交时转 LF检出时保持 LF git config --global core.autocrlf false # 完全关闭转换更规范的做法是在仓库根目录放一个.gitattributes比如* textauto *.sh text eollf *.bat text eolcrlf这样能保证团队协作时脚本文件统一为 LF批处理文件统一为 CRLF避免每个成员因为本地配置不同而产生无意义的换行符变更。3.3 用 Vim 快速修改多个文件的行尾符如果你习惯 Vim 并且要批量修改多文件的行尾符可以这样:set ffunix 当前文件转成 LF :set ffdos 当前文件转成 CRLF批量改所有打开的文件可以用:argdo:args *.txt :argdo set ffunix | update这条命令会让 Vim 对所有匹配的 txt 文件统一转成 LF 并保存。日常维护配置文件时非常方便不需要安装任何额外插件。4. 常见问题排查与避坑经验实录4.1 “^M”是怎么来的如何清理干净“^M”是很多终端工具对 CR 字符的可视化表示它的显示方式是“^”加“M”因为 ASCII 码 13 和第 13 个字母 M 对应用控制字符表示就是^M。当你在 Linux 下用 Vim、cat 或 less 打开一个 Windows 来源文件时CRLF 中的 CR 就会被显示成^M看起来很闹心但它是完全正常的字符不是文件损坏。清理^M最直接的办法是上面提到的tr -d \r或者sed -i s/\r$//。这里我特别提醒一句先备份再批量处理。有些文件里的 CR 可能是二进制数据的组成部分或者是某些旧程序有意写入的字段分隔符盲目删除会让数据错乱。处理前先用file确认类型再用十六进制工具看头尾确认 CR 都出现在行尾再动手批量清理。4.2 Shell 脚本在 Linux 上报错$\r: command not found这个错误几乎是所有在 Windows 上写脚本的人都会撞上的经典坑。原因就是脚本文件是 CRLF 行尾Linux 的 Shell 解析器在执行脚本时把每行结尾的 CR 当成了命令名的一部分。比如你写着echo hello实际解析器看到的是echo hello\r最后那个\r被当成一个奇怪的命令于是报错。解决方法是把脚本转成 LF 行尾。在 Linux 上执行sed -i s/\r$// deploy.sh或者用 dos2unixdos2unix deploy.sh如果你在 Windows 上用 VS Code 编辑脚本更一劳永逸的办法是修改 VS Code 设置点击右下角CRLF选择LF然后在命令面板执行“Convert Indentation to Spaces”之类的操作让文件保存成 LF。对团队协作项目强烈建议在仓库根目录配置.gitattributes强制 sh 文件为 LF从源头断绝问题。4.3 终端进度条和日志刷屏\r 的正确打开方式\r不只是文件处理里的“麻烦精”在终端交互里它是实打实的好帮手。最典型的场景是进度条。很多命令行工具显示动态进度时不是不断打印新行而是用\r覆盖当前行。比如在 Python 里import time for i in range(101): print(f\rProgress: {i}%, end) time.sleep(0.05)这里print的end默认不追加\n然后每轮循环输出\rProgress: x%由于\r会把光标移回行首新输出的内容就会覆盖旧内容屏幕上看起来是原地刷新。如果少写了这个\r或者用了end\n就会变成不断往上滚动的日志最终效果完全不同。但这里有个很隐蔽的坑如果你的输出内容长度每次都不一样比如从Progress: 9%变成Progress: 100%多出来的位数会把旧内容的残留字符留下来导致显示错乱。解决方法是固定输出区域宽度比如f\rProgress: {i:3d}%或者用 ANSI 转义序列先清除当前行。4.4 换行符问题速查表为了方便排查我把日常工作中最容易遇到的行尾符问题和对应解法整理成了一张表现象常见原因解决方案Linux 下看到文件行尾有^M文件是 Windows CRLF 风格sed -i s/\r$// 文件或dos2unix 文件Shell 执行脚本报$\r: command not found脚本是 CRLF 行尾转成 LF 行尾配置 .gitattributes 统一Git 提示“CRLF will be replaced by LF”Git 换行符策略未统一配置core.autocrlf或写.gitattributesPython 读文件后每行末尾多出\ropen 时没有用通用换行模式使用open(file, newlineNone)或显式 strip 行尾\r串口或日志输出被覆盖、刷屏输出中\r\n与\n混用统一使用\r\n表示换行用\r做行内刷新HTTP 请求解析失败手动拼接协议头时用了 LF 而不是 CRLF严格按协议规范发送\r\n经典 Mac 文件打不开或显示乱码行尾符是孤立 CRtr \r \n统一转成 LF这张表基本覆盖了我这些年遇到过的绝大多数行尾符问题。每次遇到诡异现象先别急着改逻辑检查一下行尾符往往能省下大量排查时间。4.5 一个最容易忽视的细节文件末尾到底该不该有换行最后再聊一个和\n密切相关的细节文件最后一行之后到底要不要保留换行符。很多编辑器在保存时默认会在文件末尾加一个换行符而一些工具比如 Git也会在 diff 中显示 “No newline at end of file” 的提示。这是因为 POSIX 标准规定“行”是以换行符结尾的一系列字符如果没有末尾换行最后一行严格来说不算完整的行。C 编译器的某些老版本也会对“没有末尾换行”的源文件给出警告。规范的做法是文本文件末尾保留一个换行符。它不会影响大多数程序读取但可以避免多个文件拼接时最后一行和下一个文件开头粘在一起。在 VS Code 里可以通过设置files.insertFinalNewline: true来保证保存时自动补上。如果你在写脚本、配置文件或任何要被其他程序逐行读取的文本务必记得在末尾留一个\n。根据我自己的经验换行符问题大多数时候不是技术难度大而是因为太基础、太不起眼大家都默认不会出错结果它一出错就把人折腾得够呛。建议在动手处理文件前先确认三件事文件来自哪个平台、当前默认行尾符是什么、接收方约定用什么行尾符。只要这三件事想清楚了\r和\n就再也坑不了你。