1. 一个被悄悄改写的订单状态为什么我们需要只读约束先说一件我真实经历过的事。之前维护过一个订单处理系统核心类里有个字段叫OrderStatus用一个整型去表示状态0是待支付1是已支付2是已发货3是已完成。逻辑本身不复杂但架不住后期需求多陆续有同事在这个类里加各种辅助方法比如CheckInventory()、CalculateDiscount()、SyncExternalSystem()。某天线上出现了一个诡异的bug一笔订单在用户还没完成支付的时候状态居然变成了“已支付”而且金额、库存、优惠券记录全部对不上。查了半天最后定位到是SyncExternalSystem()里面做状态回写因为拿到的是一个共享的订单对象一不留神就把状态给改了。这个事件本身不是太复杂的技术问题但它带出了一个很有价值的问题我们怎么在代码层面让“不应该被修改的东西”从根本上无法被修改这就得聊到readonly关键字了。readonly是C#语言里一个非常简单但经常被低估的关键字。它的作用一句话可以概括修饰字段让这个字段只能在声明时或者在构造函数中被赋值其他任何地方都不能再改它。换句话说它把一个字段从“可变”变成“在对象整个生命周期内不可变”把误操作的可能性从语法层面就堵死了。这篇文章我会从基础语法讲起但重点不是给你背语法而是结合各种使用场景聊聊readonly在实际项目里到底怎么用、和const有什么区别、在引用类型上怎么做才真正安全、以及它跟volatile、static这些关键字怎么配合。无论你是刚入门C#的新手还是已经写了两三年、想在代码设计上更进一步的同学这篇都值得花十分钟读一遍。2. readonly的赋值时机与编译器在幕后做的事2.1 三种合法的赋值点位声明处、实例构造函数、静态构造函数readonly字段的赋值位置非常有限归纳起来就三类。第一类是声明时直接初始化这是最简单的写法public readonly int MaxRetryCount 3;第二类是在构造函数里赋值。实例字段就在实例构造函数里赋静态字段就在静态构造函数里赋。这里有个小细节很容易被忽略如果类里有多个构造函数每个构造函数都可以给readonly字段赋一次值不是只能在某一个构造函数里赋。编译器不要求每个构造函数都必须赋值它会通过“在构造函数返回前readonly字段必须被明确赋值”这个规则来做流分析。如果某个构造函数路径上完全没有赋值编译直接报错。public class Order { public readonly int OrderType; public Order() : this(1) { } public Order(int orderType) { OrderType orderType; } }第三类补充说明一下readonly字段不能在普通方法里赋值。即便你在方法里做判断、走分支、条件赋值统统不行这不是运行时的限制是编译器的硬性规定写不出来的那种。静态字段和实例字段在这点上是对称的static readonly只能在静态构造函数和声明处赋值实例构造函数里碰都不能碰。这个细节在一些项目里会导致一个烦恼如果一个配置你希望每个实例初始化的时候都读一次配置文件又想用readonly那只能把它设计成实例字段或者退一步不用readonly。2.2 编译器视角下readonly字段的IL形态很多资料只会说“readonly字段在运行时不能修改”其实更准确的是在编译后的IL中间语言层面readonly字段被标记成了initonly。JIT看到这个标记后会在执行期间拒绝普通代码对它赋值。不是因为微软做了魔法拦截而是JIT在编译方法时遇到了对initonly字段的存储操作会直接抛FieldAccessException。这也能解释为什么反射可以修改readonly字段后面第6章我会细讲绕过的操作因为反射本质上是在跳过JIT的静态检查直接向内存地址写入。而普通代码路径上JIT已经把它当成不可变数据了。2.3 readonly字段的本质是“引用被钉死”不代表内容被冻住这是整个关键字理解里最大的分水岭。那么readonly修饰引用类型字段比如数组、自定义对象、ListT表示的是什么表示的是这个字段里存的那个引用地址不能变——不能再new一个新的数组不能把变量指向另一个对象。但是数组的元素可以改ListT里的内容可以Add和Remove自定义对象的属性可以随便set。看这个例子public class OrderProcessor { public readonly Liststring Steps new Liststring(); public void Init() { // 编译错误 Steps new Liststring(); } public void AddStep(string step) { // 合法能编译过 Steps.Add(step); } }Steps new Liststring()这行会编译报错因为你要改的是字段本身。但Steps.Add()完全没有问题你只是在操作引用指向的那个对象。好到这里基础语义清楚了。接下来就到了最实用的选型问题readonly、const、static readonly到底该怎么选3. readonly、const、static readonly三兄弟的选型实战很多时候搞不清这几个关键字的人不是不懂语法而是不清楚技术决策背后的代价。我把它们放在一张表里直接对比。比较维度constreadonlystatic readonly赋值时机声明时声明时或构造函数声明时或静态构造函数确定值的时间编译期运行期首次构造对象或首次访问时运行期类型初始化时允许的数据类型基本类型、string、枚举任意类型任意类型存储位置编译后内嵌到IL常量值作为类字段存储作为静态字段存储修改是否需要重新编译所有引用程序集需要bug来源不需要改一个程序集即可不需要能否用于非基本类型的复杂对象不能能能是否每个实例都有一份不占用实例字段直接内嵌每个实例一份全局一份3.1 为什么const像潜伏的定时炸弹const的值在编译时就被直接替换到了每一处使用它的代码里这在多项目解决方案里会引出非常隐蔽的问题。比如你在A项目里定义了一个public const int DefaultPageSize 20;B项目引用了A项目并在代码里用了DefaultPageSize。B项目编译时A项目IL里的20直接被复制进了B项目的IL。这时候如果有一天你修改这个值为50只重新编译A项目而不重新编译B项目B项目里照样还是20。线上两台机器一台跑新的A程序集一台跑旧的B程序集行为直接不一致。当然有人会说“我每次都解决方案全量重新编译”。话是这么说但大型项目里发布节奏不同频的情况太多了。大家不要给自己埋这种雷。3.2 readonly在配置和常量场景下真正省心的地方readonly因为是运行期确定值改的时候只需要重新编译包含定义的那个程序集就够了依赖它的程序集不需要重新编译运行时会去读取新值。这一点在配置类型的场景上尤其好用。一个实际项目的例子我们以前做一个线下活动报名系统报名人数峰值限制、优惠截止日期这类配置全放在一个Config类里用静态只读字段暴露public class EventConfig { public static readonly int MaxAttendeeCount LoadFromConfig(Event:MaxAttendeeCount); public static readonly DateTime RegistrationDeadline LoadFromConfig(Event:RegistrationDeadline); private static int LoadFromConfig(string key) { // 从配置中心读取 int.TryParse(ConfigurationManager.AppSettings[key], out var val); return val; } }程序每次启动时从配置中心拿值静态构造函数在类型第一次被访问前执行一次之后整个进程生命周期内这个值都不会变。把“启动后不可变”和“每次启动可更新”这俩需求同时满足了。这个方案比藏着const里强太多也比每个方法都临时读配置效率高。3.3 一个容易被绕过的躲避检测的坑ref return要特别提醒一件事readonly字段本身不能改但如果你把它通过ref返回给调用方调用方拿到的就是这块内存的引用可以直接对它赋值。编译器在这个场景下有一些保护措施但如果你自己用ref声明局部变量去接收readonly字段的引用某些版本下仍然可能绕过去。public class Demo { private readonly int _value 10; public ref int Value ref _value; // 危险 }虽然新版本编译器对这类代码的警告越来越严格但写代码的时候还是要避免把readonly字段以ref形式对外暴露不然等于自己把锁打开了。这类隐患在代码评审阶段比较考验眼力正常的注意力不会放在这种边界上可一旦被利用字段的只读语义就名存实亡了。4. 引用类型上的只读陷阱别让数组骗了你4.1 一个数组的意外修改路径很多人天真地以为我声明了一个readonly数组就相当于数组内容也不能改了。这个误解导致的实际bug我见得太多。看这个例子public class ArticleService { public static readonly string[] DefaultTags { C#, 设计模式, 架构 }; }这个DefaultTags数组任何人都能往里面塞数据ArticleService.DefaultTags[0] PHP;编译能过运行不报错但你的默认配置已经在不知不觉中被污染了。如果这个数组还被多个线程同时读还会引发更复杂的可见性问题。那怎么处理按场景分如果只是想暴露一组只读的数据给外部使用用ReadOnlyCollectionT包装一下或者在返回数据时拷贝一份新数组。如果是预定义的一组固定值更稳妥的方案是使用不可变集合比如IImmutableListstring来自System.Collections.Immutable。如果数据量很小可以考虑直接用.NET 8里新增的FrozenSet这类不可变集合类型。4.2 用readonly struct实现真正不可变的对象从C# 7.2开始你可以给结构体加readonly修饰符这表示这个结构体的所有实例都是不可变的这个比字段级别的readonly更强硬它要保证的是整个对象层面的状态冻结。public readonly struct Money { public decimal Amount { get; } public string Currency { get; } public Money(decimal amount, string currency) { Amount amount; Currency currency; } }在这个结构体里所有属性都只能有getter没有setter字段必须是readonly的。这样设计出来的类型非常适合表示那些天然不可变的概念比如金额、日期范围、坐标等。作为方法参数或返回值时它会减少很多防御性拷贝读起来也放心。如果说字段级别的readonly是一把锁那readonly struct就是直接把这个类别的对象设计成保险箱——从构造函数返回的那一刻起内容就永远不会变了。4.3 组合拳引用字段 不可变容器我在实际项目里推荐的组合方式是对外暴露只读的访问入口内部维护一个真正不可变的数据源。public class ProductCatalog { private static readonly ProductInfo[] _products Initialize(); public static IReadOnlyListProductInfo Products _products; }这里Initialize()负责从数据库或配置文件中读取产品信息返回一个数组存进_products。对外暴露的Products用IReadOnlyListProductInfo接口承载调用方只能遍历和索引不能添加、删除也无法修改数组元素因为ProductInfo是只读类型。这种写法在只读语义、并发安全、性能之间做到了最好的平衡。5. 场景适配依赖注入、配置中心与多线程环境的readonly实战5.1 构造函数注入模式下readonly是标配现在主流的ASP.NET Core项目都用了依赖注入一个服务类的依赖项在构造函数里注入后续绝不更换。这种模式下用readonly来保存注入的服务是首选实践。public class OrderService { private readonly IOrderRepository _orderRepo; private readonly ILoggerOrderService _logger; private readonly IEventBus _eventBus; public OrderService(IOrderRepository orderRepo, ILoggerOrderService logger, IEventBus eventBus) { _orderRepo orderRepo; _logger logger; _eventBus eventBus; } }这样写的好处在于只要你看到readonly你就知道这个字段是在构造函数里被填进去的在整个服务生命周期内不会换日常开发里不可能有人不小心给它重新赋值。代码可读性和可维护性都直接提升一个档次。反过来如果这些依赖字段不带readonly后期很容易有人出于各种原因在某个方法里给它们重新赋值。这种操作一多依赖关系就乱套了单元测试时mock出来的行为可能在运行时被悄悄替换成真实实现调试起来极其痛苦。5.2 readonly和volatile的边界它们不能共存volatile关键字的作用是确保字段每次访问都从内存读取不经过CPU缓存同时保证访问顺序。它修饰的是字段的访问特性而readonly修饰的是字段的赋值约束。这两个关键字不能同时修饰同一个字段编译器会直接报错因为volatile意味着这个字段可能会在任何时候被其他线程修改而readonly恰恰相反它是说这个字段永远不能被修改。二者语义天然矛盾。实际使用中对一个标记为readonly的引用类型字段如果该对象内部有可变字段并且这些字段会跨线程访问那么只靠readonly是解决不了线程安全问题的。你需要对对象内部的可变成员加锁或者使用volatile——没错操作的是成员而不是那个只读引用本身。举个例子public class ServiceManager { private static readonly LazyServiceManager _instance new LazyServiceManager(() new ServiceManager(), LazyThreadSafetyMode.ExecutionAndPublication); private CacheEntry _currentCache; public CacheEntry CurrentCache Volatile.Read(ref _currentCache); }容器标记为readonly LazyT保证实例只会被创建一次LazyThreadSafetyMode.ExecutionAndPublication防止多个线程重复执行初始化逻辑。内部的_currentCache则用Volatile.Read来做读取保证拿到的永远是最新的缓存引用。readonly、LazyT、Volatile三者配合才是多线程场景下完整的武器组合。5.3 JIT优化与readonly字段别把性能神话化网上流传一种说法“readonly字段能被JIT内联优化性能更好。”这个说法有一定道理但不能神化。JIT在做常量传播和死代码消除时对readonly字段有时会比普通字段更激进但这只在特定情况下生效比如字段在构造函数里被赋值一个字面量常数并且JIT能证明构造完成后没人改它。对于复杂场景这种优化未必能触发。我个人的建议是不要为了性能而用readonly要为了设计正确性而用。反过来倒有一个性能隐藏项值得注意readonly字段和普通字段的内存布局差异非常小不会带来实质性的性能影响所以别在性能测试报告里写“改用readonly后请求耗时下降XX%”这种结论那是自欺欺人。5.4 配置热更新下的readonly困境如果你们的配置管理系统支持热更新比如Apollo配置中心的下发那readonly就不太适合直接用于配置字段了因为热更新意味着配置值可能在运行中被修改而readonly字段在运行期不可变。这时候一般选择IOptionsMonitorT这种模型它内部维护一个可以更新的配置值并在配置变化时通知订阅方。所以不要逢配置就用readonly先想清楚你的配置语义是“进程内只读”还是“支持动态刷新”。如果只是进程内只读、每次启动读取最新值static readonly就是最合适的如果需要动态刷新readonly反而不合适。这种“适配”才是真正的场景适配关键字本身是中性的工具关键是你要能判断它在不同场景下的适用边界。6. 稍微冷门但仍需知道的边界与同类关键字的区分6.1 反射可以修改readonly字段但它不是常规手段前面提到反射能改这里展开说一下。确实可以在运行时通过反射获取字段信息然后调用SetValue来修改一个readonly字段的值。运行时不强制拦截这种操作。var field typeof(Order).GetField(OrderType, BindingFlags.Instance | BindingFlags.NonPublic); field.SetValue(order, 999);这在单元测试中偶尔用到尤其是在测试老代码里那些没有给你留设置入口的私有readonly字段时可以用反射来注入特定行为。但生产代码里绝不应该这么干这等于绕过编译器布下的全部防线。如果你发现生产代码里有用反射改readonly字段的那基本可以断定它已经破坏了设计与其这样不如直接把字段改成普通可变字段至少让意图诚实一点。6.2 同名的“readonly”在不同领域的不同含义聊两个容易在排查问题时造成混乱的“同名不同义”场景。一个是操作系统里的文件只读属性Windows下用DOS命令attrib r给U盘或文件加只读属性这里的readonly或缩写r是文件系统的标志位跟C#的关键字没有半毛钱关系。有人网上搜“U盘定时执行set readonly的脚本”那是在处理文件系统权限问题不是C#开发问题。跑题说一句U盘被设了只读通常是物理写保护开关或磁盘属性被改了处理方式和编程完全是两码事。另一个是数据库里READONLY作为字段名的情况它可能是个保留字或关键字在SQL语句里需要加反引号转义比如MySQL里readonly才能作为列名或表名。这也跟C#里的readonly关键字无关但在一些跨语言团队里经常有人把几种场景搞混明明是一个数据库表名报错的问题却去代码里查readonly的用法浪费不少排查时间。遇到这种跨领域同名词汇的报错时先冷静确认你看到的关键字是在什么语言、什么平台、什么上下文中别一头扎进错误的方向。6.3 和老对手const、static、extern、volatile的关系梳理看相关热搜词的时候注意到很多人在搜static关键字的作用、const关键字、extern关键字的作用、volatile关键字的作用。这些关键字经常和readonly一起出现在面试题和实际代码中我简单梳理一下它们跟readonly的关系static修饰字段是“属于类型而非实例”和readonly可以组合成static readonly表示“类型级别、只读”。const编译期常量readonly是运行期常量两者是兄弟关系但千万别互换使用场景。extern用来声明外部实现的方法或字段一般用于调用非托管代码和readonly基本不属于同一战场但有时在互操作场景里会同时出现。volatile表示字段访问不走缓存和readonly不能同时用于同一字段。把它们画在一张关系图上的话static回答的是“属于谁”readonly回答的是“能不能改”const回答的是“何时确定值”volatile回答的是“怎么读”。各管一摊组合起来才能表达完整的设计意图。6.4 我长期使用readonly的一些习惯文章最后分享几个我自己这些年攒下的实践习惯算是给大家的一些参考。第一类里所有只在构造函数中赋值、之后不再变化的私有字段一律加readonly。这个习惯可以让代码的意图一目了然开发人员阅读代码时不用逐行分析字段在哪里被修改过只要看到readonly直接放心省下的心智负担在大型项目里非常可观。第二对外暴露集合时永远不要直接暴露数组或List 本身。用IReadOnlyListT、ReadOnlyCollectionT或者不可变集合。这个习惯能挡住绝大多数调用方误改内部数据的问题。第三代码评审时先扫一遍所有字段如果一个非readonly字段在对象生命周期里从未被重新赋值我会明确建议加readonly。这不是强迫症而是用最少量的代码改动来传递最强的意图约束。第四对配置类字段先明确配置更新的语义。进程内只读就用static readonly需要热更新就不要用readonly而去使用专门的配置监听模式。别让代码结构和真实的业务诉求相互打架。我踩过最痛的坑就是在以为读到了“最新配置”的地方因为图省事用了静态字段结果配置更新后服务不刷新线上数据从旧配置一直读到重启。后来老老实实用配置中心提供的监听接口把变化的配置实时推给订阅方代码是稍微多了一点但再没出过这种幺蛾子。readonly这个关键字本身没什么高深玄机真正的价值在于它帮你把设计约束落实到编译器层面让每一个后来的维护者都没机会不小心破坏初衷。在长期迭代、多人协作的工程环境里这种靠语言特性约束的底气是很值得认真对待的。