deque在频繁头部插入时性能优于list：list.insert(0, x)为O(n)，deque.appendleft()为O(1)；但deque不支持切片且随机访问慢2–3倍。
list 和 deque 在频繁头部插入时的性能差异
用 list 做 insert(0, x) 是 O(n) 操作，每次都要移动后面所有元素；而 deque 的 appendleft() 是 O(1)，底层用双向链表实现。如果你在写解析器、队列缓冲或日志前缀追加逻辑，这点差异会随数据量放大成明显卡顿。
- 常见错误现象：
list.insert(0, x)在循环里调用上千次后，耗时突然从几毫秒跳到几百毫秒 - 适用场景：需要持续在开头加元素（如滑动窗口头部更新、命令历史记录）
- 注意
deque不支持切片（d[1:5]报TypeError），随机访问也比list慢 2–3 倍 - 小数据量（
dict vs. defaultdict 处理缺失键的开销
defaultdict 并不“更快”，它只是把键不存在时的默认值构造逻辑提前绑定在类型上；而普通 dict 用 get(key, default) 或 setdefault() 是按需触发。两者在键存在时性能几乎一致，但误用 defaultdict 可能导致意外初始化——比如传入 list 后，哪怕只查一次不存在的键，也会悄悄新建一个空列表。
- 常见错误现象：统计词频时用
defaultdict(list)，结果发现每个没出现过的单词都占了一个空列表内存 - 正确做法：计数用
defaultdict(int)，分组用defaultdict(list)，但要确保你真需要“自动创建”行为 -
dict.setdefault(key, [])更可控——只在键不存在时才新建，且你能看到这个动作发生在哪一行
tuple 作为字典键时的不可变性陷阱
只要 tuple 里所有元素都是不可变的（比如 (1, "a", (2, 3))），它就能当 dict 键；但一旦含可变对象（比如 [1, 2] 或另一个 dict），就会报 TypeError: unhashable type。这不是语法错误，是运行时才暴露的问题，容易在动态构造 key 时漏检。
- 常见错误现象：用
tuple(data_list)当 key，但data_list里混了 list 或 dict，程序跑一半崩在dict[key] = value - 调试技巧：打印
type(x)和hash(x)（成功返回整数，失败抛异常）快速验证 - 替代方案：如果必须用动态结构作 key，先用
json.dumps(obj, sort_keys=True)转成字符串（注意浮点精度和 NaN 处理）
set 查找比 list 快，但初始化成本更高
in 操作在 set 是平均 O(1)，在 list 是 O(n)；但把一个大 list 转成 set 要 O(n) 时间 + 额外内存。如果你只查一次，转 set 反而更慢；查十次以上，通常就回本了。
立即学习“Python免费学习笔记（深入）”；
- 常见错误现象：函数开头写
valid_ids = set(id_list)，但整个函数只用了一次if x in valid_ids - 使用场景：高频成员判断（如过滤、去重、权限校验），且数据集稳定或复用多次
- 注意
frozenset适合当字典键或放进其他 set，但不能增删——别试图对它调add()
实际写代码时，最常被忽略的是「数据规模预期」：本地测 100 条很快，上线后面对 10 万条日志或百万级用户 ID，list.index() 和 set.__contains__() 的差距就不是“快一点”，而是“能不能响应”。