C#的const和readonly字段有什么区别？-小浪学习网

const和readonly核心区别在于值的确定时间和不变性机制。const字段的值在编译时确定，且不可更改，适用于数值、bool、char和string类型，隐式静态，直接内联到代码；readonly字段的值在运行时确定，可在声明或构造函数中赋值，支持所有类型，可为静态或实例字段，仅保证引用不变性，不保证对象内容不可变。选择const用于编译时固定值，如数学常量；选择readonly用于运行时初始化，如配置或依赖注入。使用readonly list时仍可修改列表内容，但不可重新赋值引用；为确保线程安全和不可变性，应使用不可变对象或手动同步访问。

C#的const和readonly字段有什么区别？

C#里的const和readonly字段，核心区别在于它们的值在何时被确定和固定下来。简单来说，const是编译时常量，它的值在代码编译时就必须确定，而且一旦确定就永远不能改变。而readonly则是运行时常量，它的值可以在声明时赋值，也可以在类的构造函数中赋值，但一旦构造函数执行完毕，这个字段的值就不能再改变了。

解决方案

理解const和readonly的关键在于它们“不变”的含义以及不变发生的时间点。

const字段：

编译时常量： 它的值必须在编译时就完全确定。这意味着你不能用一个运行时才能确定的值（比如一个方法调用的结果）来初始化它。
隐式静态： const字段总是隐式地静态的。你不需要也不能显式地使用Static关键字来修饰它。这意味着无论你创建了多少个类的实例，const字段都只有一个副本，并且可以直接通过类名来访问。
类型限制： 只能用于数值类型（int, double, Float等）、bool、char和String。这是因为这些类型的值可以在编译时被直接嵌入到代码中。
不可变性： 一旦定义，其值在程序的整个生命周期内都不能改变。

readonly字段：

运行时常量： 它的值可以在声明时初始化，也可以在类的构造函数中初始化。这意味着你可以用运行时才能确定的值来初始化它，比如通过计算、从配置文件读取，或者通过方法参数传入。
静态或实例： readonly字段可以是实例字段（每个对象实例有自己的副本）或静态字段（所有对象共享一个副本，通过static readonly定义）。
类型不限： 可以用于任何类型，包括自定义的引用类型和值类型。
引用不变性（对于引用类型）： 对于引用类型，readonly保证的是该字段所指向的“引用”本身不能改变，也就是说，它不能再指向另一个对象。但它所指向的那个对象的内容（如果该对象是可变的）仍然是可以改变的。这是一个非常重要的点，我看到很多人在这里犯迷糊。

为什么const只能用于基本类型和字符串，而readonly可以用于任何类型？

这背后其实是它们在内存和编译层面处理方式的差异。const的本质是“编译时替换”。当你在代码中使用了const常量时，编译器会直接把这个常量的值“硬编码”到你使用它的地方。就像你写了个const int MaxAttempts = 3;，那么所有用到MaxAttempts的地方，在编译后都会直接变成数字3。这种直接替换的机制，只有对于那些在编译阶段就能确定其精确值的类型才可行，比如整数、浮点数、布尔值，以及字符串字面量（它们的值在编译时也是确定的）。

但对于引用类型（比如你自定义的类MyClass），情况就完全不同了。一个引用类型的值不仅仅是它本身，更重要的是它指向的内存地址。这个内存地址是在程序运行时，当你使用new关键字创建对象时才分配的。编译器在编译阶段并不知道这个对象会在内存的哪个位置。所以，你无法在编译时把一个对象的“值”（也就是它的内存地址）直接“嵌入”到代码中。

readonly则不同。它允许你在运行时，特别是在构造函数中，为字段赋值。这意味着你可以先创建对象，然后把这个对象的引用赋值给readonly字段。readonly保证的是，一旦这个引用被赋值了，你就不能再把它指向另一个对象。它维护的是引用的不变性，而不是被引用对象内容的不可变性。这就是为什么readonly可以用于任何类型，因为它处理的是引用（或者对于值类型，是其值的副本），而不是在编译时就要求完全固定的、可直接替换的“字面量”。

在实际开发中，何时优先选择const，何时选择readonly？

