const和readonly核心区别在于值的确定时间和不变性机制。const字段的值在编译时确定，且不可更改，适用于数值、bool、char和string类型，隐式静态，直接内联到代码；readonly字段的值在运行时确定，可在声明或构造函数中赋值，支持所有类型，可为静态或实例字段，仅保证引用不变性，不保证对象内容不可变。选择const用于编译时固定值，如数学常量；选择readonly用于运行时初始化，如配置或依赖注入。使用readonly list
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<string> names = new List<string>();</string></string>来声明一个列表，并认为这个列表是不可变的。但实际上，
readonly只保证
names这个引用不能再指向另一个
List对象，你仍然可以对
names列表进行
Add、
Remove等操作，因为列表对象本身是可变的。如果你需要一个真正不可变的列表，你需要使用像
ImmutableList<t></t>这样的类型。
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<string>();</string>这样的代码。但是，
_data.Add(item);这样的操作却是完全允许的，因为它修改的是
List<string></string>对象内部的状态，而不是
_data这个引用本身。
线程安全问题： 如果一个
readonly字段指向的是一个可变的对象（比如
List<t></t>,
Dictionary<tkey tvalue></tkey>，或者你自定义的带有公共setter的类），并且这个对象被多个线程共享访问，那么你仍然需要自己处理线程安全问题。多个线程同时修改这个可变对象的内部状态，会导致竞态条件、数据损坏等问题。
readonly本身对此无能为力。
为了确保线程安全，你需要：
-
使用不可变对象： 如果可能，让
readonly字段指向一个本身就是不可变的对象。C#中有很多内置的不可变类型，例如
string、
DateTime、
Guid。对于集合，可以使用
System.Collections.Immutable命名空间下的类型，如
ImmutableArray<t></t>、
ImmutableList<t></t>等。一旦这些不可变对象被创建，它们的内容就不能被修改。 手动同步访问： 如果你必须使用可变对象，并且它被多个线程共享，那么你需要在访问或修改该对象的代码块周围使用锁（如
lock关键字）或其他同步机制，以确保同一时间只有一个线程可以修改它。 返回不可变视图： 就像
GetData()方法中那样，返回一个
IReadOnlyList<string></string>接口，这可以防止外部代码通过返回的引用修改原始列表，但内部方法仍然可以修改。但这只是“外部不可变”，内部仍需注意。
不可变性： 当你真正想要实现不可变性时，仅仅使用
readonly是不够的。你需要确保： 所有字段都是
readonly的。 所有字段指向的类型本身也是不可变的（或者至少是不可变的接口）。 没有公共的setter。 构造函数只进行初始化，不暴露内部可变状态。
总而言之，
readonly是一个非常有用的关键字，它帮助我们强制执行“引用不变性”的规则。但在多线程环境或需要严格数据不变性的场景下，我们必须更深入地思考它所指向的对象的性质，以避免潜在的问题。
