17370845950

list.extend()和list += [...]行为一致、性能无差别，但底层协议不同：前者调用list_extend并严格检查可迭代性，后者通过__iadd__复用其逻辑但对list/tuple有快速路径；语义上extend更通用，+=更简洁，性能差异可忽略。

两者在绝大多数情况下行为一致、性能几乎无差别，但底层实现路径不同，极端场景下有细微差异。

底层调用的协议不同

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 延迟拼接