itertools.chain() 拼接大量可迭代对象更快且内存友好，但小列表用+或extend()更直接；chain()返回惰性迭代器，强制转list会抵消优势；product可替代嵌套for但返回元组需注意解包；groupby仅合并相邻相等元素，需预排序；逻辑复杂时手写for更清晰易读。
itertools.chain() 比 for 循环拼 list 快多少？
快，但只在“拼接大量可迭代对象”时明显；如果只是两个小 list，手写 + 或 extend() 反而更直接、更易读。
-
itertools.chain()不立即生成新容器，返回的是惰性迭代器——内存友好，但首次遍历时才有开销 - 手写
a + b + c会触发三次内存分配和拷贝，元素越多越慢；itertools.chain(a, b, c)几乎是常数时间构造 - 常见错误：用
list(itertools.chain(...))强制转 list，就抵消了大部分优势——除非你真需要随机访问或多次遍历 - 示例对比：
list(itertools.chain(range(1000), range(1000)))比list(range(1000)) + list(range(1000))快约 2–3 倍（CPython 3.11）
itertools.product() 能不能替代嵌套 for？
能，而且更简洁；但要注意它生成的是元组，不是变量解包，容易在循环体里写错用法。
- 嵌套
for i in a: for j in b:和for i, j in itertools.product(a, b)语义等价，但后者少缩进、逻辑更平铺 - 参数顺序很重要：
itertools.product(a, b)等价于外层a、内层b，和嵌套 for 一致；反着写会改变遍历顺序 - 性能上差别不大，但
product预分配迭代器状态，对超长序列略省栈帧；不过如果a或b是生成器，product会把它吃掉一次——不可重复使用 - 错误现象：
for x in itertools.product([1,2], [3,4]): print(x[0] + x[1])正确；但有人误写成for x, y in itertools.product(...)却忘了product返回的是(x, y)元组，不是两个独立变量
为什么 groupby() 总是只分出单个元素？
因为 itertools.groupby() 只合并「相邻且相等」的项，不是按全局值分组——这是最常踩的坑。
- 输入必须已按 key 排序，否则相同 key 的元素被隔开，就会被切成多组；例如
groupby([1,2,1], key=lambda x:x)产出三组：(1,[1]), (2,[2]), (1,[1]) - 典型修复：先
sorted(data, key=key_func)，再传给groupby；但注意排序本身是 O(n log n)，可能比手写 dict 累加还慢 - 适用场景：处理已排好序的日志流、连续传感器数据、或配合
sorted(..., key=...)一次性完成；别用它替代{k: list(g) for k, g in groupby(...)}这种想当然的写法 - 另一个坑：
g是迭代器，只能消费一次；写list(g)后再想用len(g)就是空的——得先存成 list
什么时候该放弃 itertools，老老实实写 for？
当逻辑里需要提前 break、条件 continue、中间状态累积，或者只跑几次就结束时，itertools 的抽象反而增加理解成本。
立即学习“Python免费学习笔记（深入）”；
-
itertools.takewhile()和dropwhile()看似方便，但一旦条件变复杂（比如“跳过前 N 个，再取直到满足 X”），代码立刻变得难读；不如用普通 for + flag 变量 -
itertools.islice()对大文件或无限迭代器有用，但如果只是for i in range(10):，硬套islice(count(), 10)完全没必要 - 调试困难：链式调用如
chain(filter(...), map(...))出错了，堆栈里看不到中间变量；而手写循环每步都可 print 或断点 - 兼容性提醒：某些旧项目用 PyPy 或 MicroPython，
itertools实现有差异；filter/map在 Python 3 中也返回迭代器，和itertools组合时容易混淆类型
真正影响性能的往往不是 itertools 本身，而是你是否清楚每个函数的求值时机、内存行为和边界条件。写完记得用 timeit 测，别靠直觉猜。
