init访问器用于在对象初始化时赋值且之后不可变，支持构造函数和对象初始化器两种方式，相比set更安全，适用于配置、DTO等需不可变性的场景，提升代码健壮性与可读性。
C#中的
init
访问器，简单来说，它的核心用途就是让属性在对象创建后变得不可变（immutable）。这意味着你可以在对象实例化时，通过构造函数或者对象初始化器给这些属性赋值，但一旦对象完成构建，这些属性就不能再被修改了。至于如何初始化，也很直接：要么在类的构造函数里赋值，要么在创建对象时使用对象初始化器语法。它本质上提供了一种“只在初始化时设置”的机制，介于完全可变的
set
和只能在构造函数中赋值的
readonly
字段之间，给开发者提供了更灵活的不可变性选择。
解决方案
理解
init
访问器的关键在于它的“一次性赋值”特性。当你在一个属性上使用
init
访问器而不是
set
访问器时，你告诉编译器这个属性的值只允许在以下两种情况中被设置：
在类的构造函数内部： 这是最传统的方式，确保对象在创建时就处于一个有效的状态。在对象初始化器中： 这是
init
访问器真正发光的地方，它允许你在创建对象实例的同一行代码中，以更声明式的方式给属性赋值。
一旦对象初始化过程完成，任何尝试修改
init
属性的操作都会导致编译错误。这对于构建数据契约（data contracts）、配置对象或者任何需要保证其状态在创建后不被随意更改的类型来说，都是一个非常强大的工具。
举个例子，假设我们有一个表示订单项的类：
public class OrderItem{ public int ProductId { get; init; } // 只能在初始化时设置 public string ProductName { get; init; } // 只能在初始化时设置 public decimal UnitPrice { get; init; } // 只能在初始化时设置 public int Quantity { get; set; } // 可以随时修改 // 构造函数，也可以用来初始化init属性 public OrderItem(int productId, string productName, decimal unitPrice) { ProductId = productId; ProductName = productName; UnitPrice = unitPrice; }}// 如何使用和初始化：// 方式一：使用构造函数var item1 = new OrderItem(101, "C#编程指南", 99.99m);item1.Quantity = 2; // Quantity是set属性，可以修改// 方式二：使用对象初始化器（更常见和灵活）var item2 = new OrderItem(102, "ASP.NET Core实战"){ UnitPrice = 129.50m, Quantity = 1 // 这里给Quantity赋值，因为它有set访问器};// 错误示例：尝试修改init属性// item1.ProductId = 200; // 这行代码会导致编译错误！// item2.ProductName = "新的名称"; // 这行代码也会导致编译错误！
通过这个例子，我们能清楚地看到
ProductId
、
ProductName
和
UnitPrice
在对象创建后就“固定”了，而
Quantity
则可以在后续业务逻辑中根据需要调整。这种设计让代码意图更加明确，也减少了潜在的错误。
init
init
访问器与
set
访问器有什么本质区别？
在我看来，
init
和
set
访问器的核心差异，在于它们对“可变性”的承诺和控制粒度。
set
访问器代表的是一种完全的、随时随地的可变性——你可以创建对象，然后想什么时候改它的属性就什么时候改，就像你在修改一个普通变量一样。这种灵活性在很多场景下是必需的，比如一个用户界面上的输入框，它的值需要随着用户的输入而不断更新。
然而，
init
访问器则是在说：“这个属性，它只在对象被构造出来的那一刻有一次赋值的机会。一旦对象‘定型’了，它的这个属性就不能再变了。” 这就好比你点了一份定制化的披萨，在下单的时候你可以选择各种配料，但一旦披萨进了烤箱，你就不能再加芝士或者换掉香肠了。这种“初始化时设置，之后不可变”的特性，让
init
属性成为了构建不可变数据模型（immutable data models）的利器。
从技术实现上讲，当编译器看到
init
访问器时，它会在IL代码层面施加限制，只允许在构造函数或对象初始化器（本质上也是在构造函数执行之后、但对象完全创建之前的一个特殊阶段）中调用其内部的赋值逻辑。而
set
访问器则没有这种限制，它可以在任何地方被调用。
public class Configuration{ // 使用init，表示这些配置项在程序启动后就不应再改变 public string ConnectionString { get; init; } public int MaxRetries { get; init; } = 3; // 可以有默认值 // 使用set，表示这个属性是可变的，比如一个计数器 public int CurrentAttempts { get; set; } public Configuration(string connectionString) { ConnectionString = connectionString; }}var appConfig = new Configuration("Server=.;Database=AppDB"){ MaxRetries = 5 // 通过对象初始化器设置init属性};// appConfig.ConnectionString = "新的连接字符串"; // 编译错误！// appConfig.MaxRetries = 10; // 编译错误！appConfig.CurrentAttempts = 1; // 允许，因为是set属性
这种区别不仅仅是语法上的，它更深层次地影响了我们如何思考和设计类的行为。
init
鼓励我们创建更健壮、更易于理解和调试的系统，尤其是在并发编程和函数式编程风格日益流行的今天，不可变性带来的好处是显而易见的。
什么时候应该优先选择
init
init
属性而非只读字段或构造函数赋值？
这确实是个好问题，因为在C# 9之前，我们想实现属性的“只读”或“初始化后不可变”效果，主要依赖于
readonly
字段或者只通过构造函数赋值的私有
set
属性。
init
访问器出现后，它提供了一个更优雅、更具表现力的选择，尤其是在某些特定场景下。
我个人认为，当你需要一个属性在对象创建时被赋值，并且之后不再改变，同时你又希望能够利用C#强大的对象初始化器语法时，
init
属性就是首选。
考虑以下几种情况：
大量的可选属性或配置项： 如果你的类有很多属性，其中大部分都是可选的，或者它们的值可以通过多种方式（比如从配置文件、环境变量或默认值）来提供。如果只用构造函数，你可能需要创建多个重载构造函数，或者一个参数列表非常长的构造函数，这会变得非常笨拙和难以维护。
// 传统方式，如果有很多属性，构造函数会很长或需要多个重载// public Product(string name, string sku, decimal price, string description, int stock) { ... }// 使用init属性，结合对象初始化器，代码更清晰public class Product{ public string Name { get; init; } public string Sku { get; init; } public decimal Price { get; init; } public string Description { get; init; } public int Stock { get; init; } public Product(string name, string sku, decimal price) // 核心属性可以通过构造函数确保 { Name = name; Sku = sku; Price = price; }}// 初始化时非常灵活和可读var newProduct = new Product("笔记本电脑", "LAPTOP-001", 1299.99m){ Description = "高性能轻薄笔记本", Stock = 50};var minimalProduct = new Product("鼠标", "MOUSE-002", 25.00m);
这里，
Description
和
Stock
是可选的，通过对象初始化器赋值，代码看起来非常干净，不像长长的构造函数参数列表那样容易出错。
构建不可变数据传输对象（DTOs）或值对象： 这些对象通常只用于封装数据，并且一旦创建就不应被修改。
init
属性完美地契合了这种需求，它强制了不可变性，使得这些对象在多线程环境或作为函数参数传递时更加安全。
与记录类型（Records）结合使用： C# 9引入的记录类型（
record
）在很大程度上就是围绕
init
属性构建的。记录类型默认的属性就是
init
属性，这使得它们天生就是不可变的，并且提供了值相等性语义。如果你正在使用记录类型，那么
init
属性自然是你的默认选择。
相比之下，
readonly
字段虽然也能保证不可变性，但它只能在构造函数中赋值，无法利用对象初始化器。这在某些场景下会限制灵活性。而只通过构造函数赋值的私有
set
属性，虽然可以模拟
init
的效果，但需要更多的样板代码（比如为每个属性编写私有
set
），并且不如
init
那样直接表达“初始化时设置”的意图。
所以，我的建议是，当你的属性需要在对象创建后保持不变，并且你欣赏对象初始化器带来的简洁和可读性时，毫不犹豫地选择
init
访问器。它在保持代码整洁的同时，也提供了强有力的不变性保证。
init
init
属性在实际项目开发中能带来哪些具体好处？
从实际项目开发的视角来看，
init
属性带来的好处是多方面的，它不仅仅是语法糖，更是一种设计理念的体现。
提升代码健壮性与可预测性： 这是最直接的好处。当一个对象的某些属性被声明为
init
后，你就能确信这些属性的值在对象生命周期内不会被意外修改。这对于减少bug，特别是那些由于对象状态被意外改变而引发的bug，非常有帮助。在复杂的业务逻辑中，如果一个对象被多个模块或线程共享，不可变性可以大大简化推理过程，降低并发编程的难度。我记得以前调试一些状态混乱的bug时，总是要追溯哪个地方偷偷改了对象的值，有了
init
，这种困扰就少了很多。
简化并发编程： 在多线程或异步编程中，可变状态是导致死锁、竞态条件等问题的罪魁祸首。
init
属性强制的不可变性使得对象可以安全地在不同线程之间共享，无需额外的锁机制，从而简化了并发代码的编写和维护。
更好的API设计和可读性： 对象初始化器与
init
属性的结合，使得类的实例化过程更加清晰。当一个类有许多属性时，使用命名参数（通过对象初始化器实现）来赋值比依赖构造函数中参数的顺序要安全得多，也更容易理解。这对于消费者来说，使用你的API会更加直观。
// 假设一个复杂的过滤器对象public class ProductFilter{ public string Keyword { get; init; } public decimal? MinPrice { get; init; } public decimal? MaxPrice { get; init; } public string Category { get; init; } public bool IncludeOutOfStock { get; init; } = false; // 默认值 // 如果没有init，可能需要一个超长构造函数或者setter}// 使用init和对象初始化器，创建过滤器非常清晰var filter = new ProductFilter{ Keyword = "手机", MinPrice = 1000m, MaxPrice = 5000m, Category = "电子产品"};
这样的代码，一眼就能看出每个属性的含义，而不需要去查阅构造函数的签名。
支持记录类型（Records）的强大功能： 记录类型是C# 9引入的一个重要特性，它默认的属性就是
init
属性。记录类型为创建值类型语义的不可变数据模型提供了极大的便利，包括自动生成构造函数、
Equals
、
GetHashCode
、
ToString
以及
with
表达式（用于非破坏性修改）。
init
访问器是记录类型实现其核心功能的基础。如果你在项目中使用记录类型，那么你自然而然地会享受到
init
带来的所有好处。
提高测试效率： 不可变对象更容易进行单元测试。因为它们的状态在创建后不会改变，所以你可以更确定地知道测试的输入条件和预期结果，而无需担心对象在测试过程中被意外修改，从而简化了测试用例的编写和维护。
总的来说，
init
属性不仅仅是一个语法上的小改进，它在很大程度上推动了C#在构建更现代、更健壮、更易于维护的应用程序方面的能力。它鼓励我们编写更多不可变代码，这在当前软件开发的大趋势下，无疑是一个非常重要的方向。
以上就是C#的init访问器有什么用途？如何初始化属性？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439330.html
微信扫一扫 
支付宝扫一扫 
