17370845950

是等价的，CPython中list.extend()和+=均调用同一底层C函数list_inplace_concat（即__iadd__），行为一致且原地修改；但仅限CPython，其他实现可能不同，且类型检查逻辑略有差异。

extend() 和 += 在 CPython 中是否等价

在 CPython 解释器下，list.extend() 和 += 对列表操作**底层调用的是同一段 C 代码**，即 list_inplace_concat（对应 list.__iadd__）。这意味着只要右侧操作数是 list 或其他可迭代对象（如 tuple、range），两者行为一致——都是原地扩展，不创建新列表对象。

但注意：这个等价性仅限于 CPython。PyPy、Jython 等实现可能不同；且当右侧不是 list 时，+= 仍走 __iadd__，而 extend() 显式要求可迭代对象，类型检查逻辑略有差异。

传入非 list 类型时的兼容性差异

extend() 接受任意可迭代对象，包括 str、set、生成器等；+= 在 CPython 中也支持，但语义上更“宽松”——它依赖右操作数是否实现了 __iter__，且某些自定义类若只实现 __add__ 而未实现 __iadd__，+= 会退化为 a = a + b（新建列表），而 extend() 仍会报错或按预期迭代。

• lst.extend("abc") → 添加 'a', 'b', 'c' 三个字符
• lst += "abc" → 同样添加三个字符（CPython 下）
• lst += (1, 2) → 正常；lst += {1, 2} → 顺序不确定，但合法
• 若某类 MyIter 有 __iter__ 但没实现 __iadd__，lst += my_iter 可能触发 TypeError 或回退到拷贝加法

性能实测的关键变量

实际性能差异几乎可以忽略，但以下几点会影响测量结果：

• 当右侧是 list 且长度已知时，extend() 和 += 都会预分配内存（调用 l

  

  ist_resize），避免多次 realloc
• 若右侧是生成器或没有 __len__ 的迭代器，extend() 会边迭代边扩容（可能多次 realloc），+= 行为相同
• 使用 timeit 测量时，别忽略名称查找开销：lst.extend 是属性访问，+= 是操作符，后者略快——但差距在纳秒级，无实际意义
• 真正影响性能的是数据规模和内存局部性，而非选哪个方法

容易被忽略的边界行为

最易踩坑的是对不可变对象或错误类型的操作：

• lst += 42 → TypeError: 'int' object is not iterable（和 extend(42) 一样）
• lst.extend([1, 2]) 和 lst += [1, 2] 看似一样，但如果 lst 是子类（如继承自 list 并重写了 __iadd__），两者可能表现不同
• extend() 是普通方法调用，可被 monkey patch；+= 绑定到 __iadd__，patch 后者才生效
• 多线程环境下，两者都不保证原子性——即使底层是同一函数，中间仍可能被中断，需外层加锁

真正该关注的不是选哪个，而是确保右侧对象符合预期类型，并理解「原地修改」带来的副作用——比如传入的列表后续被其他代码修改，会影响你的 extend 结果。