用set做成员判断因平均o(1)查找远快于list的o(n)，尤其数据超10⁵时；dict适用于需关联值的场景；内存不足时可分片或用bloomfilter。
为什么用 set 而不是 list 做成员判断？
因为 list 的 in 操作是 O(n) 时间复杂度，而 set 是平均 O(1)。当数据量超过 10⁵ 级别时，差距会从毫秒级拉到秒级甚至更久。
常见错误现象：if x in huge_list: 在循环里反复执行，整个脚本卡住或超时。
- 构建
set本身有开销（哈希计算 + 内存），但只发生一次；后续查找几乎无额外成本 -
set不支持重复元素和顺序，如果原始数据含重复项且你只关心“是否存在”，这反而是优势 - 内存占用比
list略高（哈希表需要空闲槽位），但通常可接受；若内存极度敏感，需权衡
dict 什么时候比 set 更合适？
当你不仅需要“是否存在”，还需要“关联什么值”——比如查 ID 得到用户名、查哈希得文件路径。此时 dict 是自然选择，同样具备 O(1) 平均查找性能。
使用场景举例：清洗日志时，用 dict 缓存已处理的请求 ID 及其响应码，避免重复解析。
- 键必须是不可变类型（
str、int、tuple等），不能用list或dict作键 - 如果只需要存在性检查，却用了
{k: True}这类伪字典，纯属浪费内存和可读性 - Python 3.7+ 中
dict保持插入顺序，但别依赖它做“有序集合”——该用collections.OrderedDict或dict+list组合
大数据集初始化时的坑：别在循环里反复调用 add() 或 update()
逐行读大文件并往 set 里塞，写成 my_set.add(line.strip()) 没问题；但若先读完全部再建 set，直接传生成器或列表更高效。
错误示范：s = set(); for x in big_iter: s.add(x) —— 多余的 Python 层循环拖慢速度。
- 推荐写法：
s = set(big_iter)或s = {x for x in big_iter}，让 C 层批量处理 - 如果数据源是文件，用
set(line.rstrip('\n') for line in f)，避免一次性加载全量字符串到内存 - 注意：
set()构造器不接受未解包的嵌套可迭代对象，set([[1,2], [3,4]])会报TypeError: unhashable type: 'list'
内存不够怎么办？考虑分片 set 或用 bloomfilter
当数据量大到单机内存撑不住（比如十亿级字符串），硬建 set 会触发 OOM。这时候得换思路。
简单分片方案：按首字母或哈希前缀把数据拆进多个 set，查询时只查对应分片。虽增加一层判断，但内存可控。
- 例如：
shard_map = {'a': set(), 'b': set(), ...}; key = item[0].lower(); shard_map[key].add(item) - 更稳健的选择是第三方库
bloomfilter（如pybloom_live），支持超大数据集的近似存在判断（有极小误判率，但内存仅 KB~MB 级） -
bloomfilter无法删除元素，也不返回原始值——它只回答“很可能存在”或“绝对不存在”，适合前置过滤场景
set；要“有什么”，就上 dict；真到了内存告急那步，别硬扛，分片或布隆过滤器才是正解。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
