.NET中LINQ的Intersect方法是否始终返回第一个序列的实例？

首先明确回答你：是的，Intersect方法始终会返回第一个输入序列中的实例，而非第二个序列的。你的测试结果完全符合这个行为，下面我来详细解释：

1. Intersect的内部实现逻辑 #

虽然官方文档没有把这个细节写得特别直白，但从.NET的实际源代码实现来看，Enumerable.Intersect的执行流程是这样的：

• 首先遍历第一个序列（items1），将所有元素加入一个哈希集合（基于你实现的相等逻辑去重）；
• 然后遍历第二个序列（items2），检查每个元素是否存在于这个哈希集合中；
• 最终的结果集，是直接从第一个序列中筛选出那些在第二个序列里存在匹配（按相等逻辑）的元素，不会包含第二个序列中的任何实例。

所以你得到Name=1的实例，完全符合这个流程。

2. 针对你的业务场景的建议 #

你的场景是本地存储条目和后端返回条目合并，同Id的在线条目有更新的Name。这种情况下，单纯用Intersect可能不是最优选择：

• 如果需要保留本地实例并更新Name：可以先通过Intersect找到共同Id的条目，再用后端的Name值覆盖本地实例的Name；
• 如果需要直接使用后端的实例：可以把后端序列作为Intersect的第一个参数，本地序列作为第二个，这样结果就会是后端的实例；
• 更灵活的方式是使用Join操作，把两个序列按Id关联，然后直接构建新的Item实例（比如保留本地的基础信息，替换为后端的Name）。

3. 关于LINQ相等逻辑的补充 #

LINQ的集合操作（如Intersect、Distinct、Union等）默认使用EqualityComparer<T>.Default来判断相等性。这个比较器的优先级是：

• 优先使用类型实现的IEquatable<T>.Equals方法（也就是你写的Equals(Item other)）；
• 如果没有实现IEquatable<T>，才会回退到object.Equals。

你的Item类正确实现了IEquatable<Item>，所以Intersect完全按照你定义的“Id相等则对象相等”逻辑来工作，这部分是符合预期的。

内容的提问来源于stack exchange，提问作者Don Box