17370845950

Python set 能去重是因为底层基于哈希表：元素插入前计算 hash() 值并映射到桶，相同值必有相同哈希值，重复插入时检测到等价元素即跳过；仅可哈希类型（如 tuple、frozenset）可加入，list/dict 不行。

Python set 为什么能去重？底层是哈希表

Python set 去重不是靠遍历比对，而是依赖哈希（hash）机制：每个元素被插入前先计算 hash() 值，映射到内部哈希表的某个桶（bucket）。相同值的对象必然有相同哈希值（且满足 a == b → hash(a) == hash(b)），因此第二次插入时会发现桶中已有等价元素，直接跳过。

注意：只有可哈希类型才能放进 set —— 比如 list、dict 会报 TypeError: unhashable type；而 tuple（不含不可哈希项）可以。

• 自定义类若想进 set，必须正确定义 __hash__ 和 __eq__
• 哈希冲突存在，但 CPython 用开放寻址法处理，不影响正确性
• None、数值、字符串、frozenset 等内置类型都已实现合理哈希

list(set(...)) 去重会丢失原始顺序，怎么办？

Python 3.7+ 的 dict 保持插入顺序，这个特性可被借用来保序去重：

list(dict.fromkeys(items))

它比 list(set(items)) 多一次哈希计算（key 插入 dict），但避免了排序或额外索引查找。如果 items 是生成器或大列表，这种写法也更省内存——dict.fromkeys 不会提前展开整个迭代器。

• 不要用 sorted(set(...)) 除非你真需要排序后结果
• 若需稳定去重 + 条件过滤，用 seen = set(); [x for x in items if not (x in seen or seen.add(x))]（注意 add() 返回 None）
• 第三方库如 more-itertools.unique_everseen 更语义清晰，但引入依赖

大数据量下 set 去重比 list.count 或 in 慢？不，恰恰相反

对长度为 N 的列表，用 for x in lst: if x not in seen: seen.append(x) 这种方式，每次 in 是 O(N) 列表扫描，总时间复杂度是 O(N²)；而 set 的 in 平均是 O(1)，总开销接近 O(N)。

实测：10 万整数去重，set 耗时约 8ms，纯列表模拟耗时超 2s（CPython 3.11，Mac M2）。

• 小数据（set
• 内存上 set 占用略高（哈希表有空桶、存储哈希值），但通常可接受
• 如果元素本身很大（如长字符串、大元组），哈希计算开销会上升，但仍是目前最通用的平衡解

嵌套结构去重只能靠 frozenset 或 tuple 化？

想对 list 列表去重？不行，因为 list 不可哈希。常见做法是转成 tuple（如果元素可哈希）：

list(set(tuple(x) for x in list_of_lists))

但如果内层含字典或集合，就得进一步转换，比如用 json.dumps(x, sort_keys=True) 生成唯一字符串再哈希——但这引入序列化开销和浮点精度、NaN 等边界问题。

• frozenset 可用于去重无序集合（如 [{1,2}, {2,1}] → 一个结果），但会丢失顺序和重复元素信息
• 真正复杂的嵌套结构（含函数、对象引用等），set 无能

  

  为力，得用自定义缓存逻辑或 id()（仅限临时内存去重）
• 别忘了深拷贝风险：转 tuple 是浅转换，原列表内嵌套可变对象仍共享引用

实际用 set 去重时，最易忽略的是「可哈希性」前提和「顺序丢失」副作用；一旦涉及嵌套或自定义类型，哈希逻辑就得手动接管，这时候就不是一行 set() 能解决的事了。