ExceptWith() 比 foreach + Contains() 快 2–3 倍，因其复用哈希分布、按桶并行扫描、避免重复哈希计算；传入非 HashSet 会退化为 O(n×m)；自定义类型须正确实现 GetHashCode/Equals 或统一使用 IEqualityComparer。
直接用 ExceptWith() 比手动遍历 + Contains() 快 2–3 倍，不是错觉，是哈希表底层批量操作的必然结果。
为什么 ExceptWith() 比 foreach + Contains() 快得多
它不是“先遍历再查”，而是把两个哈希表的桶结构对齐后做批量剔除：跳过哈希码不匹配的桶，对命中桶只比对链表头几个节点（冲突少时基本 O(1)），避免了每次 Contains() 都要重新计算哈希、定位桶、遍历链表。
手动写循环时，哪怕 alreadyProcessed 是 HashSet<T>，foreach 迭代 exampleSet 的每个元素仍要单独调用一次 Contains() —— 每次都是完整查找路径，开销叠加。
而 ExceptWith() 内部会：
- 复用目标集合（
alreadyProcessed）已有的哈希分布，不做重复哈希计算 - 按桶并行扫描（.NET 6+ 默认启用），减少 cache miss
- 直接修改原集合的内部数组引用，不新建对象
ExceptWith() 的参数类型和常见误用
它接受 IEnumerable<T>，但传入非 HashSet<T> 时性能会断崖下跌 —— 因为无法利用哈希结构加速，退化为 O(n×m)。
正确做法：
- 确保传入的是
HashSet<T>或至少是Dictionary<T, bool>（其 KeySet 本质也是哈希） - 避免传
List<T>、Array或 LINQ 查询结果（如Where(...).ToList()），它们会触发逐项Contains()回退逻辑 - 如果只有
IEnumerable<T>源，先显式构造：new HashSet<T>(source)，别省这一步
错误示例：set.ExceptWith(dbResults.Where(x => x.IsActive)) —— 这里 Where 返回的是延迟执行的迭代器，ExceptWith 会在内部反复枚举它，极慢。
不想改原集合？别用 ExceptWith()，改用 LINQ
ExceptWith() 是就地修改，返回 void；而 Enumerable.Except() 返回新 IEnumerable<T>，不碰原集合。
关键区别：
-
set1.ExceptWith(set2)→set1被清空掉所有在set2中存在的元素 -
set1.Except(set2)→ 返回新序列，set1和set2完全不变
注意：两者使用的相等比较逻辑也不同 —— ExceptWith() 用集合自身的 IEqualityComparer<T>（构造时指定或默认），而 Except() 可额外传第二个参数覆盖比较器，灵活性更高，但多一次委托调用开销。
自定义类型必须重写 GetHashCode() 和 Equals()
差集结果错乱，90% 是因为引用类型没正确实现哈希契约。例如：
class Person { public string Name; public int Age; }
// ❌ 默认 GetHashCode() 返回内存地址，两个同名同龄 Person 哈希码不同
后果：ExceptWith() 根本找不到“相同”元素，差集等于原集合。
安全做法：
- 优先用
record Person(string Name, int Age)—— 编译器自动生成匹配的GetHashCode()和Equals() - 若必须用
class，且能改源码，手写二者，并确保逻辑一致（比如都只看Name和Age） - 若不能改源码，构造
HashSet<Person>时传入自定义IEqualityComparer<Person>，并在ExceptWith()前确保两个集合用的是同一个比较器实例
最容易被忽略的一点：ExceptWith() 不校验两个集合是否用了同一套哈希/比较逻辑 —— 如果一个用默认，一个用自定义，结果不可预测，且无任何编译或运行时提示。
