python用open()配合for循环流式迭代读文件最轻量可靠，因文件对象是迭代器，按需读取缓冲块而非全载入内存；应避免list(f)或readlines()导致内存暴涨，慎用seek()破坏状态，优先rstrip('\r\n')替代strip()提升性能，编码错误宜用surrogateescape而非ignore，多进程分文件切片比多线程更有效。
用 open() 配合 for 循环读文件，不是“读取”，是流式迭代
Python 的 open() 返回的文件对象本身就是迭代器，for line in f: 不会把整个文件加载进内存，而是按需读取缓冲块、逐行 yield。这是处理 GB 级文本文件最轻量也最可靠的方式。
常见错误现象：list(f) 或 f.readlines() —— 这俩会一次性把全部行塞进内存，1GB 文件轻松吃掉 3–4GB 内存（字符串开销+指针）。
- 必须用
for line in open(...)或显式with open(...) as f: for line in f: - 别在循环里调
f.seek(0)或反复readline()，破坏迭代状态易出错 - 如果需要跳过 BOM，用
encoding='utf-8-sig'，否则首行可能多出\ufeff
line.strip() 和 line.rstrip('\n') 性能差一倍？真有影响
对每行做清洗时，strip() 会扫描所有空白字符（空格、制表、回车、换行等），而 rstrip('\n') 只切末尾换行符。在 GB 级日志或 CSV 场景下，这个差异实测可拉高 15%–20% CPU 时间。
使用场景：纯文本按行处理、无前后空格干扰时，优先用 rstrip('\n')；若原始数据含不规则缩进或空格分隔字段，再考虑 strip()。
立即学习“Python免费学习笔记（深入）”；
-
line.rstrip('\r\n')更稳妥，兼容 Windows/Linux/Mac 换行符 - 避免
line.replace('\n', '').replace('\r', '')—— 创建多个中间字符串，内存和速度双输 - 如果后续要 split 字段，直接
line.rstrip('\r\n').split('\t')，别先 strip 再 split
遇到编码错误就崩？errors='ignore' 不是万能解药
大文件常混杂异常字节（比如日志截断、终端乱输、编码不一致），用 errors='ignore' 看似省事，实际会静默丢数据，且后续解析字段时可能因长度错位导致 IndexError 或逻辑错误。
更可控的做法是捕获异常并记录上下文，而不是跳过：
- 用
errors='surrogateescape'（Python 3.5+），把非法字节转成 Unicode 替代符，后续可用.encode('latin1', 'surrogateescape')恢复原字节 - 或手动按块读：
f.read(8192)+decode(..., errors='replace')，自己控制 buffer 大小和容错粒度 - 绝对不要在生产脚本里写
try: ... except: pass吞掉编码异常
想并发加速？multiprocessing 分文件比 threading 分行靠谱得多
CPython 的 GIL 让多线程对 I/O 密集型任务提速有限，且多线程共享文件句柄容易触发 ValueError: I/O operation on closed file。真正有效的并行是按文件切片（如用 seek() 定位到某行起始，配合 os.stat().st_size 均分偏移）。
但注意：按字节切片不能保证行完整，必须找到最近的换行符再开始读，否则首行会缺前半截。
- 用
linecache.getline(filename, n)适合随机查，不适合顺序扫 - 第三方库如
smart-open支持 S3/HDFS 分块，但本地文件没必要引入依赖 - 单进程够用时，别硬上多进程——进程启动/通信开销可能抵消收益
真正难的从来不是“怎么读”，而是“怎么确保每行都干净、不错位、不丢字节、不爆内存”。尤其当文件来自不同系统、没统一编码、没校验机制时，靠一行 for line in open(...) 走天下，反而最容易翻车。
