是等价的，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或回退到拷贝加法
性能实测的关键变量
实际性能差异几乎可以忽略，但以下几点会影响测量结果：
立即学习“Python免费学习笔记（深入）”；
- 当右侧是
list且长度已知时，extend()和+=都会预分配内存（调用list_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 结果。
