该用 itertools.chain 时：面对上百个长列表且仅一次遍历；它返回延迟拼接的迭代器，省内存；但不可索引，需 list() 转换才能随机访问；多次遍历时反而更慢；chain.from_iterable 更适合“列表的列表”输入。
用 itertools.chain 合并多个列表更省内存，但若只是合并两三个小列表，+ 更直觉、更安全。
什么时候该用 itertools.chain？
当你面对的是大量列表（比如上百个）、每个列表又很长，且后续只做一次遍历（如传给 sum()、list() 或 for 循环），itertools.chain 就值得上——它不立刻生成新列表，而是返回一个迭代器，延迟拼接。
- 常见错误现象：
chain(a, b, c)返回的是itertools.chain对象，不是list；直接打印或索引会报TypeError: 'itertools.chain' object is not subscriptable - 必须显式转成
list才能随机访问：list(chain(a, b, c)) - 如果后续还要多次遍历，
chain反而慢：迭代器只能用一次，重复使用得重新调用chain - 兼容性没问题，
itertools是 Python 标准库，3.6+ 行为一致
为什么 + 运算符有时反而更稳妥？
+ 对 list 是就地拼接并返回新列表，语义清晰、行为确定，适合多数日常场景。
- 容易踩的坑：
+要求所有操作数都是list；混入tuple或range会直接报TypeError: can only concatenate list (not "tuple") to list - 性能上，
a + b + c会产生中间列表（比如先算a + b得临时列表，再加c），对超大列表有内存压力 - 但如果你只合并 2~3 个几百项以内的列表，这种开销几乎不可测，可读性远胜
chain - 注意：不要在循环里反复用
+=拼列表（如result += item），那等价于多次extend，但语法误导性强；改用.extend()或预分配更明确
itertools.chain.from_iterable 是什么？和普通 chain 有什么区别？
当你手头是一个“列表的列表”，比如 lists = [[1,2], [3,4], [5]]，而不是单独的变量 a, b, c，这时 chain.from_iterable(lists) 比 chain(*lists) 更合适。
-
chain(*lists)依赖解包，如果lists非常长（比如上万个子列表），可能触发RecursionError或参数过多异常 -
chain.from_iterable(lists)不解包，逐个迭代内部可迭代对象，更健壮 - 两者返回类型和行为完全一致，只是输入接口不同
- 示例：
list(chain.from_iterable([[1,2], [3], [4,5,6]]))→[1, 2, 3, 4, 5, 6]
真正需要权衡的不是“优雅与否”，而是“你要不要那个中间列表”。如果之后要索引、切片、反复用，老老实实用 + 或 sum(lists, [])；如果只是喂给一个 for 循环或一次性函数，chain 省内存也省事。别为了“看起来高级”而绕弯——Python 里最不优雅的事，就是把简单问题配出复杂解法。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
