为何直接迭代文件对象会拆分行，而生成器不会？

问题现象 #

用multiprocessing.pool.ThreadPool的imap直接处理打开的文件对象时，行被拆成单个字符传入my_func，导致计算出错；但用自定义的按行打包的生成器时，就能正常按行批量处理。

核心原因 #

1. 文件对象迭代特性与imap分块逻辑不兼容
   文件对象虽然是可迭代对象（逐行返回内容），但multiprocessing池类的map/imap方法在处理这类“流式可迭代对象”时，会绕过上层的行迭代逻辑，直接按chunk_size指定的字节数拆分文件的底层缓冲区。拆分后的字节片段会被当成独立的任务元素，转成字符串后就变成了单个字符，这就是行被拆分的根本原因。

2. 对chunk_size参数的误解
   你之前以为chunk_size是把N行打包成列表传给my_func，但实际逻辑分两种情况：

   • 对于普通列表这类“非流”可迭代对象，chunk_size是按元素数量分块；
   • 对于文件对象这类“流式”可迭代对象，chunk_size是按字节数拆分缓冲区，完全和行边界无关。

自定义生成器能正常工作的原因 #

你写的chunked_reader生成器先完成了逐行读取+批量打包的逻辑：先按行迭代文件，把指定数量的行打包成一个列表作为单个元素返回。此时传给imap的可迭代对象是“列表元素”，imap会把每个列表当成独立任务传给my_func，自然不会拆分行，完全符合批量处理的预期。

正确用法建议 #

• 如果my_func是处理单一行：直接用pool.imap(my_func, f)即可，不需要指定chunk_size，文件对象的逐行迭代会被正确识别，每个任务就是完整的一行。
• 如果my_func是批量处理多行：用自定义生成器把多行打包成列表后再传给imap，此时my_func接收的参数就是行的列表，和你预期一致。

内容的提问来源于stack exchange，提问作者beginner_