C#如何使用HashSet求差集_C# ExceptWith高效数据过滤【性能】

先看一段性能数据对比：ExceptWith() 比手写 foreach + Contains() 快 2–3 倍。这不是偶然，而是哈希表底层批量操作的必然结果。

背后的逻辑其实是，ExceptWith() 并没有傻到“一个个遍历再一个个查找”。它的做法是将两个哈希表的桶结构对齐，然后做一次批量剔除——跳过那些哈希码不匹配的桶，只对命中桶里的链表头几个节点进行比对（冲突少的时候基本也就是 O(1)）。这样一来，每次 Contains() 都要重复的哈希计算、桶定位和链表遍历，在 ExceptWith() 内部全都合并成了一轮高效扫描。

换到手动循环的场景：哪怕你的 alreadyProcessed 也是 HashSet，foreach 遍历 exampleSet 的每一个元素时，还是要单独调用一次 Contains()。每一次调用都是一条完整的查找路径，开销自然就叠加起来了。

而 ExceptWith() 内部做了三件事：复用目标集合（比如 alreadyProcessed）已有的哈希分布，不做重复计算；按桶并行扫描（.NET 6+ 默认开启，能减少 cache miss）；最后直接修改原集合的内部数组引用，不新建对象。这几个优化叠加在一起，性能自然就上去了。

ExceptWith() 的参数类型和常见误用

它接收 IEnumerable，但一个很容易踩的坑是：传入非 HashSet 时，性能会“断崖式”下跌。因为这时候无法利用哈希结构加速，直接就退化成 O(n×m) 了。

正确的做法其实很简单：

• 确保传入的是 HashSet，或者至少是 Dictionary（它的 KeySet 本质也是哈希结构）。
• 千万避免传 List、Array 或者 LINQ 查询结果（比如 Where(...).ToList()），这些会触发逐项的 Contains() 回退逻辑。
• 如果手头只有 IEnumerable 源，别偷懒，先显式构造一个 new HashSet(source)，这一步能省回后面几十倍的性能损失。

举个反面例子：set.ExceptWith(dbResults.Where(x => x.IsActive))。这里的 Where 返回的是一个延迟执行的迭代器，ExceptWith 会在内部反复枚举它，性能极差，基本等于在火上浇油。

不想改原集合？别用 ExceptWith()，改用 LINQ

一个常被忽略的区别：ExceptWith() 是就地修改，返回 void；而 Enumerable.Except() 返回新的 IEnumerable，原集合完全不受影响。

• set1.ExceptWith(set2) 的结果是：set1 被清空掉所有在 set2 中存在的元素。
• set1.Except(set2) 则返回一个新序列，set1 和 set2 内容保持不变。

另外，两者用的相等比较逻辑也不一样。ExceptWith() 用的是集合构造时指定的 IEqualityComparer（或者默认的），而 Except() 可以额外传一个参数来覆盖比较器，灵活性更高，但相应地会多一次委托调用开销。

自定义类型必须重写 GetHashCode() 和 Equals()

差集结果错乱，十有八九是引用类型没有正确实现哈希契约。举个例子：

class Person { public string Name; public int Age; }// ❌ 默认的 GetHashCode() 返回的是内存地址，两个同名同龄的 Person 对象哈希码完全不同

这么做的后果是什么？ExceptWith() 根本找不到“相同”的元素，最后计算出的差集就等于原集合本身，等于白做。

安全一点的做法主要有三种：

• 优先用 record Person(string Name, int Age)——编译器会自动生成匹配的 GetHashCode() 和 Equals()，省心又安全。
• 如果必须用 class，而且能改源码，那就手写这两个方法，并确保实现逻辑一致（比如都以 Name 和 Age 为准）。
• 如果连源码也改不了，那就在构造 HashSet 时传入自定义的 IEqualityComparer，并且在调用 ExceptWith() 前确认两个集合用的是同一个比较器实例。

最后，有一个很容易被忽略的点：ExceptWith() 不会去校验两个集合是否使用了同一套哈希/比较逻辑。如果一个用的是默认比较器，另一个是自定义的，结果将不可预测，而且不会有任何编译错误或运行时警告。这意味着，一旦出现这种不一致，调试起来会非常隐蔽。所以，一定要在代码里明确确保一致性。