list.extend()和list += [...]行为一致、性能无差别，但底层协议不同：前者调用list_extend并严格检查可迭代性，后者通过__iadd__复用其逻辑但对list/tuple有快速路径；语义上extend更通用，+=更简洁，性能差异可忽略。
![list.extend() 与 list += [...] 在底层实现和性能上的细微区别](https://img.php.cn/upload/article/001/242/473/176889456217787.png)
两者在绝大多数情况下行为一致、性能几乎无差别，但底层实现路径不同，极端场景下有细微差异。
底层调用的协议不同
list.extend() 显式调用列表对象的 extend 方法，内部走的是 CPython 的 list_extend 函数，它会：
- 检查参数是否为可迭代对象
- 预估所需空间（调用 PyObject_Size 尝试获取长度，失败则逐个追加）
- 批量扩容（使用 list_resize，带 over-allocation 策略）
- 逐个拷贝元素引用（不复制对象本身）
list += [...] 触发的是就地加法（__iadd__），CPython 中 list.__iadd__ 的实现**直接复用了 list_extend 的核心逻辑**，但跳过了部分类型检查和迭代器健壮性处理——它假设右操作数是 list 或 tuple（CPython 特化路径），否则回退到通用 extend 流程。
对非列表类型参数的处理略有差异
当右操作数不是 list/tuple 时：
-
lst.extend(it)：支持任意可迭代对象（如range、生成器、集合），只要能iter()就行 -
lst += it：在 CPython 中，若it不是 list/tuple，__iadd__会 fallback 到调用extend，行为等价；但语义上它“期望”序列类型，某些自定义类若只实现了__add__而没实现__iadd__，+=可能退化为lst = lst + it（新建列表），而extend()仍就地修改
性能差异仅在极少数边界情况可见
正常使用中测不出区别，但以下情况可能体现微小差距：
- 对
list += [1,2,3]（小 list），CPython 有针对 tuple/list 的快速路径，比extend([1,2,3])少一次类型判断和迭代器创建开销（纳秒级） - 对生成器或无长度的迭代器（如
(x for x in ...)），extend()会尝试len()失败后逐个追加；+=在 fallback 后行为相同，无优势 - 内存分配策略完全一致：都采用 “当前长度 + 新增长度 + 额外预留（约 12.5%）” 的 over-allocation，避免频繁 realloc
实际编写建议
选哪个主要看可读性和上下文：
- 语义明确用
extend()：比如items.extend(filter(...))或传变量items.extend(more_items) - 简洁写法用
+=：比如nums += [1, 2, 3]或lines += read_lines()（且确定右边是 list/tuple） - 不要为性能在这两者间切换——瓶颈从来不在这里；若真卡在 append/extend，应考虑批量构造新列表或用
itertools.chain延迟拼接
