Except和Intersect默认对引用类型按地址比较易出错，需重写Equals/GetHashCode、传IEqualityComparer或改用record；注意null处理、大小写敏感、性能优化及去重顺序规则。
Except 和 Intersect 不是“拿来就能用对”的方法——它们的行为高度依赖相等性判断逻辑，而默认行为在引用类型上几乎必然出错。
Except 返回全量数据？先查相等性契约
常见错误现象：listA.Except(listB) 返回 listA 全部元素，看起来“完全没过滤”。
原因很直接：
- 值类型（
int、string、DateTime）走默认比较，通常没问题 - 引用类型（比如
Person类实例）默认按引用地址比较，两个内容相同的new Person { Id = 1 }被视为不同对象
解决路径只有两条：
- 重写
Equals和GetHashCode，确保逻辑一致（修改类定义） - 传入
IEqualityComparer<t></t>实现，不侵入原类型（推荐用于临时或第三方类） - 或直接改用
record：它自动按值比较，Except开箱即用
注意：null 值参与比较时，若自定义比较器未显式处理，会抛 NullReferenceException
Intersect 结果为空？检查输入是否真有共通项
Intersect 的语义是“两者都有的元素”，但它不会告诉你“为什么没有”。典型陷阱包括：
- 一个集合含
"abc"，另一个含"ABC"，默认字符串比较区分大小写 → 不匹配 - 使用了自定义比较器但只覆盖了
Equals，忘了同步实现GetHashCode→ 哈希表查找失败，结果漏项 - 输入集合之一为
null→ 直接抛ArgumentNullException，不是返回空序列
实操建议：
- 字符串忽略大小写交集，用
StringComparer.OrdinalIgnoreCase：listA.Intersect(listB, StringComparer.OrdinalIgnoreCase)
- 对象交集前先确认字段是否真正一致（比如
Id和Name都相同），别只看调试器显示的“看起来一样”
大数据量下 Except 和 Intersect 变慢？换 HashSet 手动查
原生 Except 和 Intersect 内部虽也用哈希，但封装层带来委托调用开销，尤其配合自定义比较器时。实测 >10k 条数据时，性能差距可达 2–5 倍。
更快写法（以差集为例）：
var setB = new HashSet<int>(listB); // O(n) 构建，可复用 var diff = listA.Where(x => !setB.Contains(x)).ToList(); // O(m)
要点：
-
HashSet<T>要求T的GetHashCode稳定且分布合理；自定义类务必保证这点 -
Where + Contains是立即执行，失去延迟执行特性，需明确是否需要该语义 - 若右集合（
listB）不变，setB可缓存复用，避免重复构建
Except 和 Intersect 的顺序与去重规则容易被忽略
它们都自动去重，且结果顺序不是“原始顺序”，而是“在左操作数中首次出现的顺序”：
-
new[] { 2, 1, 2 }.Except(new[] { 1 })→{ 2 }，不是{ 2, 2 } -
new[] { 2, 1, 2 }.Intersect(new[] { 1, 2 })→{ 2, 1 }，因为2在左序列中先于1出现
这个细节在分页、日志比对、增量同步等场景里会直接影响结果正确性——比如你期望保留重复 ID 的上下文，那这两个方法就不适用，得换 Where + Contains 手动控制。
最常被跳过的点：没人检查右操作数是否为空集合。空集合参与运算时，Except 返回全部左操作数，Intersect 返回空序列——这看似合理，但若业务逻辑隐含“右集合必有内容”，就埋了静默缺陷。
