itertools.batched() 更安全，因其不预加载全部数据、内存占用恒定；手写切片易致全量展开，引发 OOM 或阻塞。
batched() 为什么比手写切片更安全
直接用 itertools.batched() 处理大迭代器，核心优势是它不预加载全部数据——它只维持当前批次的元素，内存占用恒定。手写 list(it)[i:i+n] 或 islice 循环容易误触发全量展开，尤其当 it 是生成器或数据库游标时，可能 OOM 或阻塞超时。
常见错误现象：MemoryError、迭代中途卡住、CPU 占用突增但无输出。
使用场景：读取超大 CSV 文件流、分页拉取 API 数据、逐批处理日志行。
batched() 的参数陷阱和替代选择
batched() 只接受两个参数：iterable 和 n（每批元素数），不支持自定义填充、跳过不完整批次等逻辑。遇到末尾不足 n 个元素时，默认返回最后一组（长度 n）。
如果需要补全（比如喂给固定尺寸模型输入），得自己 wrap：
from itertools import batched, chain, repeat <p>def batched_padded(iterable, n, fillvalue=None): for batch in batched(iterable, n): yield tuple(batch) + tuple(repeat(fillvalue, n - len(batch)))</p>
性能影响：补全逻辑增加少量开销，但远低于转成 list 再 pad；batched() 本身是 C 实现，比纯 Python 循环快 2–3 倍。
和 chunked()（more-itertools）对比要注意什么
more-itertools.chunked() 行为相似，但返回的是 list 而非 tuple，且在 Python
-
batched()返回tuple，不可变，适合后续 hash 或作为 dict key -
chunked()返回list，可原地修改，但多一次内存分配 -
batched()是标准库，无额外依赖；chunked()需装more-itertools - 两者都不缓存整个迭代器，但
chunked()对某些惰性对象（如map）兼容性略差
真实大迭代器下的实操建议
处理真正的大迭代器（比如千万级日志行），光靠 batched() 不够，得配合下游消费节奏控制：
- 避免把整批
tuple一次性塞进 pandas DataFrame —— 改用pd.concat([pd.DataFrame(batch) for batch in batched(...)], ignore_index=True)会累积内存；应逐批.append()或用chunksize参数反向驱动 - 若下游是数据库批量插入，确认驱动是否支持
executemany()；传入batched()结果前，先map(tuple, ...)转成元组序列（多数驱动要求） - 调试时别用
print(list(batched(...)))—— 这会强制展开全部批次，失去流式意义 - 注意
n的取值：太小（如n=1）导致调用开销占比高；太大（如n=100000）可能让单批处理时间过长，阻塞协程或超时；推荐从1000起测，按吞吐和延迟调优
最易被忽略的一点：batched() 不感知迭代器内部状态，如果源迭代器本身有副作用（如文件指针移动、网络重连），批次边界可能打乱业务语义——这时必须用带状态封装的自定义迭代器，而不是依赖 batched() 切分。
