053、文件读写那些坑：open 的模式、编码检测、大文件分块与上下文安全
一个让我加班到凌晨两点的bug
去年接手一个数据清洗项目，客户给了一堆CSV文件，说是“标准UTF-8编码”。我随手写了个循环读取，本地测试一切正常。上线后第三天，运维半夜打电话说程序崩了——某个文件读到一半直接抛出UnicodeDecodeError，整条流水线中断，数据丢失了将近两万条。
我远程连上去一看，那个文件开头几个字节是\xff\xfe，BOM头标记的是UTF-16 LE。客户所谓的“标准UTF-8”其实是Excel另存为时默认的“带BOM的UTF-8”，而中间混入了一个从老旧系统导出的UTF-16文件。更致命的是，我用了with open(file, 'r', encoding='utf-8')硬编码了编码方式，遇到不匹配直接炸。
从那以后，我写文件读写代码都会多问自己一句：这个文件真的像它看起来那样吗？
open 的模式：你以为你懂，其实你只懂一半
open()的第二个参数，大多数人只会用'r'、'w'、'a'。但实际项目中，模式组合才是真正的坑。
二进制模式与文本模式的混用
# 别这样写——Windows下会出鬼withopen('data.bin','r')asf:data=f.read()Windows系统下，文本模式会自动把\r\n转成\n。如果你读的是二进制文件（图片、压缩包、pickle序列化数据），这种转换会破坏数据完整性。正确的做法是：
# 二进制文件必须用'b'模式withopen('image.jpg','rb')asf:raw_bytes=f.read()读写混合模式：r+、w+、a+
这三个模式我见过太多人用错。简单记一个原则：
r+：文件必须存在，指针在开头，可以读也可以写。但写的时候会覆盖原有内容，不是追加。w+：文件不存在就创建，存在就清空。可以读，但读到的内容是你刚写进去的。a+：文件不存在就创建，指针在末尾。读的时候需要先seek(0)，否则读不到任何东西。
# 踩过坑的写法：想用r+在文件末尾追加withopen('log.txt','r+')asf:f.write('new line\n')# 这行会写在文件开头，覆盖原有内容！正确的追加方式是用'a'或'a+'，或者先seek(0, 2)把指针移到末尾。
容易被忽略的'x'模式
'x'模式（独占创建）是我最近才养成习惯用的。它只在文件不存在时创建并写入，如果文件已存在直接抛FileExistsError。这在多进程写日志、缓存文件生成时特别有用，避免两个进程同时写同一个文件导致数据混乱。
try:withopen('output.txt','x')asf:f.write('独占写入')exceptFileExistsError:# 这里可以处理冲突，比如重命名或跳过pass编码检测：别信文件名，信字节
回到开头的故事。硬编码编码方式就像在赌桌上押全部身家。正确的做法是检测文件的实际编码。
chardet 库的正确用法
chardet是Python生态里最常用的编码检测库，但它有个坑：检测小文件时准确率极低。
importchardet# 错误示范：只读前100字节就判断编码withopen('unknown.csv','rb')asf:raw=f.read(100)result=chardet.detect(raw)encoding=result['encoding']# 这里大概率是'ascii'，实际可能是'utf-8'正确的做法是读取足够多的样本，至少几千字节：
defdetect_encoding(file_path,sample_size=10000):withopen(file_path,'rb')asf:raw=f.read(sample_size)result=chardet.detect(raw)# chardet返回的confidence是0到1之间的置信度ifresult['confidence']<0.8:# 置信度太低，可能需要人工介入或尝试常见编码# 这里踩过坑：有些文件混合了多种编码return'utf-8'# 回退到最通用的编码returnresult['encoding']BOM头的处理
Windows生成的UTF-8文件经常带BOM头（\xef\xbb\xbf）。Python的open()函数不会自动处理BOM，需要手动跳过或使用utf-8-sig编码：
# 自动处理BOM头withopen('excel_export.csv','r',encoding='utf-8-sig')asf:# BOM头会被自动忽略，不会出现在读取的内容中content=f.read()utf-8-sig是Python特有的编码别名，它会在读取时自动跳过BOM头，写入时自动添加BOM头。如果你需要兼容Excel，写入时用这个编码最省心。
大文件分块：别让内存爆炸
处理几百MB甚至GB级别的文件时，f.read()直接读取全部内容到内存是自杀行为。我见过一个同事用readlines()读2GB的日志文件，服务器直接OOM被kill。
逐行读取的陷阱
# 看似安全的逐行读取，其实有隐患withopen('huge_file.log','r')asf:forlineinf:process(line)这个写法本身没问题，Python的文件对象是迭代器，内部会按行缓冲读取。但问题在于：如果某一行特别长（比如一个JSON对象被压缩成一行），这一行仍然会占用大量内存。
# 更安全的做法：按固定字节块读取defread_in_chunks(file_path,chunk_size=1024*1024):withopen(file_path,'rb')asf:whileTrue:chunk=f.read(chunk_size)ifnotchunk:breakyieldchunk# 使用示例forchunkinread_in_chunks('huge_file.bin'):process_chunk(chunk)处理超大文本文件时的行分割
按块读取二进制文件简单，但处理文本文件时，一个块可能切断了某行。需要自己处理行边界：
defread_lines_in_chunks(file_path,chunk_size=1024*1024):withopen(file_path,'r',encoding='utf-8')asf:buffer=''whileTrue:chunk=f.read(chunk_size)ifnotchunk:ifbuffer:yieldbufferbreakbuffer+=chunk# 按换行符分割，保留最后一个不完整的行lines=buffer.split('\n')forlineinlines[:-1]:yieldline+'\n'buffer=lines[-1]这个写法有个细节：split('\n')会丢失换行符，所以yield的时候要补回来。如果你需要保留原始换行符（比如处理CSV时），可以用splitlines(True)。
上下文安全：with 不是万能药
with open()是Python最优雅的语法糖之一，但它并不能解决所有资源管理问题。
多个文件的上下文管理
# 同时打开两个文件，用with嵌套withopen('source.txt','r')assrc:withopen('dest.txt','w')asdst:forlineinsrc:dst.write(line)Python 3.1+支持在一个with语句中打开多个文件：
# 更简洁的写法withopen('source.txt','r')assrc,open('dest.txt','w')asdst:forlineinsrc:dst.write(line)自定义上下文管理器
有时候你需要管理的不是文件，而是数据库连接、网络socket等资源。可以自己实现上下文管理器：
classManagedFile:def__init__(self,filename,mode):self.filename=filename self.mode=mode self.file=Nonedef__enter__(self):self.file=open(self.filename,self.mode)returnself.filedef__exit__(self,exc_type,exc_val,exc_tb):ifself.file:self.file.close()# 返回False会传播异常，返回True会抑制异常# 这里踩过坑：不要轻易返回True，会吞掉异常returnFalse异常处理与资源释放
with语句保证即使发生异常，__exit__也会被调用。但有个细节：如果在__enter__中发生异常，__exit__不会被调用。
# 危险的写法try:withopen('可能不存在的文件.txt','r')asf:data=f.read()exceptFileNotFoundError:# 这里没问题，with已经处理了资源释放pass但如果open()本身抛异常（比如权限不足），文件对象根本没创建，也就不需要释放。with语句的设计已经考虑到了这一点。
个人经验性建议
永远不要信任文件扩展名和文件名。
.csv文件可能是Excel导出的带BOM的UTF-16，.txt文件可能是GBK编码。写代码时先检测编码，或者提供一个可配置的编码参数。大文件处理时，先估算内存占用。一个简单的公式：文件大小 × 编码膨胀系数（UTF-8中文约3倍）≈ 内存占用。如果超过可用内存的30%，考虑分块处理。
写日志文件时，用
'a'模式而不是'w'。我见过太多人用'w'模式写日志，每次重启程序就把之前的日志清空了。如果担心日志文件太大，配合logging模块的RotatingFileHandler使用。测试文件读写时，一定要测试边界情况：空文件、只有一行、只有换行符、包含特殊字符（如
\x00）、文件被其他进程锁定。这些情况在单元测试中很容易被忽略，但生产环境一定会遇到。最后一条，也是最重要的一条：写文件时，先写入临时文件，再重命名。这样即使写入过程中程序崩溃，也不会破坏原始文件。这个习惯救过我很多次。
importosimporttempfiledefsafe_write(filename,content):# 先写入临时文件tmp=tempfile.NamedTemporaryFile(mode='w',delete=False,dir=os.path.dirname(filename),prefix='tmp_',suffix='.tmp')try:tmp.write(content)tmp.close()# 原子操作：重命名os.replace(tmp.name,filename)except:os.unlink(tmp.name)raise文件读写看起来是Python最基础的操作，但恰恰是这些基础操作，在线上环境最容易出问题。希望这篇笔记能帮你少踩几个坑。