选择const还是readonly，通常取决于你的数据特性和不变性的需求。

我个人在使用时，会这样考虑：

选择const的场景：
- 真正的、永恒不变的固定值： 比如数学常数（PI）、物理常数、或者你的应用程序中一些永远不会变的配置项（比如默认的端口号，如果它真的永远不变）。
- 编译时已知的字面量： 错误码、状态码的数字值，或者一些固定的提示字符串（例如”操作成功！”）。
- 性能敏感（微优化）： 编译器会将const值直接内联到使用它的地方，这在某些极端情况下可能会带来微小的性能提升，尽管现代JIT编译器通常也能很好地优化readonly。但更重要的是，它表达了一种“完全不变，且在编译时就确定”的意图。
选择readonly的场景：
- 运行时确定的配置或依赖： 比如从配置文件加载的数据库连接字符串，或者在应用程序启动时初始化的某个服务实例。这些值在程序运行时确定，但一旦确定就不应再改变。
- 不可变对象实例的引用： 如果你有一个对象，希望它在被创建后就不能再被重新赋值（指向另一个对象），即使这个对象本身的内容是可变的，readonly也是合适的。例如，一个readonly的Logger实例，你不能把它换成另一个Logger，但你仍然可以通过它来记录日志。
- 实例级别的常量： 如果每个对象实例需要有自己的一组常量，而这些常量在对象创建后就不再改变，那么readonly实例字段是你的选择。例如，一个Person对象可能有一个readonly的BirthDate字段。
- 需要构造函数注入的依赖： 在依赖注入的场景中，服务通常通过构造函数注入，并且这些注入的服务实例通常会被声明为readonly，以确保它们在对象生命周期内保持不变。

一个常见的误区是，有人会用readonly List names = new List();来声明一个列表，并认为这个列表是不可变的。但实际上，readonly只保证names这个引用不能再指向另一个List对象，你仍然可以对names列表进行Add、Remove等操作，因为列表对象本身是可变的。如果你需要一个真正不可变的列表，你需要使用像ImmutableList这样的类型。

readonly字段的线程安全性与不可变性：有什么需要特别注意的吗？

当谈到readonly字段的线程安全性和不可变性时，最需要强调的就是前面提到的那个关键点：readonly只保证引用本身是不可变的，而不是它所指向的对象是不可变的。

想象一下你有这样的代码：

public class MyService {     private readonly List<string> _data = new List<string>();      public MyService(IEnumerable<string> initialData)     {         _data.AddRange(initialData);     }      public void AddItem(string item)     {         _data.Add(item); // 这行代码是完全合法的，即使_data是readonly     }      public IReadOnlyList<string> GetData()     {         return _data;     } }

在这个例子中，_data字段是readonly的。这意味着你不能在构造函数之外写_data = new List();这样的代码。但是，_data.Add(item);这样的操作却是完全允许的，因为它修改的是List对象内部的状态，而不是_data这个引用本身。

线程安全问题： 如果一个readonly字段指向的是一个可变的对象（比如List, Dictionary，或者你自定义的带有公共setter的类），并且这个对象被多个线程共享访问，那么你仍然需要自己处理线程安全问题。多个线程同时修改这个可变对象的内部状态，会导致竞态条件、数据损坏等问题。readonly本身对此无能为力。

为了确保线程安全，你需要：

使用不可变对象： 如果可能，让readonly字段指向一个本身就是不可变的对象。C#中有很多内置的不可变类型，例如string、DateTime、Guid。对于集合，可以使用System.Collections.Immutable命名空间下的类型，如ImmutableArray、ImmutableList等。一旦这些不可变对象被创建，它们的内容就不能被修改。
手动同步访问： 如果你必须使用可变对象，并且它被多个线程共享，那么你需要在访问或修改该对象的代码块周围使用锁（如lock关键字）或其他同步机制，以确保同一时间只有一个线程可以修改它。
返回不可变视图： 就像GetData()方法中那样，返回一个IReadOnlyList接口，这可以防止外部代码通过返回的引用修改原始列表，但内部方法仍然可以修改。但这只是“外部不可变”，内部仍需注意。