set交集比in循环快，根本原因是set的&运算基于哈希表，平均O(min(m,n))；而list/tuple的in每次O(n)，嵌套成O(m×n)。必须两边都是set才触发C层哈希优化，否则回退慢路径。
为什么 set 交集比 in 循环快？
根本原因是底层实现差异：set 的 & 运算基于哈希表，平均时间复杂度 O(min(len(a), len(b)))；而循环中对 list 或 tuple 做 in 判断，每次都是 O(n) 线性扫描，嵌套下来容易变成 O(m×n)。
比如判断 1 万个元素是否在另一个含 5 万个元素的容器里：用 list 的 in 平均要查 2.5 亿次；换成 set 后，哈希查找单次接近 O(1)，总开销压到几万次量级。
必须把待查容器转成 set 才有效
常见误区是只把一个操作数转为 set，另一个还留着是 list 或 tuple，结果调用的仍是慢路径。Python 的 & 是对称运算，但只有两边都是 set 实例时，才触发 C 层优化的哈希交集算法。
- ✅ 正确：
set_a & set_b（两者都是set） - ❌ 无效：
set_a & list_b会触发list.__and__，通常返回NotImplemented，再回退到慢速循环模拟 - ⚠️ 隐患：
set_a & some_iterable中some_iterable若不是set，可能被强制转成set再计算——这步本身就有开销，且不可控
实际写法：别手写循环，优先用 set 操作
遇到“找出两个集合共有的元素”这类需求，直接用 &，别下意识写 for x in a: if x in b: ...。哪怕 b 原本是 list，也应提前转一次 set 复用：
立即学习“Python免费学习笔记（深入）”；
# 慢：每次循环都线性扫 list_b common = [x for x in list_a if x in list_b]快：转一次，后面所有查找都摊薄成本
set_b = set(list_b) common = list(set_a & set_b) # 或直接用 set_a & set_b
注意：如果 list_b 只用一次，且长度小（set 的初始化开销可能反超；但只要复用 ≥2 次，或长度 >1k，几乎一定更快。
小心 set 的限制和隐式开销
set 要求元素可哈希，遇到 dict、list 这类不可哈希类型会直接报 TypeError: unhashable type；另外，set 会去重、无序，若业务依赖顺序或允许重复，不能直接替代。
- 不可哈希？先用
tuple包装list元素，或改用frozenset存嵌套结构 - 需要保持顺序？用
dict.fromkeys(...).keys()模拟有序去重，再做交集逻辑 - 内存敏感？
set比同尺寸list占更多内存（哈希表负载因子 + 指针开销），大数据量需权衡
真正快的前提是：数据适合哈希、你愿意为速度牺牲一点点内存和约束条件。
