list.append() 有时变慢是因为扩容需 realloc 内存并复制元素；cpython 采用约1.125的增长因子（newsize = (size >> 3) + size + 6），导致偶发 o(n) 时间开销。
Python 列表不是“可变数组”的简单模仿，它的底层是动态数组（dynamic array），但附带引用计数、对象缓存、预分配策略等 CPython 特有机制——这意味着 append 平均 O(1)，但单次可能触发 realloc；pop() 末尾快，pop(0) 却是 O(n)。
为什么 list.append() 有时突然变慢？
CPython 在列表扩容时采用“增长因子约 1.125”的策略（具体为 newsize = (size >> 3) + (size ），并非每次翻倍。当列表从 65535 扩容到 65544 时，可能触发内存重分配+逐个拷贝指针，造成可观测延迟。
实操建议：
- 若已知最终长度（如解析固定行数 CSV），用
[None] * n预分配，再按索引赋值 - 避免在循环中反复
append同一列表（如result.append(item); result.append(item)），改用extend([item, item])或直接+= [item, item] - 监控扩容点：用
sys.getsizeof(my_list)观察内存跳变
del my_list[i] 和 my_list.pop(i) 的行为差异
两者都移除索引 i 处元素，但 pop() 返回被删值，del 不返回（返回 None）。更重要的是：它们都需将索引 i+1 到末尾的所有指针前移一位 —— 时间复杂度均为 O(n)。
立即学习“Python免费学习笔记（深入）”；
常见错误现象：
- 在 for 循环中边遍历边
del或pop(i)，导致漏删或IndexError - 误以为
del my_list[:]比my_list.clear()更快 —— 实际上后者是 C 层直接重置长度字段，更快更明确
正确做法：
- 逆序删除：
for i in range(len(lst)-1, -1, -1): if condition: del lst[i] - 构建新列表：
lst = [x for x in lst if not should_remove(x)]
列表推导式 vs map() + list()：不只是语法糖
列表推导式在 CPython 中由专门的字节码 LIST_APPEND 支持，而 map() 返回迭代器，list(map(...)) 需额外函数调用开销和对象创建步骤。
性能与可读性权衡：
- 纯函数映射（如
str.upper）且无条件过滤时，map()内存更省（但转成 list 就没了优势） - 含
if过滤或表达式复杂时，列表推导式更直观，且解释器优化更好 -
map()在 Python 3 中返回惰性迭代器，若你只取前 N 项，它比列表推导式省时间
words = ['hello', 'world'] # 推荐：清晰、高效 upper_words = [w.upper() for w in words] <h1>仅当你确定后续只遍历一次且可能提前中断时才考虑</h1><p>upper_iter = map(str.upper, words)</p>
嵌套列表的浅拷贝陷阱
new_list = old_list.copy() 或 new_list = old_list[:] 只复制最外层引用，内层子列表仍共享。修改 new_list[0].append(99) 会同时影响 old_list[0]。
解决路径：
- 确认是否真需要深拷贝 —— 大多数场景只需避免意外修改，用
[x[:] for x in nested]（一层深拷贝）已足够 - 真正多层嵌套且结构不确定时，才用
import copy; copy.deepcopy()，但注意其性能开销和循环引用风险 - 更健壮的做法：用不可变容器替代，如
tuple存子序列，或改用dataclass(frozen=True)封装
容易被忽略的地方是：列表作为字典键会报错（因可变），但很多人没意识到，把列表放进另一个列表后，依然无法哈希 —— 它的可变性不会因为“被包了一层”就消失。
