C#记录类型中意外的数据不一致问题解析

news/2025/11/10 6:04:58/文章来源:https://www.cnblogs.com/qife122/p/19205700

意外的记录不一致性

前几天，我在排查代码中的一个bug时，发现这源于我对C#记录类型工作方式的误解。可能只有我一个人期望它们以我理解的方式工作，但我觉得值得写下来分享。

这个问题是我在修改2029年英国大选网站时发现的，但它实际上与大选无关，因此我没有将其包含在大选网站的博客系列中。

回顾：非破坏性变更

当记录类型被引入C#时，同时引入了使用with操作符的"非破坏性变更"概念。其思想是记录类型可以是不可变的，但你可以轻松高效地创建一个新实例，该实例具有与现有实例相同的数据，但具有一些不同的属性值。

例如，假设你有这样一个记录：

public sealed record HighScoreEntry(string PlayerName, int Score, int Level);

然后你可以编写以下代码：

HighScoreEntry entry = new("Jon", 5000, 50);
var updatedEntry = entry with { Score = 6000, Level = 55 };

这不会改变第一个实例中的数据（因此entry.Score仍为5000）。

回顾派生数据

记录类型不允许为主要构造函数指定构造函数体（这是我在早期关于记录和集合的文章中打算写的内容），但你可以基于主要构造函数中的参数值初始化字段（以及自动实现的属性）。

作为一个非常简单（且高度人为设计）的示例，你可以创建一个记录，在初始化时确定值是奇数还是偶数：

public sealed record Number(int Value)
{public bool Even { get; } = (Value & 1) == 0;
}

乍一看，这看起来不错：

var n2 = new Number(2);
var n3 = new Number(3);
Console.WriteLine(n2); // 输出: Number { Value = 2, Even = True }
Console.WriteLine(n3); // 输出: Number { Value = 3, Even = False }

到目前为止一切顺利。直到本周，我一直认为这一切都很好。

问题：混合使用with和派生数据

问题出现在混合使用这两个功能时。如果我们更改上面的代码（同时保持记录本身不变），使用with操作符而不是调用构造函数来创建第二个Number，输出就会变得不正确：

var n2 = new Number(2);
var n3 = n2 with { Value = 3 };
Console.WriteLine(n2); // 输出: Number { Value = 2, Even = True }
Console.WriteLine(n3); // 输出: Number { Value = 3, Even = True }

"Value = 3, Even = True"真的不好。

这是怎么发生的？出于某种原因，我一直假设with操作符使用新值调用构造函数。但实际上并非如此。上面的with操作符大致转换为如下代码：

// 这不会编译，但大致是生成的内容。
var n3 = n2.<Clone>$();
n3.Value = 3;

<Clone>$方法（至少在这种情况下）调用生成的复制构造函数（Number(Number)），该构造函数复制Value和Even的支持字段。

这一切都有文档记录——但目前没有任何关于可能引入的不一致性的警告。（我将给微软的同事发邮件，看看能否在其中添加一些内容。）

请注意，由于Value是在克隆操作之后设置的，我们无论如何都无法编写一个复制构造函数来正确处理这个问题。（至少，没有直接的方法——我稍后会提到一个复杂的方法。）

如果有人想"为什么不直接使用计算属性？"，显然这是可行的：

public sealed record Number(int Value)
{public bool Even => (Value & 1) == 0;
}

任何可以像这样轻松按需计算的属性都很棒——不仅不会出现本文中的问题，而且在内存方面也更高效。但这对于我在大选网站中使用的大多数记录中的属性来说真的不起作用，这些记录通常使用按ID索引的集合构建，或者执行其他相对昂贵的计算。

我们能做什么？

到目前为止，我想到了四种前进的方法，但没有一种是令人愉快的。我很想听听其他人的建议。

选项1：耸耸肩继续生活

现在我知道了这个问题，我可以避免在除了"简单"记录之外的任何东西上使用with操作符。如果没有计算属性或字段，with操作符仍然非常有用。

当然，存在一种风险，我可能在一个最初"简单"的记录类型上使用with操作符，然后后来引入一个计算成员。嗯。

选项2：编写Roslyn分析器来检测问题

至少在理论上，对于任何在声明它们的同一解决方案中使用的记录（这对我的大选网站来说是一切），编写一个Roslyn分析器应该是可行的，该分析器：

分析每个声明记录中的每个成员初始化器，以查看使用了哪些参数
分析每个with操作符的使用，以查看正在设置哪些参数
如果两者之间存在任何交集，则记录错误

这很有吸引力，可能对其他人也有用。它的缺点是需要实现Roslyn分析器。我很久没有编写分析器了，但我猜这仍然是一个相当复杂的过程。如果我真正找到时间，这很可能是我会做的事情——但我希望有人评论说分析器已经存在，或者解释为什么不需要它。

更新，2025-07-29：我写了一对分析器！请参阅我的后续文章了解更多细节。

选项3：找出安全使用with的方法

我一直在尝试如何使用Lazy<T>来延迟计算任何属性，直到它们第一次被使用，这将在with操作符为属性设置新值之后。我想出了下面的模式——我认为这是有效的，但非常混乱。采用这种模式不需要将父记录中的每个新参数都反映在嵌套类型中——仅用于计算属性中使用的参数。

public sealed record Number(int Value)
{private readonly Lazy<ComputedMembers> computed =new(() => new(Value), LazyThreadSafetyMode.ExecutionAndPublication);public bool Even => computed.Value.Even;private Number(Number other){Value = other.Value;// 延迟创建ComputedMembers实例，直到computed = new(() => new(this), LazyThreadSafetyMode.ExecutionAndPublication);}// 这是一个结构体（或者可以是一个类），而不是记录，// 以避免为Value创建字段。我们只需要计算属性。// （我们甚至不需要使用主要// 构造函数，在某些情况下最好不要使用。）private struct ComputedMembers(int Value){internal ComputedMembers(Number parent) : this(parent.Value){}public bool Even { get; } = (Value & 1) == 0;}
}

这是：