流式分片迭代的核心目标是以可控块为单位边读边解析边处理，内存稳定在MB级并支持扩展；关键在控制节奏、显式管理边界、避免隐式加载，推荐用生成器封装f.read(chunk_size)并设4MB–8MB，二进制文件必用'rb'模式。
明确“流式分片迭代”的核心目标
不是把整个文件读进内存，也不是简单按行循环；而是以可控块为单位，边读、边解析、边处理，全程内存占用稳定在 MB 级别，同时支持后续扩展（如分发到多进程或集群）。关键在于：**控制读取节奏 + 显式管理边界 + 避免隐式加载**。
用生成器封装分块读取逻辑
直接使用 f.read(chunk_size) 配合 yield 是最轻量、最可控的方式。推荐 chunk_size 设为 4MB–8MB（兼顾 I/O 效率与内存压力），且对二进制文件必须用 'rb' 模式：
- 文本文件若需按行切分，不要在生成器里
split('\n')—— 容易截断跨块的长行，应由下游负责行缓冲或续行合并 - 二进制协议解析（如日志包、自定义帧格式）可在生成器内做基础帧头校验，只 yield 合法数据块
- 避免在生成器函数中打开/关闭文件——交给
with外层管理，确保异常时资源释放
适配不同数据形态的分片策略
“分片”不等于固定字节数切分。生成器应感知数据语义：
- CSV 文件：可先扫描首行确定字段数和分隔符，再按记录边界（而非字节）yield 行组，例如每次 yield 1000 行构成一个逻辑分片
- JSON Lines（每行一个 JSON 对象）：逐行读 +
json.loads()，累积 N 条后 yield 列表，天然支持结构化分片 - 固定长度记录（如传感器二进制日志）：用
struct.unpack()解析每条，按条数而非字节数组织分片，保证语义完整性
衔接下游处理时的关键约束
生成器只是“供气阀”，下游消费方式决定整体是否真正流式：
- 禁止将生成器转成
list()或传给pandas.read_csv()全量加载——这会瞬间吃光内存 - 批量写入数据库时，用
executemany()而非循环execute()；每分片处理完再 commit，避免长事务 - 若需并行加速，用
multiprocessing.Pool.imap()消费生成器，而非map()——前者保持惰性求值，不预取全部
