C#中的常量（
const）和只读字段（
readonly）都是用来定义不可变数据的，但它们在初始化时机、类型限制和编译行为上有着本质的区别。简单来说，
const是编译时常量，它的值在编译阶段就已确定并嵌入到代码中；而
readonly是运行时常量，它的值可以在声明时或在构造函数中确定，一旦确定后就不能再修改。理解这些差异，对于写出健壮、高效且易于维护的C#代码至关重要。
解决方案
const关键字用于声明编译时常量。这意味着它的值必须在声明时就确定，并且这个值必须是一个在编译时就能计算出的表达式。
const只能应用于基本数值类型（如
int,
double,
bool）、
string类型或
null。它默认是静态的，因此不能用
static关键字修饰。编译器在遇到
const变量时，会直接将其值替换到代码中，这被称为“内联”。
public class MyConstants
{
public const int MaxAttempts = 3; // 编译时常量
public const string DefaultName = "Guest"; // 编译时常量
// public const DateTime StartTime = DateTime.Now; // 错误：DateTime.Now 不是编译时常量
}readonly关键字则用于声明只读字段。它的值可以在声明时初始化，也可以在类的构造函数中初始化。一旦构造函数执行完毕，
readonly字段的值就不能再被修改。与
const不同，
readonly字段可以是任何类型，包括引用类型。它既可以是实例字段，也可以是静态字段（通过
static readonly）。
readonly字段的值是在运行时确定的，不会被编译器内联。
public class MySettings
{
public readonly int MaxUsers; // 可以在构造函数中初始化
public readonly Guid SessionId = Guid.NewGuid(); // 可以在声明时初始化
public static readonly List<string> ValidStates = new List<string> { "Active", "Inactive" }; // 静态只读字段
public MySettings(int maxUsers)
{
MaxUsers = maxUsers; // 在构造函数中初始化
// SessionId = Guid.NewGuid(); // 可以在构造函数中重新赋值，但只能一次
// ValidStates = new List<string>(); // 错误：静态只读字段不能在实例构造函数中重新赋值
}
public MySettings()
{
// MaxUsers = 10; // 也可以在这里初始化，但如果另一个构造函数也初始化，就会有歧义
}
}从我的经验来看，选择
const还是
readonly往往取决于值的来源和其在程序生命周期中的确定性。如果一个值在程序编译时就固定不变，且是基本类型或字符串，那么
const是一个直接且性能稍优的选择。但如果值需要根据程序启动时的配置、依赖注入的结果，或者是一个复杂的对象实例，那么
readonly显然是更灵活、更安全的方案。
C#中什么时候应该选择使用常量（const）而不是只读字段（readonly）？
选择
const而非
readonly，通常是基于几个核心考量：值的确定性、类型限制和性能。
当一个值是真正意义上的“常量”，即它在程序的整个生命周期中，从编译那一刻起就永不改变，并且这个值是基本类型（
int,
bool,
double等）或
string类型时，
const是最合适的选择。想想数学常数（如
Math.PI），或者像
public const int DefaultPageSize = 20;这样的固定配置值。这些值在编译时就已经完全确定，并且编译器会直接将它们的值“烘焙”到使用它们的地方，这种内联行为可以带来微小的性能提升，因为它避免了运行时查找内存地址的开销。
但这种便利性也带来一个潜在的陷阱：如果你在一个库中定义了一个
public const，其他项目引用并使用了它。如果未来你修改了这个
const的值，那么所有引用这个库的项目都必须重新编译，才能使用新的
const值。否则，它们仍然会使用旧的、内联到它们自己代码中的值，这可能导致难以追踪的运行时错误。这通常被称为“版本兼容性问题”或“DLL Hell”的一个小分支。
因此，我的个人建议是，对于那些绝对不会改变、且是基本类型或字符串的内部私有或保护常量，可以放心地使用
const。但对于任何可能在未来版本中发生变化，或者需要暴露给外部消费者的“常量”值，即使它看起来像是编译时就能确定的，也更倾向于使用
public static readonly。这能为你未来的API演进留出足够的灵活性，避免给下游使用者带来不必要的重新编译负担。
C#只读字段（readonly）在并发编程或多线程环境中有什么特别的优势或注意事项？
在并发编程和多线程环境中，
readonly字段扮演着一个微妙但重要的角色，它主要通过限制字段的赋值次数来提升线程安全性。
readonly确保一个字段在对象构造完成之后（或静态字段在类型初始化之后）不能被重新赋值。这意味着，一旦
readonly字段被初始化，它的“引用”或“值类型内容”就是固定的。这对于多线程环境来说是一个优势，因为它消除了在多个线程尝试同时修改同一个字段引用/值时可能出现的竞争条件。例如，如果你有一个
readonly字段
_configuration，指向一个配置对象，那么你就不必担心某个线程会意外地将
_configuration重新指向另一个配置对象。
public class ThreadSafeService
{
private readonly ILogger _logger; // 引用本身不可变
public ThreadSafeService(ILogger logger)
{
_logger = logger ?? throw new ArgumentNullException(nameof(logger));
}
public void DoWork()
{
_logger.LogInfo("Doing some work...");
// _logger = new AnotherLogger(); // 编译错误：不能修改只读字段
}
}然而，这里有一个非常重要的注意事项，也是许多开发者容易混淆的地方：
readonly关键字只保证了字段本身的引用或值不可变，它不保证该字段所指向的对象内容是不可变的。如果你的
readonly字段是一个引用类型，比如
readonly List<string> _data;</string>，那么
_data这个引用本身是不能被重新赋值的（你不能让它指向一个新的
List对象），但是
_data所指向的
List对象本身却是可变的。这意味着，不同的线程仍然可以通过
_data.Add("item") 或 _data.Clear()等操作来修改
List内部的内容，这仍然会导致竞争条件，需要额外的同步机制（如
lock）来保护
List对象的内部状态。
public class DataProcessor
{
private readonly List<string> _sharedData = new List<string>(); // 引用不可变，但列表内容可变
private readonly object _lock = new object(); // 用于同步
public void AddData(string item)
{
lock (_lock) // 保护_sharedData的内部状态
{
_sharedData.Add(item);
}
}
public List<string> GetDataSnapshot()
{
lock (_lock)
{
return new List<string>(_sharedData); // 返回副本，避免外部直接修改
}
}
}所以，在多线程环境中，
readonly是一个有益的起点，它能帮助你明确哪些字段的引用不会被意外更改。但如果你处理的是可变引用类型，仅仅
readonly是不够的，你还需要结合其他线程安全技术（如锁、不可变集合、原子操作等）来确保被引用对象的内部状态在并发访问下也是安全的。
C#中常量（const）和只读字段（readonly）在API设计和版本兼容性方面有哪些考量？
在API设计和版本兼容性方面，
const和
readonly的选择是一个非常关键的决策，它直接影响到你的库或组件的消费者在未来升级时的体验。
正如前面提到的，
const字段在编译时会被内联到所有使用它的代码中。这意味着，如果你的库（比如
MyLibrary.dll）定义了一个
public const int Version = 1;，而另一个应用程序（
MyApplication.exe）引用并使用了这个
Version常量，那么在
MyApplication.exe编译时，
1这个值会被直接写入到
MyApplication.exe的IL代码中。
问题来了：如果你的
MyLibrary.dll升级了，将
Version改为
2，并发布了新版本。此时，如果
MyApplication.exe没有重新编译，它仍然会使用旧的
1值，因为它在编译时就已经把
1硬编码进去了。这会导致应用程序的行为与新库的预期不符，甚至可能引发运行时错误或逻辑缺陷。这种行为在版本兼容性方面是一个巨大的隐患，尤其是在大型项目或公共API中。
// MyLibrary.dll
public class LibraryInfo
{
public const int ApiVersion = 1; // 假设这是旧版本
// ...
}
// MyApplication.exe (引用MyLibrary.dll旧版本编译)
public class Consumer
{
public void CheckVersion()
{
Console.WriteLine($"Current API Version: {LibraryInfo.ApiVersion}"); // 编译时，ApiVersion被替换为1
}
}
// 后来，MyLibrary.dll更新为
public class LibraryInfo
{
public const int ApiVersion = 2; // 新版本
// ...
}
// 此时，如果MyApplication.exe不重新编译，它仍然会输出 "Current API Version: 1"相比之下，
readonly字段则表现得更为友好。
readonly字段的值是在运行时从定义它的程序集加载的。所以，如果你的库定义了一个
public static readonly int ApiVersion = 1;，而
MyApplication.exe引用并使用了它。当你的库升级，将
ApiVersion改为
2并发布新版本时，
MyApplication.exe不需要重新编译。在运行时，它会加载新版本的
MyLibrary.dll，并从其中读取
ApiVersion的新值
2。
// MyLibrary.dll
public class LibraryInfo
{
public static readonly int ApiVersion = 1; // 假设这是旧版本
// ...
}
// MyApplication.exe (引用MyLibrary.dll旧版本编译)
public class Consumer
{
public void CheckVersion()
{
Console.WriteLine($"Current API Version: {LibraryInfo.ApiVersion}"); // 运行时，从MyLibrary.dll加载值
}
}
// 后来，MyLibrary.dll更新为
public class LibraryInfo
{
public static readonly int ApiVersion = 2; // 新版本
// ...
}
// 此时，即使MyApplication.exe不重新编译，它也会输出 "Current API Version: 2"因此，在设计公共API时，我的建议是：
-
对于公共可见的、可能会在未来版本中改变其值的“常量”，即使其值在编译时可以确定，也强烈推荐使用
public static readonly。这为你的库提供了更好的向前兼容性，减少了消费者的升级负担。 对于只在内部使用的、且绝对不会改变的编译时常量（例如私有辅助常量），可以使用
const。但即使是内部常量，如果其值可能随业务需求变化，使用
readonly也是一个更安全的选择。 对于引用类型字段，无论公私，只能使用
readonly，因为
const不支持引用类型（除了
string和
null）。
这个选择不仅仅是语法上的差异，更是对未来维护和生态系统兼容性的一种深思熟虑。它直接影响着你的API是否能够平滑演进，以及用户升级你的组件时会遇到多少麻烦。
