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 不会提前展开整个迭代器。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 不要用
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() 能解决的事了。 
