应先用 sys.getsizeof() 估算集合内存占用再调用 set.intersection()，否则易 OOM；若超内存则改用分块处理、排序+双指针或 numpy 替代方案。
用 set.intersection() 处理超大集合前先确认内存是否撑得住
直接调用 set.intersection() 看似最自然，但若两个集合都超 1 亿元素且元素是字符串或自定义对象，Python 的 set 会吃掉数 GB 内存——不是慢，是直接 OOM。关键不是算法复杂度，是底层哈希表的内存开销。实操中应先用 sys.getsizeof() 估算单个集合大小（注意：这只是浅层大小，实际占用可能翻倍），再对比可用 RAM。
常见错误现象：MemoryError 出现在 set(...) 构造阶段，而非交集计算时；或者系统开始疯狂 swap，top 显示 Python 进程 RSS 持续飙升。
- 如果任一集合无法全量载入内存，必须放弃纯内存方案，转向流式或磁盘辅助
- 若元素是短字符串（如 UUID、数字字符串），可考虑用
array.array('Q')或numpy.uint64替代set存整数哈希值（需自行处理哈希冲突） - 避免把文件逐行读入再
set()—— 改用生成器 + 分块处理，例如每次读 100 万行、计算局部交集、再合并结果
用 sorted list + 双指针替代 set 降低内存峰值
当两个集合可排序且总元素量极大（比如各 5 亿）、但交集结果稀疏（预期只占 0.1%），用排序后双指针比哈希集合更省内存——因为不需要存储哈希桶和空槽位。前提是数据源支持顺序读取或能一次性排序落盘。
使用场景：日志 ID 对比、数据库主键同步、离线 ETL 中的去重关联。
立即学习“Python免费学习笔记（深入）”；
- 排序本身有成本：用
sorted()会复制全部数据；推荐用unix sort命令预处理文件，再用 Python 流式读取两个已排序文件 - 双指针代码极简：
while i - 注意字符串比较开销：若元素是长文本，先转成
hashlib.sha256().hexdigest()再排序，但需处理哈希碰撞（加原始值二次校验）
用 pyroaring 的 RoaringBitmap 加速整数集合交集
如果你的“集合”本质是正整数（如用户 ID、商品 SKU 编号），且范围集中在 0–2³² 内，pyroaring 是目前 Python 生态里交集性能最强、内存最省的方案。它比原生 set 快 3–10 倍，内存占用常不到 1/5。
性能影响：构建 Bitmap 比构建 set 略慢（因需分桶压缩），但 .intersection() 是毫秒级，且支持延迟计算（& 操作符返回新 bitmap，不立即分配内存）。
- 安装：
pip install pyroaring；注意 Windows 用户需提前装 Visual Studio Build Tools - 不能直接传字符串或负数：必须先映射为非负整数（例如用
int(hashlib.md5(s.encode()).hexdigest()[:8], 16) & 0x7FFFFFFF） - 交集结果仍是
RoaringBitmap，要转 Pythonlist得调用.to_list()——这步会触发全量解压，慎用；建议直接迭代或转成numpy.array
避免踩 set.intersection(*others) 的隐式拷贝坑
写 A.intersection(B, C, D) 看起来方便，但 CPython 实现中，它会以 A 为基准，逐个对 B、C、D 做哈希查找——这没问题；但如果你误写成 A.intersection([B, C, D])（传了列表），就会触发完全不同的逻辑：把整个列表当做一个元素去查，结果永远为空，且不报错。
另一个隐蔽问题：当 B 比 A 小得多时，手动交换顺序为 B.intersection(A) 能显著减少哈希查找次数（因为内层循环在较小集合上）。CPython 不会自动优化这个。
- 永远检查参数类型：
isinstance(other, abc.Set)，别依赖文档说“接受任意可迭代对象” - 对多个集合求交，优先用
functools.reduce(set.intersection, [A, B, C])，并确保第一个集合是最小的那个 - 如果集合来自不同来源（如一个从 DB fetch，一个从文件读），别在交集前统一转
set——保留生成器，用any(x in big_set for x in small_iter)做存在性判断更省内存
