C#的init-only属性如何实现不可变对象？-C#.Net教程-PHP中文网

init-only属性允许在对象初始化时设置值，之后不可修改，1. 它通过init访问器实现仅在构造函数或对象初始化器中赋值；2. 与readonly字段不同，它是属性，可被接口成员引用和反射识别；3. 与get; set;属性相比，它在初始化后禁止写入，确保不可变性；4. 适用于dto、值对象、线程安全场景和函数式编程；5. 在继承中，派生类可设置基类的init属性；6. 创建“修改版”对象需新建实例，推荐结合record类型使用with表达式简化操作；7. 多数序列化库支持init属性的反序列化。init-only属性为c#中的不可变数据建模提供了安全、简洁且编译器强制的解决方案。

C#的init-only属性如何实现不可变对象？

C#中的

init-only

登录后复制

属性提供了一种优雅的方式来创建不可变对象。它允许你在对象初始化时（无论是通过构造函数还是对象初始化器）设置属性的值，但在此之后，这些属性就不能再被修改了。这对于构建数据完整性高、线程安全且状态可预测的系统非常有用。在我看来，这是C#语言在追求更安全、更易维护代码方面迈出的重要一步。

解决方案

init-only

登录后复制

属性的核心在于其

init

登录后复制

访问器。它就像是

set

登录后复制

访问器的一个特殊版本，只不过它的赋值权限被严格限制在了对象构造阶段。这意味着，一旦一个对象被完全实例化，带有

init

登录后复制

访问器的属性就变成了只读的。

我们来看一个简单的例子。假设我们想定义一个表示产品信息的类，一旦产品ID和名称确定，就不应该再被更改：

public class Product
{
    public int Id { get; init; } // 只能在初始化时设置
    public string Name { get; init; } // 只能在初始化时设置
    public string Description { get; set; } // 可以随时修改

    // 构造函数可以用来初始化init属性
    public Product(int id, string name)
    {
        Id = id;
        Name = name;
    }
}

// 如何使用它：
var myProduct = new Product(101, "智能手机")
{
    Description = "最新款的智能手机，性能卓越。"
};

// 尝试修改init属性会引发编译错误：
// myProduct.Id = 102; // 编译错误：Init-only property or indexer 'Product.Id' can only be assigned in an object initializer, or on 'this' or 'base' in an instance constructor or an 'init' accessor.

// 而普通的set属性则可以修改：
myProduct.Description = "限时特惠，性能卓越。";

// 通过对象初始化器来设置init属性也完全没问题：
var anotherProduct = new Product(202, "无线耳机")
{
    Description = "高音质，佩戴舒适。",
    // Id = 202, // 也可以在这里设置，但如果构造函数已经设置了，就没必要了
    // Name = "无线耳机"
};

登录后复制

从上面的代码可以看出，

Id

登录后复制

和

Name

登录后复制

属性在对象创建后就“固化”了。这种机制有效地阻止了外部对对象核心状态的意外修改，从而确保了数据的不可变性。对于那些需要确保数据在创建后不会被篡改的场景，

init-only

登录后复制

属性提供了一个非常简洁且编译器强制的解决方案。这比以前我们不得不写只读字段或者私有set属性然后通过构造函数赋值要方便太多了。

C#中

init-only

登录后复制

属性与

readonly

登录后复制

字段或

get; set;

登录后复制

属性有何区别？

理解

init-only

登录后复制

属性的价值，很大程度上取决于你如何看待它与现有机制的异同。在我看来，它们各自有明确的适用场景，并不是简单的替代关系。

readonly

登录后复制

字段：它是一个字段（field），而不是属性（property）。

readonly

登录后复制

字段只能在声明时或构造函数中赋值。一旦赋值，就不能再更改。它的主要用途是封装类的内部状态，通常不直接暴露给外部。比如，一个类的内部配置值，或者一个计算出来的、在对象生命周期内不变的哈希值。它的缺点在于，如果你想通过属性的形式暴露这个值，你还需要额外写一个

get

登录后复制

属性，并且这个属性的值就直接等于

readonly

登录后复制

字段的值。

get; set;

登录后复制

属性：这是我们最常用的属性形式，提供了完整的读写能力。它意味着这个属性的值可以在对象生命周期的任何时候被读取和修改。这非常灵活，但同时也带来了潜在的问题：如果一个对象的状态可以随意被修改，那么在多线程环境下，或者在复杂的业务逻辑中，跟踪其状态变化并确保数据一致性会变得非常困难，甚至可能引入难以发现的bug。

init-only

登录后复制

属性：它是一个属性（property），这意味着它拥有属性的所有优点，比如可以有访问器（get/init），可以作为接口成员，可以被反射工具识别为属性等等。但它的特殊之处在于，其

init

登录后复制

访问器只允许在对象初始化阶段（包括构造函数和对象初始化器）进行赋值。一旦初始化完成，它就变得和只有

get

登录后复制

访问器的属性一样，不可再被外部修改。

简单来说：

```
readonly
```
登录后复制
字段是内部的、只读的变量。
```
get; set;
```
登录后复制
属性是外部可读写的变量。
```
init-only
```
登录后复制
属性是外部可读的，但只能在创建时一次性写入的变量。

我觉得

init-only

登录后复制

属性的出现，填补了

readonly

登录后复制

字段和

get; set;

登录后复制

属性之间的一个空白。它让我们可以轻松地定义那些“一旦诞生，便不再改变”的数据结构，同时又保持了属性的便利性。

在实际项目开发中，何时应该优先考虑使用

init-only

登录后复制

属性？

在我的项目实践中，

init-only

