Except未返回预期结果是因为默认按引用比较，自定义引用类型需重写Equals/GetHashCode或传IEqualityComparer；record类型可自动按值比较；大数据量时建议用HashSet预热提升性能。
Except 为什么没返回预期结果？先看相等性怎么算
默认情况下，Except 比较的是引用或值类型的默认相等逻辑。比如两个 new Person { Id = 1 } 实例，即使属性一样，Except 也会认为它们不同——因为 Person 没重写 Equals 和 GetHashCode。
常见错误现象：listA.Except(listB) 返回全量数据，看起来“没生效”。
- 值类型（
int、string、DateTime）用默认比较，通常没问题 - 引用类型（自定义类/记录）必须提供相等性契约：要么重写
Equals/GetHashCode，要么传入IEqualityComparer<t></t> - 用
record是最省心的选择——它自动按值比较，Except直接可用
差集、交集、并集三兄弟的参数顺序和空值行为
Except、Intersect、Union 都是左操作数减/交/并右操作数，且返回结果去重、保持左操作数中首次出现的顺序（不是原始顺序，而是“左序列中首次出现”的顺序）。
容易踩的坑：null 值参与运算时，string 类型的 null 默认会被当作相等项处理；但若用自定义比较器没处理 null，可能抛 NullReferenceException。
-
listA.Except(listB)→ listA 中有、listB 中没有的元素 -
listA.Intersect(listB)→ 两者都有的元素（取交集，不是 listB 中的顺序） -
listA.Union(listB)→ 合并去重，顺序按 listA 先出现、再 listB 中新元素 - 任一输入为
null，直接抛ArgumentNullException，务必提前判空
性能关键：大数据量下别用默认 Except，改用 HashSet 预热
原生 Except 在内部会为右操作数构建查找结构，但每次比较仍走枚举+委托调用，大数据量（如 >10k 条）时明显变慢。尤其配合自定义 IEqualityComparer 时，委托开销放大。
实操建议：手动用 HashSet<t></t> 预建右集合，再用 Where + Contains 替代：
var setB = new HashSet<int>(listB); // O(n) 构建 var diff = listA.Where(x => !setB.Contains(x)).ToList(); // O(m)
这比 listA.Except(listB) 快 2–5 倍（取决于数据分布），且逻辑更可控。
- 如果右集合不变，
HashSet可复用，避免重复构建 -
Except的延迟执行特性会丢失——ToList()或ToArray()显式触发 - 注意：
HashSet要求类型支持正确哈希，自定义类仍需保证GetHashCode稳定
字符串忽略大小写的差集怎么写？别硬套 StringComparer
想让 "A" 和 "a" 被视为相同？不能只写 Except(..., StringComparer.OrdinalIgnoreCase) 就完事——这个比较器只影响相等判断，不改变原始元素值。
典型误用：new[] {"A", "B"}.Except(new[] {"a"}, StringComparer.OrdinalIgnoreCase) 返回 {"A","B"}，但你可能期望返回 {"B"}（因为 "A" 和 "a" 冲突）。这是对的，但要注意：返回的是左集合里的原始值 "A"，不是标准化后的形式。
- 如果需要统一格式（比如全部转小写再比较），得自己投影：
listA.Select(x => x.ToLower()).Except(listB.Select(x => x.ToLower())) - 但这样丢掉了原始大小写信息；若需保留原始值，应配合
Join或字典映射 -
StringComparer类型只适用于string或可空string，对其他类型无效
Except 不报错，也不报异常，但结果不对，十有八九卡在 Equals 没生效上。 
