必须用rb/wb模式读写二进制文件，否则会触发文本编码/解码导致错误；rb返回bytes，wb要求写入bytes，不可混用文本方法如readline()，应使用read()或read(n)。
不加'b'会导致读取结果被悄悄修改
Python 默认以文本模式打开文件，即使你没写 t。只要没显式指定 b，open() 就会启用换行符转换、编码解码和字节截断等行为——这对二进制数据是灾难性的。
比如 Windows 上的 \r\n 会被转成单个 \n；遇到 \x00（空字节）可能提前终止读取；如果文件里有非法 UTF-8 字节序列，UnicodeDecodeError 直接报错。
-
open('data.bin', 'r')→ 触发默认 UTF-8 解码，失败概率极高 -
open('data.bin', 'rb')→ 原样返回bytes对象，零转换 - 即使你后续用
.decode()手动处理，也必须先拿到原始字节，否则中间环节已失真
read() 返回类型不同，后续操作立刻出错
文本模式下 read() 返回 str，二进制模式返回 bytes。这两个类型在 Python 3 中完全不兼容，混用会直接抛 TypeError。
典型翻车场景：想用 struct.unpack() 解析二进制协议，但传入了 str：
立即学习“Python免费学习笔记（深入）”；
data = open('header.bin', 'r').read() # → str
struct.unpack('<I', data) # TypeError: a bytes-like object is required正确写法必须是：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
data = open('header.bin', 'rb').read() # → bytes
struct.unpack('<I', data) # OK-
bytes支持切片、索引、in判断（按字节）、struct/array操作 -
str的索引返回字符，不是字节；len()是字符数，不是字节数 - 某些库（如
numpy.frombuffer()、zlib.decompress()）只接受bytes或bytearray
跨平台写入/读取一致性彻底崩溃
如果你用 'w' 写二进制数据（比如加密密钥、图像像素），再用 'r' 读，Windows 和 Linux 下结果可能完全不同。
原因：文本模式写入时，Python 会把 \n 自动转为 \r\n（Windows）或保持 \n（Linux）；读取时又反向转换。而二进制模式绕过所有这些。
- 写入：
open('key.bin', 'wb').write(b'\x01\x02\n\x03')→ 磁盘上就是这 4 个字节 - 错误写法：
open('key.bin', 'w').write('\x01\x02\n\x03')→ 在 Windows 上实际写入 5 字节（\n变\r\n） - 更隐蔽的问题：用
'r'读取别人用'wb'写的文件，\r\n被还原成\n，长度变短，校验失败
gzip、pickle、图像等标准库模块强制依赖 rb/wb
几乎所有处理原始字节流的内置模块，内部都做了类型检查，只认 bytes，且文档明确要求文件句柄用二进制模式打开。
例如：
-
pickle.load(open('model.pkl', 'rb'))——load()第一个参数必须是bytes流 -
gzip.open('log.gz', 'rb')—— 底层 zlib 需要原始压缩字节，文本模式会破坏帧头 -
PIL.Image.open(io.BytesIO(data))的data必须来自'rb'，否则 JPEG 头\xff\xd8\xff可能被误判为 Unicode 错误
这些不是“建议”，是硬性契约。一旦用错模式，轻则 ValueError，重则静默损坏数据。
真正容易被忽略的点是：哪怕你只是临时用 hex() 查看内容，或者用 len() 统计大小，也得从 rb 开始——因为文本模式下的 len() 已经不是真实字节数了。
