应优先用 set 而非 list 进行百万级 in 检查，因 list 为 O(n) 线性扫描，而 set 基于哈希表均摊 O(1)，但需注意初始化方式、内存占用、数据类型一致性及哈希冲突等边界问题。
直接用 set 就行，但得小心初始化方式、内存占用和数据类型一致性——否则看似 O(1) 的 in 检查会悄悄退化或爆内存。
为什么不能直接用 list 做百万级 in 检查
Python 中 list 的 in 是线性扫描，平均时间复杂度 O(n)。对 100 万条数据做 1 万次检查，最坏可能触发 10¹⁰ 次比较，实际运行可能卡住十几秒甚至更久。而 set 底层是哈希表，理想情况下每次 in 只需一次哈希 + 一次地址比对。
但注意：这个“理想情况”依赖两个前提——哈希函数分布均匀、没有大量哈希冲突。Python 的 set 对 int、str 等内置类型做了高度优化，基本满足；但自定义类若没重写 __hash__ 和 __eq__，就不能放进 set。
构建百万级 set 的实操要点
别用循环 .add() 逐个塞，也别用 set(list_data) 把大列表先全读进内存再转——这两者都容易触发临时内存峰值翻倍。推荐一步到位：
立即学习“Python免费学习笔记（深入）”；
- 从文件流式读取时，用生成器表达式：
valid_ids = set(int(line.strip()) for line in f) - 如果数据已在 Pandas
Series中，优先用set(series.array)而非set(series.tolist())，避免中间生成大 list - 确认元素可哈希：
type(x)是str、int、tuple（且内部全可哈希）才行；list、dict、set本身不可哈希，会报TypeError: unhashable type - 字符串注意前后空格和大小写：
"123 "和"123"是两个不同 key，建议预处理统一strip().lower()
set 查找真的总是 O(1) 吗？这些边界情况会拖慢你
理论均摊 O(1)，但实际中以下情况会让单次 in 明显变慢：
- 集合过大导致 CPU 缓存失效：比如 500 万字符串，每个平均 20 字节，光哈希表本身就要上百 MB，反复随机访问容易 cache miss
- 哈希碰撞严重：所有 key 哈希值都落在同一槽位（极少见，除非自己造了坏的
__hash__），退化成链表遍历 - Python GIL 下多线程并发读
set安全，但若同时有另一个线程在.add()或.discard()，仍可能触发哈希表 resize，短暂阻塞所有读操作 - 检查不存在的 key 比存在的 key 略慢一点——因为要确认整个槽位链表/探查序列都没匹配项
简单验证当前性能：用 timeit.timeit(lambda: "xxx" in my_set, number=100000) 测千次查找耗时，稳定在 1–3ms 内算正常；超过 10ms 就该怀疑数据或环境问题。
内存比速度更容易成为瓶颈
一个含 100 万个 int 的 set，实际内存占用约 8–12 MB；同数量级的 str（平均长度 15）则轻松突破 50 MB。用 sys.getsizeof(my_set) 只返回容器开销，不包括元素本身——真实内存得用 pympler.asizeof.asizeof(my_set)。
如果只是做一次性批量检查，且原始数据支持顺序访问，可以考虑分块：把大 set 拆成多个 10 万级子集，查完立刻 del；或者改用 bisect + 排序后 list（O(log n) 但内存省 60%+），尤其适合只读、数据稳定场景。
真正棘手的不是“能不能快”，而是“快的时候内存吃不吃得消，以及你是否意识到字符串编码、None 值、浮点精度这些隐性 key 差异正在悄悄让你的 in 返回 False。
