Python tee 复制迭代器的隐藏成本

tee 使迭代器变为内存敏感型，因共享缓冲区导致内存随最慢分支增长；list 更安全可控，因其内存上限明确且行为透明。

tee 会把迭代器变成内存敏感型操作

调用 itertools.tee 后，原始迭代器不再“流式”——它会被强制缓存所有已产出的值，直到所有分支都消费完。这不是延迟复制，而是共享缓冲区：每个 tee 返回的迭代器都依赖同一份内部队列。

• 一旦任一分支读得慢，其他分支就卡在缓存未清空的位置，内存持续增长
• 原始迭代器如果是生成器（比如 range(10**9) 或文件逐行读取），tee 会悄悄把它拖进内存陷阱
• 缓存是按需增长的，但无法主动释放；即使你只取前 5 个元素，后续没消费的分支仍保有全部已遍历项

为什么 list(iterator) 有时比 tee 更安全

当你要复用迭代结果且总量可控时，显式转成 list 反而更透明、更易控。因为你能一眼看出内存占用上限，也能手动控制是否深拷贝或切片。

• tee 的缓存行为隐藏在 C 层实现里，调试时看不到中间状态；而 list() 的开销一目了然
• 如果两个分支处理逻辑差异大（比如一个要 sum()，另一个要 max()），直接 list(it) 再分别传入，比 a, b = tee(it) 更少意外
• 注意：不是说 list 没成本，而是它的成本可预期；tee 的成本取决于最慢分支的消费节奏

tee 在管道式处理中容易引发死锁

和 itertools.chain、Filter 等惰性函数混用时，tee 的缓冲机制可能让整个流水线“悬停”。典型表现是程序卡住不报错，CPU 低、内存缓步上涨。

• 例如：a, b = tee(filter(pred, gen)) —— 如果 b 先被完全消费，a 再调用 next()，没问题；但如果 a 和 b 交替取值，底层缓冲区会反复扩容
• 嵌套 tee（比如 tee(tee(it)[0])）会让缓冲层级变深，调试难度指数上升
• 用 sys.getsizeof 查不到 tee 对象本身大小，它底层的 deque 缓存不在 python 对象内存统计范围内

替代方案：按场景选更轻量的复制方式

多数时候你并不需要真正的“迭代器分叉”，只是想多次遍历数据——那就别从 tee 开始想。

立即学习“Python免费学习笔记（深入）”；

• 小数据（list(it)，再用 iter(lst) 多次构造新迭代器
• 大数据但只需部分重用：用 itertools.islice + 重放原始源（比如重新打开文件、重调生成器函数）
• 真正需要并行消费：考虑 queue.Queue 或 threading.local 配合生成器，而不是靠 tee 做同步
• 调试时快速验证：把 tee 换成 [it, copy.copy(it)]（仅限支持 copy 的迭代器），能立刻暴露是否真需要共享状态

真正麻烦的不是 tee 不能用，而是它看起来无害，实际把“谁在什么时候消费什么”这个关键时序问题藏得太深。只要有一个分支滞后，整条链路的内存和响应行为就脱离直觉。