在C#开发体系中，const与readonly均用于声明不可变的数据成员，但两者的底层实现机制、内存分配策略以及适用边界存在显著差异。这一知识点不仅是日常编码中的高频考点，更是技术面试中检验开发者对语言底层理解深度的重要维度。许多工程师在实际项目中仅关注其表面不可修改的特性，却忽视了编译期内联替换与运行期动态初始化之间的根本分歧，往往导致在应对深度追问时无法给出严谨的解答。
编译期常量与运行时常量的本质区别
const关键字定义的变量属于严格的编译期常量。这意味着编译器在将源代码转换为中间语言IL的过程中，会直接将const的值硬编码到调用该常量的程序集中。因此，const修饰的成员必须在声明语句中进行赋值，且初始值必须是一个在编译阶段即可完全确定的常量表达式。由于这种内联替换的特性，const修饰的变量默认具备静态属性，无需也不能显式添加static关键字。一旦程序集被编译完成，代码中所有引用该const的位置都会直接变为具体的数值或字符串字面量，从而消除了运行时查找字段的开销，提升了执行效率。
相比之下，readonly关键字作用于运行时常量。它的值并非在编译期固定，而是在程序加载或对象实例化过程中动态计算得出。readonly成员允许在声明处赋值，同样也允许在类的构造函数内部进行赋值。这种灵活性使得同一个类在不同实例中可以拥有不同的readonly值。此外，readonly默认代表实例级别的状态，若希望该只读字段在整个应用程序域中共享，则必须配合static关键字使用。理解这两者在生命周期上的差异，是掌握C#内存模型与性能优化的关键前提。
从IL指令生成的角度来看，两者对最终生成的二进制文件影响截然不同。使用const会在反编译后的代码中看到直接的字面量替换，而使用readonly则会保留字段访问指令（如ldfld），并在运行时通过偏移量读取内存地址。这种差异直接决定了它们在调试体验、反射获取以及跨程序集引用时的行为表现，开发者必须根据实际运行环境的需求进行权衡。
// const定义示例
public class ConstDemo
{
// 必须初始化，编译期确定值
public const int MaxCount = 100;
public const string AppName = "TestApp";
// 错误示例：不能延迟初始化
// public const int MinCount;
}
// readonly定义示例
public class ReadonlyDemo
{
// 声明时初始化
public readonly int DefaultScore = 60;
// 构造函数中初始化，不同实例可以有不同值
public readonly string UserName;
public ReadonlyDemo(string name)
{
UserName = name;
}
// 静态只读字段
public static readonly DateTime StartTime;
static ReadonlyDemo()
{
StartTime = DateTime.Now;
}
}类型支持与静态特性的详细对照
在数据类型兼容性方面，const与readonly展现出截然不同的宽容度。const严格受限，仅支持基本值类型、枚举类型以及string类型。需要特别注意的是，虽然string属于引用类型，但由于其在C#设计中具有不可变性特征，因此被特许作为const的合法修饰对象。除此之外，const严禁修饰任何其他引用类型实例，也无法处理DateTime结构体，因为DateTime的构造过程涉及复杂的类型转换，无法满足编译期常量表达式的严苛要求。这种限制从根本上杜绝了编译期可能出现的歧义与安全隐患。
readonly则打破了上述枷锁，支持绝大多数数据类型，涵盖各类自定义类、集合类型以及结构体。对于引用类型的readonly字段而言，其核心约束在于引用地址本身不可变更，即无法将该字段重新指向另一个新的对象实例。然而，被引用的对象内部的属性状态依然允许通过公共接口进行修改。在静态特性层面，const隐式等同于static，而readonly默认为实例级字段。开发者必须根据业务需求明确选择是否需要跨实例共享数据，这直接影响着类的线程安全性设计与管理模式。
| 对比维度 | const | readonly |
|---|---|---|
| 赋值时机 | 编译期，必须声明时初始化 | 运行期，可声明时或构造函数初始化 |
| 静态特性 | 默认静态，无需static修饰 | 默认实例级，静态需加static |
| 支持类型 | 值类型（除DateTime）、string、枚举 | 所有类型 |
| 修改限制 | 完全不可修改，编译后直接替换值 | 只能在构造函数中修改，之后不可改 |
| 引用类型限制 | 仅支持string不可变类型 | 引用不可改，对象内容可改 |
综合上述对照表可以看出，const更适合用于构建绝对恒定、不随运行环境变化的基础数据层，而readonly则承担着封装动态计算结果与保护实例状态的核心职责。在现代软件开发中，随着配置中心与远程服务调用的普及，越来越多的值需要在启动阶段或首次请求时动态注入，此时readonly的灵活性优势便凸显出来，成为替代早期全局静态变量的最佳实践方案。
引用类型行为差异与典型应用场景
在处理复杂业务逻辑时，两者对引用类型的行为差异直接决定了架构设计的走向。const仅能绑定至string这类天生不可变的类型，一旦尝试将其应用于自定义类或数组，编译器将直接抛出错误。而readonly在管理引用类型时提供了更为细腻的粒度控制。当readonly字段指向一个可变对象时，外部代码无法替换该字段的指向，但可以通过公开的方法或属性访问器来修改对象内部的状态。这种半不可变的设计模式，在保护核心配置不被意外覆盖的同时，又保留了数据更新的灵活性，广泛应用于缓存管理与状态追踪场景。
public class Person
{
public string Name { get; set; }
}
public class RefTypeDemo
{
// 错误：const不能修饰非string的引用类型
// public const Person DefaultPerson = new Person();
// readonly修饰引用类型
public readonly Person ReadonlyPerson = new Person { Name = "初始" };
public void Test()
{
// 错误：引用不可修改
// ReadonlyPerson = new Person();
// 正确：引用对象的内容可以修改
ReadonlyPerson.Name = "修改后";
}
}在实际工程落地与技术面试问答中，合理选用const与readonly能够显著提升代码的可维护性并规避潜在的部署风险。若业务逻辑依赖数学常数、固定协议标识或硬编码的配置参数，且这些值在开发阶段即可完全确定，应当优先采用const。其内联机制不仅能降低运行时内存占用，还能避免因频繁读取引发的性能瓶颈。反之，当数值来源于外部配置文件、数据库查询结果，或需要根据构造函数传入的参数动态生成时，readonly是唯一合规的选择。此外，在涉及多程序集引用的大型分布式系统中，修改const的值会导致所有依赖该常数的程序集强制重新编译，极易引发版本碎片化；而readonly仅影响当前程序集的构建，大大降低了跨模块协作的耦合度。
针对常见的进阶追问，例如为何不能使用const声明DateTime类型，其根本原因在于结构体的构造函数在执行时依赖于系统时钟与内存分配，完全脱离了编译期常量表达式的范畴。面对此类需求，标准做法是改用static readonly组合进行替代。通过静态构造函数或声明处初始化，既能满足运行期计算的要求，又能保证后续生命周期的只读约束。掌握这两种修饰符的边界条件与底层原理，能够帮助开发者在编写高性能、高可靠性的C#应用时做出更精准的技术选型，从容应对各类复杂场景下的代码审查与架构评审。