Python集合运算符与方法的区别：何时用 | 何时用 union

一、语法机制与类型约束：严格校验与通用迭代

理解二者差异的首要切入点是 Python 对运算符重载与面向对象方法的不同设计考量。运算符 | 在底层调用集合类型的 __or__ 和 __ror__ 魔术方法，Python 核心规范要求二元位运算符的操作数必须具备明确对等的类型支持。对于内置集合而言，其右操作数必须是集合实例（set 或 frozenset）。

与此相对，union() 方法的签名形式为 set.union(*others)。它属于多态方法，其参数可以是任何实现了迭代器协议的对象，包括 list、tuple、dict（默认迭代键）、range、生成器以及自定义的生成式。

base_set = {1, 2}
extra_list = [2, 3]

# 1. 尝试使用 | 运算符连接集合与列表
try:
    result_op = base_set | extra_list
except TypeError as err:
    print(f"运算符执行失败: {err}")

# 2. 使用 union() 方法合并列表
result_method = base_set.union(extra_list)
print(f"union 方法执行成功: {result_method}")

# 3. union() 同时传入多个不同类型的可迭代对象
multi_result = base_set.union((3, 4), range(4, 7), {"a": 1, "b": 2})
print(f"多源合并结果: {multi_result}")

从上述输出可以直观看出：当代码中存在列表等外部类型时，| 运算符会立即报错中断，而 union() 则平滑兼容各类可迭代对象。此外，union() 允许在单次调用中传入任意数量的参数，按从左到右的顺序逐一消费合并；而 | 是二元运算符，合并多个集合必须连续串联（例如 s1 | s2 | s3）。

二、执行路径与内存开销：混合数据合并的底层过程

在实际业务开发中，开发者经常需要将已有的 set 与一个未转换为集合的列表（例如来自数据库查询、JSON 解析或文件读取的数据列表）进行并集计算。为了让运算符 | 正常工作，常见的写法是先用 set() 构造函数将列表包装起来：

# 做法 A：先手动转换再使用运算符
final_set_a = active_users | set(new_user_ids)

# 做法 B：直接使用 union 方法
final_set_b = active_users.union(new_user_ids)

虽然这两种写法的最终集合元素完全一致，但二者在 CPython 运行时的执行路径与内存分配机制存在明显差别。

1. 手动转换运算符路径的执行步骤

执行 active_users | set(new_user_ids) 时，Python 必须经历以下四个阶段：

1. 分配临时集合：系统首先为 set(new_user_ids) 在堆内存中开辟一个全新的哈希表结构。
2. 逐项计算哈希并填充：遍历 new_user_ids，计算每个元素的哈希值，处理碰撞并完成哈希表初始化。若数据量较大，中间集合可能触发多次扩容与重新散列。
3. 执行集合并集运算：进入 set_or C 底层函数，创建最终结果集合，并将左操作数与中间临时集合的元素合并进入最终集合。
4. 垃圾回收销毁中间对象：中间临时集合的引用计数归零，等待内存回收释放。

2. union 方法的执行步骤

执行 active_users.union(new_user_ids) 时，底层 C 函数 set_union 采取了流水线式的直接合并策略：

1. 复制基础集合：以 active_users 为模版浅拷贝生成最终结果集合，直接复用已有的哈希表容量与结构。
2. 直接流水线迭代：调用内部的 set_update_internal 函数，直接对外部的 new_user_ids 进行一次单遍线性迭代遍历，将提取出的元素直接插入到结果集合中。
3. 返回结果：完成单遍遍历后直接返回结果集合，整个过程不创建任何中间集合对象。

在小型列表场景下，两者的纳秒级开销可以忽略不计；但当外部数据达到数万乃至数百万项时，set(new_user_ids) 会在短时间内产生显著的内存峰值并增加 GC 压力。因此，在处理非集合类型输入时，.union() 是更优的工程实践。

三、常见认知辨析：union 仅仅是 | 的函数别名吗？

在初学者甚至部分中级开发者中，存在一种常见的直觉：“s.union(t) 只是 s | t 的面向对象语法糖（或别名）”。这种说法之所以容易让人产生认同感，是因为在满足“操作数全部已经是 set 类型”这一特定条件时，两者的行为表现确实高度重合：

• 返回完全相同的新集合对象，原集合均不会被就地修改。
• 时间复杂度均为 O(len(s) + len(t))。
• 在已有两个 set 对象时，两者均直接调用 C 语言级别的底层循环，性能差异微乎其微。

然而，将这种特定条件下的等效性推广为“两者本质一样”是片面的，会导致以下两处容易忽视的代码隐患：

1. 隐藏的类型约束差异

假设一个函数原本接收集合参数并使用 s.union(data)，上游调用方传入列表时代码一直正常运转。如果后续开发者出于追求语法简练，将代码重构为 s | data，就会在运行时直接引爆 TypeError。

2. 就地更新操作的混淆：|= 与 update() 的不对称性

另一个极其常见的混淆点发生在原地修改（In-place update）的场景中。很多开发者熟悉 s.update(iterable) 可以接收列表，于是理所当然地推测增强赋值运算符 s |= iterable 也能接收列表。

tags = {"python", "backend"}
new_tags = ["performance", "memory"]

# 1. 尝试使用 |= 运算符就地更新列表
try:
    tags |= new_tags
except TypeError as err:
    print(f"|= 运算失败: {err}")

# 2. 正确做法：使用 update() 方法
tags.update(new_tags)
print(f"update() 成功更新: {tags}")

四、场景选型指南：何时用 |，何时用 union

根据上述机制差异与性能特征，在实际工程编码中可以按照以下明确依据进行选型：

适合优先使用运算符 | 的场景

• 纯集合间的数学表达式与逻辑推导：当业务概念本身就是严格的数学集合（如权限系统的角色权限位、多标签交叉筛选、集合论交并补组合运算）时，使用 allowed_roles | direct_permissions 具有极高的可读性，与数学符号保持一致。
• 防御性编程与类型断言：如果你期望下游传入的数据“必须是已经完成去重和规范化的集合”，使用 | 运算符可以在脏数据（如意外传入未处理的列表）混入时立即抛出异常，防止潜在的隐式逻辑错误延后暴露。
• 固定数量已知集合的高效串联：例如 s1 | s2 | s3，在静态变量场景下，运算符的视觉连续性优于嵌套的方法调用。

适合优先使用 union() 方法的场景

• 异构数据源聚合与数据清洗：待合并的数据来自 ORM 查询集、生成器表达式、第三方 API 解析的元组列表等。直接使用 target_set.union(raw_records) 免除了冗余的 set() 转换与中间开销。
• 动态集合列表或参数解包：当你拥有一个集合列表 list_of_sets（例如包含数十个动态生成的集合）时，直接编写 set().union(*list_of_sets) 可以在单次底层调用中完成聚合，完全避免了使用 functools.reduce(operator.or_, list_of_sets) 所带来的反复二元迭代损耗。
• 与面向对象方法链（Method Chaining）风格协同：在注重链式调用或流式处理的数据处理管道中，s.union(other).intersection(filter_set) 风格比运算符与括号嵌套更为统一。

五、特性速查与总结

为了方便在日常开发中快速回顾与代码审查，下表梳理了两种方式的关键属性比对：