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