const在编译时确定值并内联，适用于永不改变的基本类型或字符串；readonly在运行时初始化，支持任意类型且更利于版本兼容，尤其适合可能变化的公共API常量。
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 显然是更灵活、更安全的方案。
选择 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演进留出足够的灵活性，避免给下游使用者带来不必要的重新编译负担。
在并发编程和多线程环境中，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;，那么 _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 是不够的，你还需要结合其他线程安全技术（如锁、不可变集合、原子操作等）来确保被引用对象的内部状态在并发访问下也是安全的。
在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是否能够平滑演进，以及用户升级你的组件时会遇到多少麻烦。
以上就是C#的常量与只读字段是什么？有什么区别？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
659
收藏
