for line in file 更安全，因其基于迭代器协议每次只读一行并及时回收内存，而f.readlines()一次性加载全部行到内存，易致memoryerror；处理大文件需注意编码、换行符、文件句柄管理和超长行分块读取。
read() 会把整个文件塞进内存，GB级文件直接触发 MemoryError 或系统杀进程——这不是代码写错了，是读法本身就不适合大文件。
为什么 for line in file 比 f.readlines() 安全得多
关键在迭代器协议和缓冲机制：f.readlines() 返回一个完整列表，每行都是独立字符串对象，全部驻留内存；而 for line in file 底层调用 file.__next__()，每次只从 OS 缓冲区捞一行，旧行对象可被立即回收。
- 实测：1.2GB 日志文件，
f.readlines()占用 3.8GB 内存；for line in f峰值仅 8MB - 注意编码：如果含中文或特殊字符，务必显式指定
encoding='utf-8'，否则UnicodeDecodeError可能打断迭代 - 换行符处理：
line末尾带\n，需用line.rstrip('\n')而非line.strip()（后者会误删首尾空格）
生成器函数封装时必须加的三个细节
自己写 yield 函数不难，但漏掉下面任意一条都可能让“内存友好”失效：
- 必须用
with open(...)包裹，否则文件句柄泄漏，Linux 下最多打开 1024 个文件就报OSError: Too many open files - 生成器内部不要做耗时操作（如网络请求、数据库写入），否则单行处理时间过长，看起来像卡死
- 若需跳过空行或注释行，用
if line.strip() and not line.startswith('#'):判断，别用if line.strip():后再二次strip()，避免重复创建字符串对象
遇到超长行（>1MB）怎么办
日志中偶尔出现单行几MB的堆栈或 Base64 字段，for line in f 会卡住甚至爆内存——这时得切回 read() 分块，但要手动按行切分：
def read_by_line_with_chunk(file_path, chunk_size=64*1024):
with open(file_path, 'r', encoding='utf-8') as f:
buffer = ''
while True:
chunk = f.read(chunk_size)
if not chunk:
if buffer:
yield buffer
break
buffer += chunk
lines = buffer.split('\n')
buffer = lines[-1] # 保留未结束的行
for line in lines[:-1]:
yield line
- 该函数对超长行仍保持低内存，因为 buffer 始终只存“当前未闭合的一行 + 新 chunk”
-
chunk_size设为 64KB 是经验值：太小（如 1KB）导致 split 频繁；太大（如 1MB）则 buffer 突增风险升高 - 不能用于二进制文件，
split('\n')在bytes模式下会报错，得换成split(b'\n')并用buffer += chunk拼接字节串
真正容易被忽略的是：生成器本身不解决磁盘 I/O 瓶颈。当处理速度远快于磁盘读取时（比如纯字符串匹配），CPU 会长期等待，此时加 buffering=8192 参数提升 OS 层缓冲效率，比换库更直接有效。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