登录后复制

属性的出现，确实让很多场景下的代码变得更加清晰和安全。

一个非常典型的场景是数据传输对象（DTOs）和值对象（Value Objects）。这些对象通常承载着一组数据，它们被设计成在创建后就不应该再发生变化。例如，一个表示订单详情的DTO，或者一个表示用户地址的值对象。一旦订单被创建，其订单号、商品列表、下单时间等核心信息就不应该被随意修改。使用

init-only

登录后复制

属性可以强制这种不可变性，避免了在代码某处不小心修改了这些关键数据。这对于API响应、消息队列中的消息体等场景特别有用。

北极象沉浸式AI翻译

免费的北极象沉浸式AI翻译 - 带您走进沉浸式AI的双语对照体验

查看详情

另一个让我觉得

init-only

登录后复制

属性大放异彩的地方是构建线程安全的数据结构。在多线程环境下，如果多个线程可以同时修改同一个对象的状态，那么就可能出现竞态条件和数据不一致的问题，需要复杂的锁机制来同步。而如果一个对象是不可变的，也就是说它的状态在创建后就不会改变，那么它天生就是线程安全的。你可以在多个线程之间安全地共享这个对象，而无需担心同步问题。这大大简化了并发编程的复杂性，减少了潜在的bug。

此外，在函数式编程范式中，不可变性是一个核心原则。

init-only

登录后复制

属性与这种理念完美契合。它鼓励我们通过创建新的对象来表示状态的变化，而不是修改现有对象。这使得代码的副作用更少，更容易测试，也更易于理解和推理。当你看到一个

init-only

登录后复制

的属性，你立刻就知道它的值是稳定的，不需要担心它会在某个不经意间被改变。

最后，不得不提的是C# 9引入的

record

登录后复制

类型。

record

登录后复制

类型在设计之初就强烈倾向于不可变性，而

init-only

登录后复制

属性正是其实现不可变性的基石。当你定义一个

record

登录后复制

，它的位置参数属性默认就是

init-only

登录后复制

的。如果你正在使用

record

登录后复制

来定义你的数据模型，那么你其实就已经在受益于

init-only

登录后复制

属性带来的便利和安全性了。

init-only

登录后复制

属性在复杂对象构造和继承场景下有哪些注意事项？

虽然

init-only

登录后复制

属性非常强大，但在一些复杂场景下，确实有一些值得注意的地方，避免踩坑。

首先是构造时的强制性。

init-only

登录后复制

属性必须在对象初始化时被赋值。这意味着，如果你定义了一个

init-only

登录后复制

属性，而没有在构造函数或对象初始化器中给它赋值，那么它会保持其类型的默认值（例如，

int

登录后复制

是0，引用类型是

null

登录后复制

）。这在某些情况下可能不是你想要的。比如，你有一个

Id { get; init; }

登录后复制

，如果你没有在构造时设置它，它的值就是0，而不是一个未定义的状态。所以，在设计类时，你需要明确哪些

init-only

登录后复制

属性是必须有值的，并确保在所有构造路径中都对其进行了赋值。

在继承场景下，

init-only

登录后复制

属性的表现是符合直觉的。基类中的

init-only

登录后复制

属性可以由派生类的构造函数或对象初始化器进行设置。这和普通的

set

登录后复制

属性行为是一致的，你不需要担心额外的复杂性。例如：

public class BaseItem
{
    public int BaseId { get; init; }
}

public class DerivedItem : BaseItem
{
    public string DerivedName { get; init; }

    public DerivedItem(int baseId, string derivedName)
    {
        BaseId = baseId; // 设置基类的init属性
        DerivedName = derivedName;
    }
}

var item = new DerivedItem(1, "SubItem");
// item.BaseId = 2; // 编译错误

登录后复制

一个经常会遇到的问题是，当你有一个不可变对象，但你需要基于它创建一个“修改版”的新对象时，该怎么办？因为

init-only

登录后复制

属性是不可变的，你不能直接修改原对象。这时，你通常需要创建一个新对象，并将原对象的大部分属性值复制过来，只修改你需要改变的那部分。这在手动操作时可能会有些繁琐。

// 假设Product是init-only属性的类
var originalProduct = new Product(101, "智能手机") { Description = "旧描述" };

// 如果要修改描述，需要创建一个新对象
var updatedProduct = new Product(originalProduct.Id, originalProduct.Name)
{
    Description = "新描述" // 只修改Description
};
// 或者
var updatedProduct2 = new Product(originalProduct.Id, originalProduct.Name)
{
    Description = "新描述",
    // 如果Product有更多的init属性，需要一个个复制过来
    // PropertyX = originalProduct.PropertyX,
    // PropertyY = originalProduct.PropertyY
};

登录后复制

而这正是

record

登录后复制

类型中with
登录后复制
表达式的用武之地。

with

登录后复制

表达式是专门为不可变对象（特别是

record

登录后复制

）设计的，它允许你以非常简洁的方式创建一个现有对象的副本，并同时修改其中一个或多个属性。它在底层就是利用了

init

登录后复制

属性的机制。

// 如果Product是一个record类型
public record ProductRecord(int Id, string Name)
{
    public string Description { get; init; }
}

var originalRecord = new ProductRecord(101, "智能手机") { Description = "旧描述" };

// 使用with表达式创建新对象，并修改Description
var updatedRecord = originalRecord with { Description = "新描述" };

// originalRecord 保持不变
// updatedRecord 是一个新对象，Id和Name与originalRecord相同，但Description不同

登录后复制

所以，如果你发现自己经常需要创建不可变对象的“修改版”，那么考虑将你的类改为