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)。

常见错误现象：

• 在 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]
仅当你确定后续只遍历一次且可能提前中断时才考虑
upper_iter = map(str.upper, words)

嵌套列表的浅拷贝陷阱

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) 封装

容易被忽略的地方是：列表作为字典键会报错（因可变），但很多人没意识到，把列表放进另一个列表后，依然无法哈希 —— 它的可变性不会因为“被包了一层”就消失。