陈易铭1. 文本I/O与二进制I/O：看似简单却常被误用的数据通道
先从一个很基础但经常会把人问住的问题说起：同样是读取一个文件，用文本模式和用二进制模式打开，程序里拿到的数据到底差在哪？很多人第一反应是“文本文件能直接看懂，二进制文件是一堆乱码”。这个回答大体没错，但它只描述了文件格式的表象，并没有触及I/O层面的本质区别。
我在帮团队排查问题时经常发现，不少写了三五年代码的开发者，遇到“读出来的字符串比原文件多出几个字符”“换行符莫名变成了两个”“图片文件读一半损坏”这类问题，排查半天找不到根因，其实症结往往就出在文本I/O和二进制I/O的概念混淆上。
先说结论：文本I/O的本质是用字符编码方案解释字节流的适配过程，而二进制I/O是字节流的原样搬运。 前者暗含了编码转换、换行符归一化、边界判断等多层逻辑，后者约等于一条管道铺到文件系统，送什么就运什么。两者在API设计、性能特征、跨平台表现上差异极大，却因为多数高级语言封装得“太顺滑”，导致很多人根本意识不到这几层隐藏操作的存在。
这篇文章会把这两类I/O从原理到实践拆开说透。无论是刚接触文件处理的新手，还是想搞明白“为什么文本读写这么慢”“为什么Windows上跟Linux上行为不一样”的进阶开发者，都能在里面找到对应的答案。文中的示例主要以Python为主，也会穿插Java、Go、C的对比，最后用一次真实排查案例演示如何靠I/O模式的正确选择解决线上问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一个字节的旅程：文本与二进制在底层到底差在哪
要理解两种I/O的分歧点，最简单的方式是跟踪一个字节从磁盘到内存的完整旅程。我拿一个例子说明：硬盘上有一个文件，里面存了内容 \x48\x65\x6C\x6C\x6F，也就是“Hello”这五个字母的ASCII码。
如果程序用二进制模式读取（比如Python里的 open(file, 'rb')），读进内存的就是这五个字节原封不动的样子。然后你想怎么处理都行，按字节数组操作，不经过任何解释层。
如果程序用文本模式读取（比如Python里的 open(file, 'r') 或 open(file, 'rt')），读进来的会是一个字符串 "Hello"。注意，从“五个字节”到“五个字符”之间有一个关键步骤——字符解码。Python会拿默认编码（通常是UTF-8）去把这五个字节翻译成Unicode字符。ASCII码恰好是UTF-8的子集，所以这里看不出差异。但如果文件里放的是 \xE4\xB8\xAD，也就是“中”字的UTF-8字节序列，二进制模式读出来是三个原始字节，文本模式则会解码成一个Unicode字符“中”。
所以说，文本I/O的“文本”二字，指的并不是文件内容长什么样，而是程序与文件之间那一层解码/编码的行为。只要加了这层行为，就必然附带三个隐藏操作：字节序列与字符集的互相转换、换行符规则的处理、以及“文件结尾”的判定逻辑。
换行符处理可能是最容易让人踩坑的点。Unix/Linux系统上，文本文件的行尾符是 \n（0x0A），Windows上是 \r\n（0x0D 0x0A）。文本模式读取时，C标准库和大量高级语言运行时会做一次“输入时把 \r\n 折叠成 \n，输出时再把 \n 展开成 \r\n”的转换。这本来是为了让上层开发者不操心平台差异，但副作用就是——在Windows上，你用文本模式打开一个Unix格式的 \n 文件，读出来的字符串和写入后的文件字节数可能对不上。这在需要对文件做哈希校验、按字节对比、或者做文件内容签名计算的场景里，会直接导致结果不一致。
二进制I/O没有这层烦恼，但相应的，它把“换行符我来处理”这个责任交给了程序员。你写 \n 就是 \n，文件里原本是 \r\n，读进内存也得自己判断并处理。
还有一个常被忽略的细节是EOF（文件结尾）的判定。在文本模式下，某些老派语言会按特殊字符来识别结尾，而二进制模式下必须以文件系统提供的真实长度为依据。这在高版本Python里已经基本透明了，但在C语言的 getc 系列函数里，文本模式下读到 0x1A（Ctrl+Z字符）就可能被当成EOF处理，这在处理非文本数据时是个著名的历史坑。
3. 换个视角看API设计：为什么不同语言的文本I/O长得完全不一样
讲完底层机制，再看各语言的API设计，很多“反直觉”的地方就说得通了。不同语言对两类I/O的暴露方式差异很大，有的严格区分，有的混在一起，搞不清楚它们的边界，写起跨平台代码就会很被动。
3.1 Python：模式字符串里的隐性开关
Python用 open() 的 mode 参数区分I/O类型，r、w、a 后面跟