union() 和 | 功能完全等价，均返回新集合且不修改原集合；区别仅在语法：前者是方法调用，支持任意可迭代对象，后者是运算符，仅接受set类型。
union() 和 | 本质一样，但调用方式不同
两者都返回新集合，不修改原集合，结果完全等价。区别只在语法：一个是方法调用，一个是中缀运算符。set1.union(set2) 和 set1 | set2 在行为、性能、兼容性上没差别，Python 内部都是走同一个 C 实现路径。
常见错误是误以为 | 能链式写成 a | b | c 就一定比 a.union(b, c) 快——其实 Python 对多操作数的 | 也会转成等价的 union() 调用，没额外优化。
-
union()支持传入任意可迭代对象（如list、tuple、dict的键），|只接受set类型，否则报TypeError: unsupported operand type(s) - 想合并
set和list？必须用union()：s.union([1, 2, 3])，不能写s | [1, 2, 3] - 多个集合合并时，
union()更直白：a.union(b, c, d)比a | b | c | d少敲两个字符，也少一层括号嵌套风险
去重不是“功能”，而是集合的底层约束
别把并集当成“去重工具”来用。集合的去重发生在构造阶段，不是 union 或 | 的副作用。比如 {1, 1, 2} | {2, 3} 得到 {1, 2, 3}，不是因为 | 去了重，而是因为 {1, 1, 2} 本身在创建时就压缩成了 {1, 2}。
容易踩的坑：拿列表去“假装”集合再求并集，比如 list(set(a) | set(b))。这看似去重合并，但丢失了原始顺序，且如果元素不可哈希（如字典、列表），会直接报 TypeError: unhashable type。
立即学习“Python免费学习笔记（深入）”；
- 需要保留顺序 + 去重 + 合并？别硬套集合，改用
dict.fromkeys()：list(dict.fromkeys(a + b)) - 含不可哈希元素？先序列化或用 frozenset 包装，但要注意语义是否还成立
-
union()对重复传入同一集合无害，s.union(s, s)和s完全相等，不用提前 dedup 参数
性能差异只在极端场景下才可见
日常代码里，union() 和 | 的耗时差异在纳秒级，远小于一次函数调用开销。真正影响性能的是集合大小和元素哈希复杂度，不是语法选择。
但有一个真实瓶颈：当其中一个集合极大（比如百万级），另一个极小（比如个位数），用 small_set.union(large_set) 比 large_set | small_set 略慢——因为 union() 默认以第一个参数为基底扩容，而 | 运算符会自动选较大的集合做主容器。不过这个优化只在 CPython 3.9+ 生效，旧版本无此逻辑。
- 明确知道大小关系？优先让大集合在左边：
big | small或big.union(small) - 不确定大小？别微操，用
|更省心，它内部做了 size 判断 - 频繁合并？避免反复构造新集合，考虑用
update()原地合并（但注意这是破坏性操作）
别忽略 None、NaN、自定义对象的哈希陷阱
并集去重依赖 __hash__ 和 __eq__。常见翻车点：浮点 NaN 不等于自身，导致 {float('nan')} | {float('nan')} 结果是 {nan, nan}（实际显示为两个 NaN，但集合长度为 2）；None 没问题，它哈希稳定；自定义类若没实现 __hash__，直接进不了集合。
还有更隐蔽的：不同模块里定义的同名类，即使结构一致，实例也不等价。比如 from a import X 和 from b import X 的两个 X()，哪怕内容相同，set([x1]) | set([x2]) 也会得到两个元素。
- 处理
NaN？先用pandas.isna()或math.isnan()预清洗，或统一替换成字符串'nan' - 跨模块对象要等价？确保它们来自同一类定义，或显式覆盖
__eq__和__hash__ - 不确定元素是否可哈希？先试
hash(x)，别等union()报错才排查
