从同步阻塞思维写一个高并发服务把所有 IO 都让线程死死占着一步步往下执行直到彻底完成、还为图省事在同步方法里用 .Result 等异步调用埋下 sync-over-async 反模式、一次促销流量只比平时高三四倍这种占着线程啥也不干的死等调用大量出现就把 IIS 线程池迅速占满耗尽线程池一空整个应用再没线程处理任何新请求守着 32 核服务器 CPU 闲在 5% 而所有 API 集体超时挂死 + 处理字符串数组挥霍内存毫无知觉解析报文用 Substring 一刀刀切每次都实打实分配新字符串拷贝一份拼接直接加号怼字节数组动不动 new 再 Array.Copy 在高频热路径上极短时间制造海量用完即弃的短命临时对象把 GC 喂到频繁暂停服务成片卡顿延迟毛刺 + JSON 序列化清一色 Newtonsoft 一把梭它靠运行时反射每次都探查类型动态读值在每秒序列化成千上万对象的高频服务里反射开销高居 CPU 热点榜还造一堆装箱临时垃圾反过来加剧 GC 卡顿 + 用 LINQ 却以为写下 Where 那行查询就执行完了根本不懂延迟执行把查询赋给变量先 Count 再 foreach 后 Any 同一查询被完整重跑三四遍又在循环里访问关联属性触发 N+1 一百个订单打一百零一次库直接打爆数据库 + 写服务类要用数据库 HTTP 日志就直接在类里 new 一个出来依赖被 new 死在内部绑死具体实现想换实现想测试注入 mock 都做不到测试只能连真库又慢又脆还自己手搓 static 单例埋多线程竞态 + 配置全堆 web.config 用 ConfigurationManager 字符串键去取键散落十几个文件改名漏一个就错把 SmtpHost 敲成 SmtpHsot 编译器毫不知情上线取出 null 才炸取出全是字符串还得自己 Parse + 引用类型默认可空类型完全不透露可空信息拿个参数无从知道会不会传 null 访问 order.Customer.Name 全凭运气 NullReferenceException 成了线上最阴魂不散的异常编译期毫无征兆全到线上特定路径才轰然爆发 + 应用被 .NET Framework 死死绑在 Windows 上只能上 Windows Server 装特定版本运行时还和别的应用共享互相牵制要配 IIS 管应用池环境稍不一致就诡异出错想上 Linux 容器享受云原生弹性精简门都没有 → 2026 现代 .NET 8 对所有 IO 用 async/await 全程异步 await 时线程被释放归还线程池服务别的请求同样线程数撑起高一个数量级并发 + Span 与 ReadOnlySpan 零拷贝切片 ArrayPool 租借复用缓冲把热路径分配压到极低 GC 压力骤降 + System.Text.Json 源生成器编译期生成直达序列化代码运行时零反射快且低分配还通 AOT + 吃透延迟执行该物化时一次 ToList 用 Include 预加载与 Select 投影根治 N+1 收敛成一次往返 + 内置 DI 容器构造函数注入只依赖接口可注入 mock 测试生命周期 Singleton/Scoped/Transient 由容器统一托管 + IConfiguration 加 IOptions 把一组配置强类型绑定到配置类属性强类型编译期可查分组归属清晰 + 开启可空引用类型把可空与否写进类型编译器流分析在编译期就揪出潜在 null 解引用逼你判空 + 迁到 .NET 8 跨平台用内置 Kestrel 宿主 self-contained 把运行时打包进产物容器把应用连同环境封成自给自足镜像一次构建哪都能跑接入 K8s 弹性伸缩 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学

我是一个 8 人 .NET 团队的技术负责人。我们手里这套支撑着公司核心业务的企业应用,跑在 .NET Framework 4.x 上,已经在 Windows Server + IIS 的环境里服役了八年。八年里,业务翻了几番,代码也从当年那套整洁的 MVC,长成了一坨同步阻塞、反射横飞、到处 new、配置散落、空引用满天飞的"祖传 C# 代码"。把我们彻底打醒的,是一次再普通不过的流量高峰:那天一个促销活动带来的并发只比平时高了三四倍,本不该出什么大事,可我们的 API 却在几分钟内集体超时、彻底挂死。事后排查,根因让人哭笑不得——代码里有一处在同步方法里用 .Result 去等一个异步调用(经典的 sync-over-async),平时并发低时它只是悄悄占着一个线程死等、没人察觉,可一旦并发上来,这种"占着线程啥也不干地死等"的调用大量出现,IIS 的线程池被这些苦等的线程迅速占满、耗尽,而线程池一耗尽,整个应用就再也没有线程去处理任何新请求了——不是某个接口慢,是所有接口在同一刻一起没了响应能力。我们守着一台 32 核的服务器,CPU 却闲在 5%,而 API 全线超时,荒谬到了极点。

那次事故之后,我们用 87 天打了一场把这套 .NET Framework 祖传应用现代化到 .NET 8 的攻坚战。这篇文章,是这 87 天的完整复盘:我们如何把同步阻塞的代码全程改造成 async/await、如何用 Span<T> 和对象池把 GC 压力压下去、如何用 System.Text.Json 源生成器取代又慢又吃内存的反射序列化、如何真正理解 LINQ 的延迟执行不再重复枚举、如何用内置 DI 容器和正确的生命周期取代满地的 new、如何用 IConfiguration 和 Options 模式收拾散落的配置、如何用可空引用类型在编译期就揪出空引用、以及如何把这套绑死 Windows 的应用迁移成跨平台容器化的 .NET 8 服务。我们沉淀了 47 套工程修法、7 个 P0 事故复盘和 6 条工程哲学。先看这场现代化前后的整体对比:

下面这张图,是我们现代化后一个请求在 .NET 8 里的处理全景——从 Kestrel 接入、走异步中间件管道、由 DI 容器解析服务、到全程异步的处理与数据访问,以及内存、序列化、诊断如何贯穿其间:

一、异步编程:从同步阻塞 .Result 占着线程死等高并发线程池耗尽全挂到 async/await 全程异步非阻塞

第一仗,也是直接源于那次线程池耗尽事故的一仗,是把代码里那些同步阻塞、占着线程死等的调用,彻底改造成 async/await 全程异步、在等待时主动释放线程的非阻塞模型。古早时代我们写代码,脑子里是一种最朴素的同步思维:一个操作,无论它是计算还是等待网络/数据库 IO,我们都让当前线程一直占着、一步步往下执行,直到它彻底完成。这种思维落到那些本质是"等待"的 IO 操作上,就酿成了大祸:一个数据库查询、一次远程 HTTP 调用,真正的耗时几乎全花在"等对方返回"上,这期间 CPU 其实无事可做,可我们的同步代码却让一个宝贵的线程死死地占着、干等着这个 IO 返回,什么也不干、也不释放。更糟的是,我们的代码库里混着同步和异步,而开发者为了在同步方法里调用一个异步方法图省事,大量地写下了 task.Result 或 task.Wait() 这种"sync-over-async"的反模式——它会让当前线程阻塞着去等一个异步任务完成,不但占着线程,在 ASP.NET 经典的同步上下文里还极易引发死锁。这一切在低并发时风平浪静,可一旦并发上来,海量请求每个都占着一个线程在那里死等 IO,服务器的线程池(线程是很重、数量有限的资源)被迅速占满耗尽,而线程池一空,整个应用就丧失了处理任何新请求的能力,于是出现了我们那次事故里 CPU 闲到 5% 而 API 却全线超时挂死的荒诞景象——不是算不过来,是没线程可用了。现代做法是拥抱 async/await 的异步非阻塞模型:对所有 IO 操作,都使用其异步版本(如 await dbContext.SaveChangesAsync()、await httpClient.GetAsync()),关键在于,当代码 await 一个 IO 操作时,当前这个线程并不会傻等,而是被立刻释放、归还给线程池去服务其他请求,等到那个 IO 真正完成了,运行时再从线程池取一个线程来继续执行 await 之后的代码。如此一来,同样数量的线程,在异步模型下能同时"在飞"地处理成百上千个正在等待 IO 的请求(因为等待期间根本不占线程),线程池再也不会被大量等待 IO 的请求占满耗尽,我们用同样的硬件,支撑起了高出一个数量级的并发吞吐。下面是异步编程的对比:

// 重构前:同步阻塞 + sync-over-async,每个请求占着一个线程死等 IO,高并发线程池耗尽全挂
public IActionResult GetOrder(int id)
{
    var order = _db.Orders.Find(id);              // 同步:线程死等数据库 IO,期间什么也不干
    var detail = _httpClient
        .GetStringAsync($"/detail/{id}").Result;  // sync-over-async 反模式!占线程死等,还易死锁
    return Ok(new { order, detail });
}
// ↑ 真正耗时全在"等 IO 返回",CPU 闲着,线程却被占死 → 并发一高,线程池被占满耗尽 → 全线超时挂死

// 重构后:async/await 全程异步,await IO 时线程被立刻释放归还线程池去服务别的请求
public async Task GetOrder(int id)
{
    var order = await _db.Orders.FindAsync(id);            // await 期间线程被释放,不占线程干等
    var detail = await _httpClient.GetStringAsync($"/detail/{id}");  // 全程异步,无阻塞无死锁
    return Ok(new { order, detail });
}
// ↑ 同样的线程数,能同时"在飞"处理成百上千个正在等 IO 的请求 → 线程池不再耗尽,吞吐高一个数量级

异步编程现代化让我们从"写代码脑子里是一种最朴素的同步思维一个操作无论它是计算还是等待网络数据库 IO 都让当前线程一直占着一步步往下执行直到它彻底完成、这种思维落到那些本质是等待的 IO 操作上就酿成了大祸一个数据库查询一次远程 HTTP 调用真正的耗时几乎全花在等对方返回上这期间 CPU 其实无事可做可我们的同步代码却让一个宝贵的线程死死地占着干等着这个 IO 返回什么也不干也不释放、更糟的是开发者为了在同步方法里调用异步方法图省事大量地写下了 task.Result 或 task.Wait 这种 sync-over-async 的反模式它会让当前线程阻塞着去等一个异步任务完成不但占着线程在经典的同步上下文里还极易引发死锁、一旦并发上来海量请求每个都占着一个线程在那里死等 IO 服务器的线程池被迅速占满耗尽而线程池一空整个应用就丧失了处理任何新请求的能力出现了 CPU 闲到 5% 而 API 却全线超时挂死的荒诞景象"进化到了"拥抱 async/await 的异步非阻塞模型对所有 IO 操作都使用其异步版本关键在于当代码 await 一个 IO 操作时当前这个线程并不会傻等而是被立刻释放归还给线程池去服务其他请求等到那个 IO 真正完成了运行时再从线程池取一个线程来继续执行 await 之后的代码同样数量的线程在异步模型下能同时在飞地处理成百上千个正在等待 IO 的请求线程池再也不会被大量等待 IO 的请求占满耗尽":过去我们的代码之所以会被一次寻常的流量高峰打挂,是因为我们对线程这个资源的本质有着根本性的误解——我们把线程当成了取之不尽的廉价东西,以为让它占着干等一会儿 IO 没什么大不了,却没意识到线程是一种极其昂贵且有限的资源,每个线程都要吃掉相当可观的内存栈空间、线程池里能有的线程数是很有限的,而我们那种"一个请求从头到尾霸占一个线程、哪怕在等 IO 时也死占着不放"的同步模型,本质上是用最稀缺的资源(线程)去消磨最不需要它的时间段(等待 IO 的纯空耗),这是一种极度的资源错配,在低并发时这种浪费被海量的空闲线程掩盖着、看不出问题,可一旦并发上来、请求数逼近线程池上限,这种"占着线程啥也不干"的浪费就瞬间致命——线程被等待 IO 的请求占满,新请求再无线程可用,服务整体失能;后来我们才真正理解了异步的精髓——它的核心不是让单个操作变快,而是在等待 IO 的那段时间里,把宝贵的线程释放出来去服务别人,让有限的线程不再被空耗在等待上,于是我们把所有的 IO 操作都换成了 await 的异步版本,await 的那一刻,当前线程不再死等、而是被归还线程池去服务其他嗷嗷待哺的请求,IO 完成后再取一个线程继续,如此一来,线程这个稀缺资源被精准地只用在真正需要 CPU 干活的时刻、而绝不浪费在纯等待上,同样的一池线程,便能同时托起成百上千个正在等待 IO 的请求,我们用同样的硬件撑起了高出一个数量级的并发,也彻底告别了那种 CPU 闲着而线程池耗尽全挂的荒诞。我们的纪律是"绝不在 IO 操作上用同步阻塞让线程占着死等、绝不写 .Result/.Wait 这种 sync-over-async 反模式埋下线程池耗尽与死锁的雷,必须对所有 IO 操作使用 async/await 的异步版本、让线程在 await 等待 IO 期间被释放归还线程池去服务别的请求,必须把异步一路贯穿到底而非中途同步阻塞,要深刻认识到线程是昂贵有限的资源绝不能浪费在纯等待上,把 async/await 全程异步当成在有限线程上撑起高并发吞吐的根本来对待"。异步编程的本质认知是:线程是昂贵且有限的资源,而同步阻塞模型让一个请求从头到尾霸占一个线程、哪怕在等待 IO 时也死占不放,这是用最稀缺的资源去消磨最不需要它的纯等待时间,低并发时被空闲线程掩盖、高并发时则瞬间因线程池耗尽而全线失能;异步编程的智慧,在于用 async/await 让线程在 await 等待 IO 的那段时间被释放归还线程池去服务他人,把线程这一稀缺资源只用在真正需要 CPU 的时刻而绝不浪费在等待上,从而让同样的一池线程同时托起成百上千个在等 IO 的请求,会写 .NET 的团队,凡 IO 必异步、且把异步一路贯穿到底,因为他们深知,在一个 IO 密集的服务里,同步阻塞不是慢一点的问题,而是一颗会在某次寻常流量高峰下让整个服务因线程池耗尽而集体猝死的定时炸弹。

二、内存与 GC:从 Substring 数组拷贝制造海量临时对象 GC 频繁卡顿到 Span<T> 对象池零拷贝少分配

第二仗,是把代码里那些动不动就 Substring、就拷贝数组、就拼接字符串、制造出海量短命临时对象、把 GC 累得频繁卡顿的写法,改造成用 Span<T>、Memory<T>、ArrayPool 零拷贝切片、复用缓冲的低分配写法。古早时代我们处理字符串和数组数据时,挥霍内存挥霍得毫无知觉:解析一个报文,我们用 str.Substring() 一刀一刀地切,而每一次 Substring 在老 .NET 里都会实实在在地分配一个全新的字符串、把那段字符拷贝一份;拼接字符串我们直接用 + 在循环里怼,每拼一次就生成一个新的中间字符串;处理字节数组我们动不动就 new byte[] 再 Array.Copy 拷来拷去。在一个高频调用的热路径上,这种写法会在极短时间内制造出海量的、用完即弃的短命临时对象,而这些垃圾对象,全都要由 GC(垃圾回收器)去清理——GC 一旦被这么多垃圾喂得频繁触发,尤其是触发那种会暂停所有应用线程的回收时,我们的服务就会出现一阵一阵肉眼可见的卡顿、延迟毛刺,吞吐也被 GC 的开销硬生生拖下去一大截。现代做法是善用 .NET 现代的低分配利器:其一,Span<T> 与 ReadOnlySpan<T>——它是一个指向一段连续内存的"视图",对字符串/数组做切片(如 str.AsSpan().Slice(2, 5))时,它根本不分配新内存、不拷贝任何数据,只是记录"从哪开始、多长"这两个数字,我们能在完全不产生垃圾的情况下对数据切来切去、解析处理;其二,ArrayPool<T>——对于那些需要临时大数组缓冲的场景,不再每次都 new 一个用完就扔,而是从一个共享的数组池里租一个、用完再还回去,让数组被反复复用,把分配次数压到极低;其三,用 StringBuilder 或现代的字符串插值取代循环里的 + 拼接。如此一来,那些曾经在热路径上喷涌而出的海量临时对象被大幅消除,GC 的压力陡然减轻、回收频率和暂停大幅下降,服务的延迟毛刺被抹平、吞吐显著回升。下面是内存与 GC 的对比:

// 重构前:Substring/数组拷贝/+拼接,热路径上喷涌出海量短命临时对象 → GC 频繁触发、卡顿毛刺
public long SumFields(string line)   // 形如 "12,34,56,78..." 的高频解析热路径
{
    long sum = 0;
    string[] parts = line.Split(',');        // 分配一个数组 + 每个子串都是新分配的字符串拷贝
    foreach (var p in parts)
        sum += long.Parse(p.Substring(0));   // Substring 又各分配一个新字符串
    return sum;                              // ↑ 一次调用制造一大把垃圾,高频下 GC 被喂到频繁暂停
}

// 重构后:Span 零拷贝切片解析,全程不分配新字符串/数组,GC 压力骤降
public long SumFields(ReadOnlySpan line)
{
    long sum = 0;
    while (!line.IsEmpty)
    {
        int comma = line.IndexOf(',');
        var field = comma < 0 ? line : line.Slice(0, comma);  // Slice 只是"视图",不分配不拷贝
        sum += long.Parse(field);                              // 直接解析 span,零中间字符串
        line = comma < 0 ? ReadOnlySpan.Empty : line.Slice(comma + 1);
    }
    return sum;
}
// 需要临时大缓冲时用 ArrayPool 租借复用,而非每次 new 一个用完即扔:
// byte[] buf = ArrayPool.Shared.Rent(8192); try { /* 用 buf */ } finally { ArrayPool.Shared.Return(buf); }
// ↑ 热路径上的海量临时对象被消除,GC 回收频率与暂停大幅下降,延迟毛刺抹平、吞吐回升

内存与 GC 现代化让我们从"处理字符串和数组数据时挥霍内存挥霍得毫无知觉解析一个报文用 Substring 一刀一刀地切而每一次 Substring 在老 .NET 里都会实实在在地分配一个全新的字符串把那段字符拷贝一份拼接字符串直接用加号在循环里怼每拼一次就生成一个新的中间字符串处理字节数组动不动就 new 再 Array.Copy 拷来拷去、在一个高频调用的热路径上这种写法会在极短时间内制造出海量的用完即弃的短命临时对象而这些垃圾对象全都要由 GC 去清理 GC 一旦被这么多垃圾喂得频繁触发尤其是触发那种会暂停所有应用线程的回收时服务就会出现一阵一阵肉眼可见的卡顿延迟毛刺吞吐也被 GC 的开销硬生生拖下去一大截"进化到了"善用 .NET 现代的低分配利器 Span 与 ReadOnlySpan 它是一个指向一段连续内存的视图对字符串数组做切片时根本不分配新内存不拷贝任何数据只是记录从哪开始多长这两个数字、ArrayPool 对于需要临时大数组缓冲的场景不再每次都 new 一个用完就扔而是从一个共享的数组池里租一个用完再还回去让数组被反复复用、用 StringBuilder 或字符串插值取代循环里的加号拼接那些曾经在热路径上喷涌而出的海量临时对象被大幅消除 GC 的压力陡然减轻回收频率和暂停大幅下降":过去我们之所以在内存上如此挥霍,是因为 .NET 有自动垃圾回收这层舒适的保护垫,它让我们彻底不用操心内存的分配和释放、想 new 就 new、想切就切,这种便利是把双刃剑——它解放了我们不必像 C/C++ 那样手动管理内存,却也悄悄地麻痹了我们对"每一次分配都是有代价的"这件事的感知,我们写下一个 Substring、一个字符串加号拼接时,根本意识不到背后是一次实打实的堆内存分配、是给 GC 又添了一份将来要清理的垃圾,我们以为有 GC 兜底就可以无限地、免费地制造对象,却忘了 GC 本身的清理工作是要消耗 CPU、甚至要暂停整个应用的,我们前面图的省事(随手分配),最终都变成了 GC 后面要替我们偿还的债(频繁回收和暂停);后来我们才真正理解,自动 GC 免除的是我们手动释放内存的负担、而绝不是我们克制分配的责任,一个有性能追求的 .NET 程序员,恰恰要对内存分配保持高度的敏感,尤其是在那些每秒被调用成千上万次的热路径上,一次看似微不足道的分配,乘以巨大的调用频次,就是压垮 GC 的海量垃圾,于是我们学会了用 .NET 现代的低分配工具去釜底抽薪:用 Span<T> 这种不分配、不拷贝、只记录起止的内存视图去做切片和解析,让原本要 new 一堆中间字符串才能完成的处理,变成在原始内存上零垃圾地腾挪;用 ArrayPool 把那些临时大缓冲从"用完即弃"变成"租借复用",把反复的分配收敛成对一池缓冲的循环利用;再用 StringBuilder 收拾循环拼接,如此一来,热路径上那条曾经喷涌不止的垃圾洪流被我们从源头掐断,GC 不再被海量短命对象喂得频繁暂停,服务的延迟毛刺被抹平、吞吐稳稳回升。我们的纪律是"绝不在高频热路径上无节制地用 Substring 数组拷贝循环加号拼接去制造海量短命临时对象把 GC 喂到频繁暂停,必须用 Span/ReadOnlySpan 做零拷贝不分配的切片与解析、用 ArrayPool 租借复用临时大缓冲而非用完即扔、用 StringBuilder 取代循环拼接,要深刻认识到自动 GC 免除的是手动释放内存的负担而非克制分配的责任、热路径上每一次分配乘以巨大频次都是压垮 GC 的债,把低分配的内存意识当成 .NET 高性能服务的基本功来对待"。内存与 GC 的本质认知是:自动垃圾回收解放了我们手动释放内存的负担,却也麻痹了我们对每一次分配都有代价的感知,而在高频热路径上随手的 Substring、拷贝、加号拼接,乘以巨大的调用频次就是喂给 GC 的海量垃圾、是它日后用频繁回收和应用暂停来偿还的债;内存优化的智慧,在于明白 GC 免除的是释放内存的负担而非克制分配的责任——用 Span<T> 做零拷贝不分配的切片解析、用 ArrayPool 把临时缓冲从用完即弃变为租借复用、用 StringBuilder 收拾拼接,从源头掐断热路径上的垃圾洪流,会写高性能 .NET 的团队,对热路径上的每一次分配都保持敏感,因为他们深知,在一个高频服务里,真正拖垮性能的往往不是算法,而是那些被自动 GC 的舒适掩盖着、却在背后疯狂制造垃圾、把 GC 累到频繁暂停整个应用的随手分配。

三、序列化:从 Newtonsoft.Json 运行时反射又慢又吃内存还产生大量垃圾到 System.Text.Json 源生成器编译期生成快且低分配

第三仗,是把项目里无处不在的 Newtonsoft.Json(Json.NET)序列化,换成 System.Text.Json 配合源生成器(Source Generator)的现代方案。古早时代我们做 JSON 序列化反序列化,清一色 JsonConvert.SerializeObject() 和 JsonConvert.DeserializeObject<T>() 一把梭,它确实好用、功能全,可它的工作原理是运行时反射——每次序列化一个对象,它都要在运行时通过反射去探查这个类型有哪些属性、是什么类型、有没有特性标注,然后再动态地一个个把属性值读出来拼成 JSON。这套反射机制在一个 API 网关、一个每秒要序列化成千上万个对象的高频服务里,代价是惊人的:反射本身就慢(比直接访问属性慢一个数量级),而且反射过程中还会产生大量的临时对象和装箱拆箱,给本就紧张的 GC 又添了一大笔垃圾。我们那台服务器的性能剖析报告里,JSON 序列化的反射开销常年高居 CPU 热点榜前列,而它产生的垃圾又反过来加剧了我们第二仗里说的 GC 卡顿。现代做法是拥抱 .NET 内置的 System.Text.Json,并开启它的杀手锏——源生成器:我们只需定义一个继承 JsonSerializerContext 的 partial 类、用 [JsonSerializable(typeof(T))] 把要序列化的类型标注上,编译器就会在编译期为这些类型生成专门的、直接读写属性的序列化代码,运行时根本不需要任何反射——序列化时走的是编译期就写死的、像手写一样高效的直达代码。这样一来,序列化既快(没有反射开销)又省(几乎不产生反射带来的临时垃圾),而且因为代码是编译期生成的,它还天然支持 AOT 编译(Native AOT),为我们后面跨平台精简部署铺平了路。下面是序列化的对比:

// 重构前:Newtonsoft.Json 运行时反射,每次序列化都反射探查类型、慢且产生大量临时垃圾
using Newtonsoft.Json;

public string ToJson(Order order)
{
    return JsonConvert.SerializeObject(order);   // 运行时反射:探查属性→动态读值→拼 JSON
}                                                // ↑ 高频热路径上反射开销巨大,还喂给 GC 一堆装箱/临时对象

public Order FromJson(string json)
{
    return JsonConvert.DeserializeObject(json);  // 同样反射,慢且吃内存
}

// 重构后:System.Text.Json + 源生成器,编译期生成直达序列化代码,运行时零反射、快且低分配
using System.Text.Json;
using System.Text.Json.Serialization;

[JsonSerializable(typeof(Order))]                 // 标注要序列化的类型
public partial class AppJsonContext : JsonSerializerContext { }  // 编译期为它生成序列化代码

public string ToJson(Order order)
{
    return JsonSerializer.Serialize(order, AppJsonContext.Default.Order);  // 走编译期生成的代码,零反射
}

public Order? FromJson(string json)
{
    return JsonSerializer.Deserialize(json, AppJsonContext.Default.Order); // 直达、快、低分配,还支持 AOT
}
// ↑ 没有运行时反射,序列化既快又几乎不产生垃圾,GC 压力进一步下降,且天然支持 Native AOT

序列化现代化让我们从"做 JSON 序列化反序列化清一色 JsonConvert 一把梭它确实好用功能全可它的工作原理是运行时反射每次序列化一个对象都要在运行时通过反射去探查这个类型有哪些属性是什么类型有没有特性标注然后再动态地一个个把属性值读出来拼成 JSON、这套反射机制在一个每秒要序列化成千上万个对象的高频服务里代价是惊人的反射本身就慢而且反射过程中还会产生大量的临时对象和装箱拆箱给本就紧张的 GC 又添了一大笔垃圾 JSON 序列化的反射开销常年高居 CPU 热点榜前列而它产生的垃圾又反过来加剧了 GC 卡顿"进化到了"拥抱 .NET 内置的 System.Text.Json 并开启它的杀手锏源生成器只需定义一个继承 JsonSerializerContext 的 partial 类用 JsonSerializable 把要序列化的类型标注上编译器就会在编译期为这些类型生成专门的直接读写属性的序列化代码运行时根本不需要任何反射序列化时走的是编译期就写死的像手写一样高效的直达代码这样序列化既快又省而且因为代码是编译期生成的它还天然支持 AOT 编译":过去我们对 Newtonsoft.Json 的依赖之深、用得之随意,本质上是因为我们把序列化当成了一件理所当然免费的小事,从没意识到在一个高频服务里它其实是个吃 CPU、造垃圾的大户,更没意识到它慢和费的根源——运行时反射——其实是可以被彻底消除的,我们一直以为序列化要灵活通用就必须靠反射在运行时动态地探查类型,这是无法避免的代价;后来 .NET 用源生成器给了我们一个全新的答案——既然要序列化的类型在编译期就已经确定了,那为什么还要等到运行时再用反射去吃力地探查它?完全可以在编译的时候,就为每个已知类型生成好专门的、直接读写其属性的序列化代码,把运行时的反射探查彻底前移、消灭在编译期,于是我们用 System.Text.Json 的源生成器,把过去那个每次调用都要反射一遍、又慢又造垃圾的通用序列化器,换成了一份份编译期就为具体类型量身生成的、像手写般高效的直达代码,序列化这件事从此既不吃 CPU 也不造垃圾,还顺带打通了 Native AOT 的路,我们才真正理解,很多我们以为必须在运行时付出的动态代价,其实都可以靠编译期的代码生成提前偿清。我们的纪律是"绝不在高频服务里无脑用 Newtonsoft.Json 的运行时反射序列化去吃 CPU 造垃圾,必须用 System.Text.Json 配合源生成器把序列化代码在编译期生成、运行时零反射,要深刻认识到很多运行时的动态代价都可以靠编译期代码生成提前消除,把源生成序列化当成既提性能又低分配还通 AOT 的现代基本功来对待"。序列化的本质认知是:Newtonsoft.Json 的灵活通用建立在运行时反射之上,而反射在高频热路径上既慢又造垃圾,是被我们长期忽视的 CPU 热点与 GC 负担;序列化优化的智慧,在于明白要序列化的类型编译期就已确定、根本无需运行时再反射探查——用 System.Text.Json 源生成器把序列化代码前移到编译期生成,运行时走直达代码零反射,既快又低分配还通 Native AOT,会写高性能 .NET 的团队,把热路径上的序列化反射当成必须消除的开销,因为他们深知,编译期能做的事绝不留到运行时,运行时省下的每一次反射,都是高频服务里实打实的吞吐与稳定。

四、LINQ 与延迟执行:从不懂延迟执行同一查询被重复枚举多次 N+1 满天飞到理解延迟执行该物化时一次 ToList 用投影避免 N+1

第四仗,是把团队对 LINQ 的"想当然"用法,纠正成真正理解延迟执行(Deferred Execution)的正确用法。古早时代我们用 LINQ 用得很爽,但很多人对它有一个致命的误解——以为写下 var query = list.Where(x => ...) 这一行,查询就立刻执行完、query 里就装着结果了。事实恰恰相反:LINQ 的查询是延迟执行的,Where、Select 这些操作符返回的只是一个"查询的描述"(一个 IEnumerable),它本身并不执行任何遍历,真正的执行被推迟到你去枚举它的那一刻(比如 foreach 它、或对它调 Count()、ToList())。不理解这一点,会酿成两类典型灾难:其一是重复枚举——我们把一个 LINQ 查询赋给一个变量,然后在代码里先 query.Count() 一下、再 foreach (query) 一遍、后面又 query.Any() 一下,我们以为只查了一次,实际上每一次对 query 的枚举,背后那个 Where 过滤、那个数据库查询,都被完完整整地重新执行了一遍,一个本该一次的查询被我们无意中跑了三四遍;其二是更可怕的 N+1 查询——在 EF 这种 ORM 里,我们 foreach 一个订单列表(1 次查询),然后在循环体里访问每个订单的 order.Customer.Name(由于延迟加载,每访问一次就又触发一次单独的数据库查询),100 个订单就是 1+100 次数据库往返,在数据量稍大时直接把数据库打爆。现代做法是真正吃透延迟执行:其一,当一个查询结果要被多次使用时,果断用 .ToList() 把它一次性物化成内存里的实际集合,后续对这个 List 的多次遍历就只是在内存里转、绝不再重复打数据库;其二,用投影(Select)和预加载(EF 的 Include)来根治 N+1——要么用 Include(o => o.Customer) 让 EF 把关联数据在一次查询里 JOIN 出来,要么直接用 Select 把需要的字段投影成一个扁平的 DTO,让数据库一次性把所有需要的数据查回来。下面是 LINQ 与延迟执行的对比:

// 重构前:不懂延迟执行,同一查询被重复枚举多次 + 循环里触发 N+1 查询,把数据库打爆
var query = _db.Orders.Where(o => o.Amount > 100);  // 这行不执行!只是个"查询描述"

int count = query.Count();        // 第 1 次执行整个查询(打一次数据库)
foreach (var o in query)          // 第 2 次又把整个查询重新执行一遍!(又打一次数据库)
{
    // 延迟加载:每访问一次 o.Customer 就单独再查一次库 → 100 个订单 = 1+100 次往返(N+1)
    Console.WriteLine($"{o.Id} {o.Customer.Name}");
}
bool any = query.Any();           // 第 3 次又执行一遍!同一查询被跑了三遍

// 重构后:该物化时一次 ToList,用 Include/投影根治 N+1,查询只打一次数据库
var orders = _db.Orders
    .Where(o => o.Amount > 100)
    .Include(o => o.Customer)     // 预加载:一次 JOIN 把关联客户查出来,杜绝 N+1
    .Select(o => new OrderDto     // 投影:只取需要的字段,数据库一次性查回扁平结果
    {
        Id = o.Id,
        CustomerName = o.Customer.Name
    })
    .ToList();                    // 一次物化成内存集合,后续多次遍历都在内存里转,不再重复打库

int count2 = orders.Count;        // 内存里数个数,零数据库往返
foreach (var o in orders) { /* ... */ }   // 内存遍历,零数据库往返
// ↑ 一次查询、一次往返,N+1 被 Include/投影根除,重复枚举被 ToList 物化消除

LINQ 现代化让我们从"用 LINQ 用得很爽但很多人对它有一个致命的误解以为写下 var query = list.Where 这一行查询就立刻执行完 query 里就装着结果了、事实恰恰相反 LINQ 的查询是延迟执行的 Where Select 这些操作符返回的只是一个查询的描述它本身并不执行任何遍历真正的执行被推迟到你去枚举它的那一刻、不理解这一点会酿成两类典型灾难其一是重复枚举把一个查询赋给变量然后先 Count 一下再 foreach 一遍后面又 Any 一下以为只查了一次实际上每一次枚举背后那个数据库查询都被完完整整地重新执行了一遍、其二是更可怕的 N+1 查询 foreach 一个订单列表然后在循环体里访问每个订单的关联属性由于延迟加载每访问一次就又触发一次单独的数据库查询 100 个订单就是 1+100 次往返在数据量稍大时直接把数据库打爆"进化到了"真正吃透延迟执行当一个查询结果要被多次使用时果断用 ToList 把它一次性物化成内存里的实际集合后续对这个 List 的多次遍历就只是在内存里转绝不再重复打数据库、用投影 Select 和预加载 Include 来根治 N+1 要么用 Include 让 EF 把关联数据在一次查询里 JOIN 出来要么直接用 Select 把需要的字段投影成一个扁平的 DTO 让数据库一次性把所有需要的数据查回来":过去我们之所以在 LINQ 上栽这么多跟头,是因为 LINQ 的语法实在太像在操作一个已经装好数据的集合了,它优雅地掩盖了背后究竟是在内存里转、还是在打数据库,究竟是已经执行了、还是只是描述了一个待执行的查询,这种声明式的优雅是把双刃剑——它让我们写得行云流水,却也让我们彻底看不见每一行 LINQ 背后真实的执行代价,我们对着一个 IQueryable 写 Count、写 foreach、写 Any,以为都是在操作同一份现成的数据,殊不知每一次枚举都是一次真实的数据库往返,我们在循环里轻松地点出一个 order.Customer.Name,以为只是访问个内存属性,殊不知每一次点出都是一条偷偷发出的 SQL;后来我们才真正理解,LINQ 的延迟执行不是一个可以忽略的语言细节,而是决定一段查询代码到底打几次数据库、是优雅高效还是性能灾难的分水岭,理解了它,我们才知道什么时候该用 ToList 把查询果断物化、好让后续的多次使用都在内存里廉价地完成而不再反复打库,才知道要用 Include 和投影把那些藏在循环里、一条条偷偷溜出去的 N+1 查询,收拢成一次把数据 JOIN 齐、查全的高效往返,我们这才把 LINQ 从一个看不清代价的黑盒,用回了一个每一次数据库访问都心里有数的利器。我们的纪律是"绝不在不理解延迟执行的情况下对同一个 LINQ 查询反复枚举导致它被重复执行多次打库、绝不在循环里访问关联属性触发 N+1 查询把数据库打爆,必须在查询结果要被多次使用时用 ToList 一次性物化、必须用 Include 预加载和 Select 投影把关联数据收拢成一次查询根治 N+1,要深刻认识到 LINQ 的声明式优雅掩盖了背后真实的执行代价,把吃透延迟执行当成每一次数据库访问都心里有数的查询基本功来对待"。LINQ 与延迟执行的本质认知是:LINQ 声明式的优雅掩盖了一段查询背后究竟在内存转还是在打数据库、究竟已执行还是只描述,而不理解延迟执行就会把一次查询无意中跑成三四遍、把关联访问跑成 N+1 把数据库打爆;LINQ 优化的智慧,在于看穿这层优雅、对每一次枚举的真实代价心里有数——结果要多次用就 ToList 一次物化让后续在内存里廉价遍历、用 Include 预加载和 Select 投影把关联数据收拢成一次往返根治 N+1,会写高效数据访问的团队,对每一行 LINQ 背后打几次库都了然于胸,因为他们深知,看不清代价的声明式查询,会在数据量长大的某天,把数据库用一堆本可避免的重复往返和 N+1 悄悄压垮。

五、依赖注入与生命周期:从到处手动 new 强耦合难测试还自己手搓单例满是隐患到内置 DI 容器构造注入生命周期由容器管

第五仗,是把代码里那种到处手动 new、把依赖硬编码进每个类、还自己手搓单例的强耦合写法,改造成用 .NET 内置 DI 容器做构造函数注入、把对象的创建和生命周期都交给容器管理。古早时代我们写一个服务类,它要用到数据库访问、要用到 HTTP 客户端、要用到日志,我们的做法简单粗暴——直接在类里 new 一个出来:private readonly OrderRepository _repo = new OrderRepository(new SqlConnection(...));。这一行 new 把灾难悄悄埋下了:其一,强耦合——这个服务类被死死地绑定在了 OrderRepository 这个具体实现上,想换一个实现、想在测试时换一个假的 mock,根本做不到,因为依赖是写死在内部 new 出来的、外面换不掉;其二,难测试——正因为依赖是 new 死的,我们没法在单元测试里注入一个内存假库,导致这个类的测试必须连着真数据库跑,又慢又脆;其三,生命周期混乱——有些对象(比如配置、比如某些客户端)本该是全局唯一的单例,可我们要么每次都 new 一个新的造成浪费,要么自己手搓一个 static 单例,而手搓的单例在多线程下的初始化又常常埋着竞态的雷。现代做法是全面拥抱 .NET 内置的 DI(依赖注入)容器:我们不再在类内部 new 依赖,而是把依赖通过构造函数参数声明出来(public OrderService(IOrderRepository repo, ILogger<OrderService> logger)),由 DI 容器在创建这个服务时,自动地把它需要的依赖一个个解析好、注入进来;我们只需在程序启动时,在容器里把"接口→实现"的映射和它的生命周期登记一次(services.AddScoped<IOrderRepository, OrderRepository>())。生命周期由容器统一管理且语义清晰:Singleton(全局唯一一个,容器负责线程安全地创建)、Scoped(每个请求一个,请求结束即释放)、Transient(每次解析都新建)。如此一来,类只依赖接口(可随时替换、可注入 mock 测试)、对象的创建和释放全由容器按登记的生命周期托管,我们再也不用手动 new、也不用手搓充满隐患的单例。下面是依赖注入的对比:

// 重构前:类内部手动 new 依赖,强耦合死实现、没法注入 mock 测试,还手搓单例埋多线程竞态
public class OrderService
{
    // 依赖被 new 死在内部:绑死具体实现,外面换不掉、测试时也注入不了假库
    private readonly OrderRepository _repo = new OrderRepository(new SqlConnection("..."));
    private static OrderService _instance;          // 手搓单例:多线程初始化有竞态隐患
    public static OrderService Instance => _instance ??= new OrderService();

    public void Place(Order o) => _repo.Save(o);    // 测试这个方法必须连真数据库,又慢又脆
}

// 重构后:构造函数注入 + DI 容器托管生命周期,只依赖接口、可注入 mock、生命周期容器统一管
public class OrderService
{
    private readonly IOrderRepository _repo;        // 只依赖接口,实现可随时替换、测试可注入假库
    private readonly ILogger _logger;
    public OrderService(IOrderRepository repo, ILogger logger)  // 依赖由容器注入
    {
        _repo = repo;
        _logger = logger;
    }
    public async Task PlaceAsync(Order o) => await _repo.SaveAsync(o);
}

// 程序启动时登记"接口→实现"映射与生命周期,创建与释放全交给容器:
// services.AddScoped();   // 每请求一个,请求结束即释放
// services.AddSingleton();          // 全局唯一,容器线程安全地创建
// ↑ 类不再 new 依赖、不再手搓单例;只声明依赖接口,容器按登记的生命周期解析注入、托管释放

依赖注入现代化让我们从"写一个服务类它要用到数据库访问 HTTP 客户端日志我们的做法简单粗暴直接在类里 new 一个出来、这一行 new 把灾难悄悄埋下了其一强耦合这个服务类被死死地绑定在了具体实现上想换一个实现想在测试时换一个假的 mock 根本做不到因为依赖是写死在内部 new 出来的外面换不掉、其二难测试正因为依赖是 new 死的我们没法在单元测试里注入一个内存假库导致这个类的测试必须连着真数据库跑又慢又脆、其三生命周期混乱有些对象本该是全局唯一的单例可我们要么每次都 new 一个新的造成浪费要么自己手搓一个 static 单例而手搓的单例在多线程下的初始化又常常埋着竞态的雷"进化到了"全面拥抱 .NET 内置的 DI 容器不再在类内部 new 依赖而是把依赖通过构造函数参数声明出来由 DI 容器在创建这个服务时自动地把它需要的依赖一个个解析好注入进来只需在程序启动时在容器里把接口到实现的映射和它的生命周期登记一次、生命周期由容器统一管理且语义清晰 Singleton 全局唯一 Scoped 每请求一个 Transient 每次新建、类只依赖接口可随时替换可注入 mock 测试对象的创建和释放全由容器按登记的生命周期托管":过去我们在代码里到处 new 依赖、绑死实现、手搓单例,根子上是混淆了两件本该分开的事——"使用一个东西"和"创造一个东西",一个服务类的本职是使用它的依赖去完成业务,可我们却让它同时还兼管了创造依赖(new 出来)、甚至管理依赖的生命周期(手搓单例)这些和它本职毫不相干的杂活,这种把"用"和"造"搅在一起的写法,让每个类都和它依赖的具体实现死死焊在了一起,牵一发而动全身,想替换、想测试、想统一管控生命周期都无从下手;后来我们接受了控制反转(IoC)这个朴素而深刻的思想——一个类不应该自己去创造和管理它的依赖,而应该只是声明"我需要这些依赖",然后把到底给它什么实现、这些实现活多久、何时创建何时释放这些控制权,统统反转交给一个外部的容器去掌管,于是我们用 .NET 内置的 DI 容器接过了所有"造"和"管"的活:类只管在构造函数里诚实地声明自己需要哪些接口,容器则负责在启动时按登记好的映射把具体实现和生命周期都准备好、在创建类时把依赖一个个解析注入进去、在恰当的时候释放它们,如此一来,每个类都被解放得只剩下它的本职——使用依赖干业务,而依赖的替换、测试时的 mock 注入、单例的线程安全创建、请求级对象的及时释放,全都被容器优雅地统一接管,我们这才明白,把"用"和"造"分开、把创造与管理的控制权反转给容器,才是让代码松耦合、可测试、生命周期清晰的根本。我们的纪律是"绝不在类内部手动 new 依赖把自己绑死在具体实现上、绝不自己手搓 static 单例埋多线程竞态,必须用构造函数声明依赖接口、由内置 DI 容器解析注入,必须把对象的生命周期(Singleton/Scoped/Transient)登记给容器统一托管而非自己管,要深刻认识到使用一个东西和创造一个东西是两件该分开的事、应把创造与管理的控制权反转给容器,把构造注入加容器托管生命周期当成松耦合可测试的根本来对待"。依赖注入的本质认知是:到处 new 依赖、手搓单例的根子,是把"使用一个东西"和"创造、管理一个东西"这两件该分开的事搅在了一起,让每个类都和具体实现死死焊住、难替换难测试、生命周期一团乱;依赖注入的智慧,在于控制反转——类只诚实声明需要哪些依赖接口,把给什么实现、活多久、何时创建释放的控制权反转交给 DI 容器统一掌管,从而让类只剩使用依赖的本职、而替换与 mock 测试与生命周期托管全交给容器,会写可维护 .NET 的团队,从不让一个类自己去 new 和管它的依赖,因为他们深知,一个既要干业务又要兼管创造和管理依赖的类,迟早会在某次想替换实现或想写个单元测试时,暴露出它和具体实现焊死在一起、根本拆不开的脆弱。

六、配置管理:从 web.config 字符串键散落拼错只能运行时炸到 IConfiguration 加 IOptions 强类型绑定编译期可查

第六仗,是把散落在 web.config 里、靠字符串键去取的配置,收拾成 IConfiguration 加 Options 模式的强类型配置。古早时代我们的配置全都堆在 web.config 这个大 XML 文件里,而代码里要读一个配置,就用 ConfigurationManager.AppSettings["SmtpHost"] 这样的字符串键去取——这套做法处处是雷:其一,字符串键散落各处、毫无约束,同一个配置项 "SmtpHost" 这个键被硬编码在十几个文件里,哪天改个名就得满世界搜替换,漏一个就出错;其二,拼错只能运行时炸,我把键名敲成了 "SmtpHsot",编译器毫不知情、照样通过,直到线上代码跑到那一行取出个 null 才轰然炸开;其三,取出来的全是字符串,要用就得自己 int.Parse、自己转 bool、自己处理转换失败,啰嗦又易错;其四,配置散落、没有分组,一个功能模块的相关配置七零八落地散在 appSettings 各处,看不出归属。现代做法是用 .NET 的 IConfiguration 配置体系加 Options 模式:配置写在 appsettings.json 里、支持按环境分文件和分层覆盖;更关键的是用 Options 模式把一组相关配置强类型地绑定到一个 C# 配置类上——我们定义一个 SmtpOptions 类(有 Host、Port、EnableSsl 等强类型属性),在启动时用 services.Configure<SmtpOptions>(config.GetSection("Smtp")) 把 JSON 里的 Smtp 配置节绑定到这个类,之后任何需要配置的地方,都通过 DI 注入 IOptions<SmtpOptions> 拿到一个强类型的配置对象,直接 options.Value.Host 访问——属性是强类型的(Port 直接就是 int 不用 parse)、是编译期可查的(敲错属性名编译器立刻报错)、是有分组归属的(一个类就是一组配置)。下面是配置管理的对比:

// 重构前:web.config + ConfigurationManager 字符串键,散落、拼错运行时才炸、全是字符串要手动转
public class Mailer
{
    public void Send()
    {
        // 字符串键硬编码、散落各处;敲错 "SmtpHsot" 编译器不管 → 运行时取出 null 才炸
        var host = ConfigurationManager.AppSettings["SmtpHost"];
        var port = int.Parse(ConfigurationManager.AppSettings["SmtpPort"]);  // 取出是字符串,得手动 Parse
        var ssl = bool.Parse(ConfigurationManager.AppSettings["SmtpSsl"]);   // 转换失败又是运行时异常
        // ...
    }
}

// 重构后:appsettings.json + Options 模式强类型绑定,属性强类型、编译期可查、有分组归属
public class SmtpOptions          // 一个类 = 一组配置,强类型属性
{
    public string Host { get; set; } = "";
    public int Port { get; set; }            // 直接就是 int,无需手动 Parse
    public bool EnableSsl { get; set; }
}
// 启动时绑定:services.Configure(config.GetSection("Smtp"));

public class Mailer
{
    private readonly SmtpOptions _opt;
    public Mailer(IOptions opt) => _opt = opt.Value;  // DI 注入强类型配置对象
    public void Send()
    {
        var host = _opt.Host;     // 强类型属性:敲错属性名编译器立刻报错,不再运行时才炸
        var port = _opt.Port;     // 直接是 int,不用 Parse
        // ...
    }
}
// ↑ 配置即对象:强类型、编译期可查、分组归属清晰,告别字符串键散落与拼错运行时炸

配置管理现代化让我们从"配置全都堆在 web.config 这个大 XML 文件里代码里要读一个配置就用 ConfigurationManager.AppSettings 字符串键去取这套做法处处是雷字符串键散落各处毫无约束同一个配置项的键被硬编码在十几个文件里哪天改个名就得满世界搜替换漏一个就出错、拼错只能运行时炸把键名敲错编译器毫不知情照样通过直到线上代码跑到那一行取出个 null 才轰然炸开、取出来的全是字符串要用就得自己 Parse 自己转 bool 啰嗦又易错、配置散落没有分组一个功能模块的相关配置七零八落地散在各处看不出归属"进化到了"用 .NET 的 IConfiguration 配置体系加 Options 模式配置写在 appsettings.json 里支持按环境分文件和分层覆盖更关键的是用 Options 模式把一组相关配置强类型地绑定到一个 C# 配置类上定义一个配置类有强类型属性在启动时把 JSON 里的配置节绑定到这个类之后任何需要配置的地方都通过 DI 注入 IOptions 拿到一个强类型的配置对象属性是强类型的是编译期可查的是有分组归属的":过去我们用字符串键去取配置之所以处处埋雷,根子上是因为我们把配置当成了游离在类型系统之外的、一堆松散的字符串键值对,而一旦一样东西游离在了类型系统之外,我们就失去了编译器这个最忠诚、最不知疲倦的守门人的全部保护——编译器能在编译期帮我们揪出敲错的变量名、对不上的类型,可它对一个藏在字符串里的配置键 "SmtpHost" 一无所知,我们把它敲成 "SmtpHsot",在编译器眼里那不过是一个无意义的字符串字面量、没有任何错可言,于是这个错误就堂而皇之地躲过了编译期的所有检查、一路潜伏到线上才以一个 null 引发的崩溃暴露出来;后来我们才真正理解,对付这种游离在类型之外的脆弱,最好的办法就是把它拉回到类型系统的保护之内——用 Options 模式把一组配置绑定成一个实实在在的强类型 C# 类,这一拉,配置就从一堆无人看管的字符串键,变成了编译器全程盯着的类型化属性:我们访问 options.Host 时,属性名敲错编译器当场报错、Port 本身就是 int 无需我们手动 parse、一组相关配置因为同属一个类而归属分明,我们等于是把配置这件事重新交还给了编译器这个守门人去守护,让那些过去要等到线上才暴露的配置错误,在编译的那一刻就被无情地拦下,我们这才懂得,凡是能纳入类型系统的,就绝不要让它游离在外靠字符串和运行时去碰运气。我们的纪律是"绝不用 ConfigurationManager 加字符串键去取散落各处的配置埋下拼错运行时才炸的雷、绝不取出字符串再到处手动 Parse,必须用 IConfiguration 加 Options 模式把一组配置强类型绑定到配置类、通过 IOptions 注入访问,要深刻认识到游离在类型系统之外的字符串键失去了编译器的守护、应把配置拉回类型系统之内,把强类型配置当成让编译器替我们守住配置正确的基本功来对待"。配置管理的本质认知是:用字符串键取配置等于让配置游离在类型系统之外、失去了编译器这个守门人的保护,拼错的键名躲过编译期一路潜伏到线上才以 null 崩溃暴露;配置管理的智慧,在于把配置拉回类型系统之内——用 Options 模式绑定成强类型配置类,让属性名编译期可查、类型自动转换、相关配置分组归属,把过去要到线上才炸的配置错误在编译那一刻就拦下,会写健壮 .NET 的团队,从不让配置游离在字符串里碰运气,因为他们深知,凡是能交给编译器守护的正确性,就绝不该留到运行时用一次线上崩溃去发现。

七、空安全:从引用默认可空 NullReferenceException 满天飞全到线上才炸到可空引用类型把可空与否写进类型编译期就揪出潜在 null

第七仗,是开启 C# 8 引入的可空引用类型(Nullable Reference Types),向那个折磨了 .NET 程序员二十年的"十亿美金错误"——NullReferenceException——宣战。古早时代在老 C# 里,所有的引用类型默认都是可空的:一个 string name、一个 Order order,它既可能指向一个真实的对象,也可能是个 null,而类型本身完全没有透露这个信息——你拿到一个 string 参数,根本无从知道调用方到底会不会给你传个 null 进来,你访问 order.Customer.Name 时,order 是不是 null、Customer 是不是 null,全凭运气和祈祷。于是 NullReferenceException 成了我们线上最常见、最阴魂不散的异常:某个本以为不会为 null 的对象偏偏是了 null,代码访问它的成员时当场抛出 NRE,而这种错误编译期毫无征兆、全都要等到线上某个特定路径被走到时才轰然爆发。现代做法是开启可空引用类型这个特性(在项目里 <Nullable>enable</Nullable>):开启后,引用类型默认变成不可空的——一个 string name 表示"它绝不应该是 null",如果你想让它可以为 null,必须显式地写成 string? name(加个问号)。这个小小的问号,把"可空与否"这个至关重要的信息,第一次正式地写进了类型系统:编译器据此会做流分析,如果你试图把一个可能为 null 的值赋给一个不可空的变量、或者在没有判空的情况下就访问一个可空变量的成员,编译器会立刻给出警告——它在编译期就帮你把那些潜在的 null 解引用一个个揪出来,逼着你要么判空、要么明确表达你的意图。这相当于把过去全靠运气、要到线上才暴露的 null 风险,前移成了编译期就能看见、就能处理的明确问题。下面是空安全的对比:

// 重构前:引用默认可空,类型不透露可空信息,NRE 编译期无征兆、全到线上才炸
public string GetCustomerName(Order order)   // order 会不会是 null?类型没说,全凭运气
{
    return order.Customer.Name;   // order/Customer 任一为 null 都当场抛 NullReferenceException
}                                 // ↑ 编译器毫无警告,直到线上某条路径走到才轰然爆发

// 重构后:开启可空引用类型(enable),可空与否写进类型,编译期揪出潜在 null
public string? GetCustomerName(Order? order)  // ? 明确表达:order 可能为 null
{
    if (order is null)            // 编译器流分析:不判空就访问成员会立刻警告,逼你处理
        return null;
    // 此处编译器已知 order 非空;若 Customer 也声明为可空则同样需判空
    return order.Customer?.Name;  // ?. 安全导航:Customer 为 null 时短路返回 null,不抛 NRE
}
// 不可空属性必须在构造时初始化,否则编译器警告 —— 把"绝不为 null"的承诺也纳入编译期检查:
// public class Order { public Customer Customer { get; set; } = null!; /* 或构造函数中赋值 */ }
// ↑ 可空与否进入类型系统,编译器在编译期就揪出潜在 null 解引用,逼着判空或表明意图

空安全现代化让我们从"在老 C# 里所有的引用类型默认都是可空的一个 string 一个 Order 它既可能指向一个真实的对象也可能是个 null 而类型本身完全没有透露这个信息你拿到一个 string 参数根本无从知道调用方到底会不会给你传个 null 进来你访问 order.Customer.Name 时 order 是不是 null Customer 是不是 null 全凭运气和祈祷、于是 NullReferenceException 成了线上最常见最阴魂不散的异常某个本以为不会为 null 的对象偏偏是了 null 代码访问它的成员时当场抛出 NRE 而这种错误编译期毫无征兆全都要等到线上某个特定路径被走到时才轰然爆发"进化到了"开启可空引用类型这个特性开启后引用类型默认变成不可空的一个 string name 表示它绝不应该是 null 如果你想让它可以为 null 必须显式地写成 string 加个问号、这个小小的问号把可空与否这个至关重要的信息第一次正式地写进了类型系统编译器据此会做流分析如果你试图把一个可能为 null 的值赋给一个不可空的变量或者在没有判空的情况下就访问一个可空变量的成员编译器会立刻给出警告它在编译期就帮你把那些潜在的 null 解引用一个个揪出来逼着你要么判空要么明确表达你的意图":过去 NRE 之所以能成为折磨我们二十年的顽疾,根子上是因为老 C# 的类型系统里藏着一个巨大的信息黑洞——一个引用类型的变量到底允不允许为 null,这个对正确性至关重要的信息,竟然完全不在类型里体现,所有的引用都默默地、一律地可空,于是每个程序员在拿到一个对象时,都被迫在脑子里玩一场没有依据的猜谜:它可能是 null 吗?我需要判空吗?而这种猜谜是没有标准答案的、是会猜错的,猜错的代价就是一个潜伏到线上的 NRE,我们二十年来写下的无数个判空、漏掉的无数个判空,本质上都是在用人脑去填补类型系统留下的这个信息黑洞,既不可靠又无穷无尽;后来 C# 用可空引用类型给这个黑洞补上了一块关键的拼图——它让"可不可以为 null"这个信息,终于堂堂正正地进入了类型系统,一个 string 就是承诺绝不为 null,一个 string? 就是明示可能为 null,这个区别第一次有了类型层面的、编译器看得见也管得着的意义,于是那场延续了二十年的、靠人脑猜测的判空猜谜,被交还给了编译器去做严格的流分析:你哪里可能解引用一个 null,编译器替你一一指出、当场警告,逼你要么判空要么表明这里确实不会为 null,我们这才从"凭经验和运气去猜哪里要判空、然后在线上为猜错买单"的泥潭里走出来,把 null 的风险从一个看不见摸不着、全靠人去防的运行时幽灵,变成了一个写在类型上、由编译器替我们盯死的编译期明确问题。我们的纪律是"绝不依赖老 C# 引用默认可空的语义靠人脑猜测哪里要判空、把 NRE 留到线上才炸,必须开启可空引用类型把可空与否写进类型、用 string? 明示可空用 string 承诺非空,必须正视编译器的可空警告要么判空要么用安全导航要么表明意图而非压制,要深刻认识到可不可以为 null 是该写进类型系统由编译器盯死的信息而非靠人脑去猜,把可空引用类型当成把 NRE 从运行时幽灵变成编译期明确问题的空安全基本功来对待"。空安全的本质认知是:老 C# 引用一律默认可空,让"可不可以为 null"这个对正确性至关重要的信息游离在类型之外,逼每个程序员靠人脑去猜哪里要判空、猜错就以一个潜伏到线上的 NRE 买单;空安全的智慧,在于把可空与否写进类型系统——用 string? 明示可空、string 承诺非空,让编译器替我们做严格流分析、在编译期一一揪出潜在的 null 解引用,把 null 风险从看不见的运行时幽灵变成编译期就能处理的明确问题,会写健壮 .NET 的团队,开启可空引用类型让编译器替自己盯死每一处 null,因为他们深知,靠人脑去防的判空总有猜漏的一次,而那一次漏掉的判空,就是某天线上某条路径上一个准时爆发的 NullReferenceException。

八、运行时与部署:从绑死 .NET Framework 加 Windows 加 IIS 又重又只能单平台到 .NET 8 跨平台 self-contained 容器哪都能跑

第八仗,也是收官的一仗,是把这套从骨子里绑死了 Windows 的应用,彻底迁移成基于 .NET 8 的、跨平台的、容器化的服务。古早时代我们的应用是被 .NET Framework 死死绑在 Windows 上的:.NET Framework 本身只能跑在 Windows 上,我们又依赖 IIS 做宿主、依赖一堆 Windows 特有的 API,这意味着我们的部署被锁死在了一条又重又贵又僵硬的路上——只能部署到 Windows Server,要装特定版本的 .NET Framework 运行时(还得和机器上其他应用共享、互相牵制),要配 IIS、要管应用程序池,环境稍有不一致就出诡异问题,想上 Linux 容器、想享受云原生那套弹性和精简,门都没有。现代做法是迁移到 .NET(自 .NET Core 起就是跨平台的,到 .NET 8 已经非常成熟):.NET 8 应用可以原生地跑在 Linux、macOS、Windows 上;宿主用内置的、轻量高性能的 Kestrel,不再依赖 IIS;更关键的是两个部署利器——其一,self-contained 发布,可以把 .NET 运行时直接打包进应用的发布产物里,目标机器上不需要预装任何 .NET 运行时,彻底告别"运行时版本依赖地狱";其二,容器化,把这个 self-contained 的应用打进一个精简的 Linux 容器镜像里,这个镜像自带了应用运行所需的一切、不依赖宿主机的任何环境,真正做到了"一次构建、哪都能跑",还能无缝接入 Kubernetes 那套弹性伸缩、滚动发布、自愈的云原生能力。我们就这样把一个又重又只能蜷在 Windows 角落里的祖传应用,变成了一个轻盈的、哪都能跑的、能享受全部云原生红利的现代服务。下面是运行时与部署的对比:

# 重构前:绑死 .NET Framework + Windows + IIS —— 只能上 Windows Server,装特定运行时、配 IIS 应用池
# (无法容器化到精简 Linux,运行时与机器上其他应用共享互相牵制,环境不一致就诡异出错)
# 部署 = 装 Windows Server → 装对应版本 .NET Framework → 配 IIS 站点与应用程序池 → 复制文件
# ↑ 又重又贵又僵,锁死单平台,享受不到 Linux 容器与云原生弹性

# 重构后:.NET 8 跨平台 + self-contained + 容器化 —— 一次构建哪都能跑,镜像自带一切、无环境依赖
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
# self-contained 发布:把 .NET 运行时直接打包进产物,目标机无需预装任何 .NET 运行时
RUN dotnet publish -c Release -r linux-x64 --self-contained true -o /app

FROM mcr.microsoft.com/dotnet/runtime-deps:8.0 AS final   # 精简基础镜像,只含运行依赖
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["./MyApp"]    # 用内置 Kestrel 宿主,不依赖 IIS
# ↑ 打成自带运行时的精简 Linux 镜像:一次构建哪都能跑,无缝接入 K8s 弹性伸缩/滚动发布/自愈

运行时与部署现代化让我们从"应用是被 .NET Framework 死死绑在 Windows 上的 .NET Framework 本身只能跑在 Windows 上又依赖 IIS 做宿主依赖一堆 Windows 特有的 API 这意味着部署被锁死在了一条又重又贵又僵硬的路上只能部署到 Windows Server 要装特定版本的 .NET Framework 运行时还得和机器上其他应用共享互相牵制要配 IIS 要管应用程序池环境稍有不一致就出诡异问题想上 Linux 容器想享受云原生那套弹性和精简门都没有"进化到了"迁移到 .NET 8 应用可以原生地跑在 Linux macOS Windows 上宿主用内置的轻量高性能的 Kestrel 不再依赖 IIS 更关键的是两个部署利器 self-contained 发布可以把 .NET 运行时直接打包进应用的发布产物里目标机器上不需要预装任何 .NET 运行时彻底告别运行时版本依赖地狱、容器化把这个 self-contained 的应用打进一个精简的 Linux 容器镜像里这个镜像自带了应用运行所需的一切不依赖宿主机的任何环境真正做到了一次构建哪都能跑还能无缝接入 Kubernetes 那套弹性伸缩滚动发布自愈的云原生能力":过去我们的应用之所以又重又僵、被钉死在 Windows 上动弹不得,根子上是因为它和它所运行的环境之间,有着千丝万缕、剪不断理还乱的隐性依赖——它依赖宿主机上预装的特定版本 .NET Framework、依赖 IIS、依赖一堆 Windows 特有的 API 和注册表设置,这些依赖大多不是显式声明的、而是默默假定"环境里就该有这些",于是这个应用根本不是一个能独立存在的东西,它是一株深深扎根在某台特定配置的 Windows 服务器土壤里、一旦拔起换个地方就活不了的植物,这种应用与环境的深度纠缠,正是它无法迁移、无法弹性、无法享受任何现代部署红利的总病根;后来我们走的整条现代化部署之路,核心其实就一件事——斩断应用与特定环境之间所有的隐性纠缠,让应用变成一个自给自足、不挑环境的独立单元,self-contained 发布斩断的是对宿主机预装运行时的依赖(把运行时打包进自己),容器化斩断的则是对宿主机操作系统环境的依赖(把应用连同它需要的一切封进一个自带环境的镜像),当这两刀斩下去,我们的应用就从那株离了特定土壤就死的植物,变成了一个把自己的土壤一起装进了花盆、搬到哪都能活的盆栽,它不再关心宿主机上装了什么、是 Linux 还是 Windows、有没有预装运行时,因为它运行所需的一切都已自带,于是一次构建、哪都能跑成了现实,Kubernetes 那套弹性伸缩、滚动发布、自愈的云原生能力也才第一次向我们敞开,我们这才彻底想通,一个应用要想轻盈、可迁移、能享受云原生的全部红利,前提就是它必须先成为一个不与任何特定环境纠缠的、自给自足的独立单元。我们的纪律是"绝不让应用与特定宿主环境深度纠缠把自己钉死在 Windows 加 IIS 加预装运行时上失去迁移与弹性能力,必须迁到 .NET 8 跨平台用内置 Kestrel 宿主、用 self-contained 把运行时打包进产物斩断对预装运行时的依赖、用容器把应用连同环境封成自给自足的镜像斩断对宿主操作系统的依赖,要深刻认识到应用与环境的隐性纠缠是无法迁移无法弹性的总病根、应让应用成为不挑环境的独立单元,把跨平台容器化当成让应用一次构建哪都能跑并享受云原生红利的根本来对待"。运行时与部署的本质认知是:老应用又重又僵、钉死在 Windows 上的总病根,是它和宿主环境之间剪不断的隐性依赖——预装运行时、IIS、Windows 特有 API,让它成了离了特定土壤就死的植物;现代部署的智慧,在于斩断应用与特定环境的一切纠缠——self-contained 把运行时打包进自己、容器把应用连同环境封成自给自足的镜像,让应用变成搬到哪都能活的独立单元,从而一次构建哪都能跑、并接入 K8s 的弹性与自愈,会做现代化的团队,把应用对环境的每一处隐性依赖都显式斩断、封装进可移植的单元,因为他们深知,一个与特定环境深度纠缠的应用,迁移它、弹性伸缩它、让它享受云原生的任何尝试,都会被那些藏在角落里、剪不断的隐性依赖一次次绊倒。

九、7 个 P0 事故复盘

7 事故:(1) 一次促销流量只比平时高三四倍、一处同步方法里用 .Result 等异步调用的 sync-over-async 大量出现把 IIS 线程池占满耗尽、32 核服务器 CPU 闲在 5% 而所有 API 集体超时挂死,事后把所有 IO 操作全程改造成 async/await 异步非阻塞、彻底禁绝 .Result/.Wait;(2) 一次高频报文解析热路径上海量 Substring 与数组拷贝制造的临时对象把 GC 喂到频繁暂停、服务出现成片延迟毛刺,事后用 Span<T>/ReadOnlySpan 零拷贝切片与 ArrayPool 租借复用把分配压到极低;(3) 一次 API 网关在大促下 Newtonsoft.Json 运行时反射序列化吃满 CPU 又造一堆垃圾拖垮吞吐,事后换 System.Text.Json 源生成器编译期生成、运行时零反射;(4) 一次报表接口因不懂 LINQ 延迟执行把同一查询重复枚举三遍、又在循环里触发 N+1 把数据库连接打满,事后用 ToList 一次物化与 Include/投影根治 N+1;(5) 一次想给某仓储换内存实现做单元测试却发现依赖被 new 死在类内部根本换不掉、测试只能连真库又慢又脆,事后全面改用构造函数注入加 DI 容器托管生命周期;(6) 一次把 SmtpHost 配置键敲错成 SmtpHsot 编译器毫无察觉、上线后发邮件路径走到才取出 null 崩溃,事后用 IOptions 强类型绑定让配置错误编译期可查;(7) 一次某条少走的分支里一个本以为非空的对象偏是 null 抛出 NRE 在线上炸开,事后开启可空引用类型让编译器在编译期就揪出潜在 null 解引用。每个 P0 都做 5-Why 复盘,固化成异步红线、低分配热路径规约、序列化基线、LINQ 查询规约、依赖注入标准、强类型配置规范或空安全要求,确保同类问题不再复发。

十、.NET 工程师的 6 条工程哲学

6 哲学:(1) 线程是昂贵且有限的资源,绝不能浪费在纯等待上——在一个 IO 密集的服务里,同步阻塞不是慢一点的问题,而是一颗会在某次寻常流量高峰下让整个服务因线程池耗尽而集体猝死的定时炸弹,凡 IO 必异步、且把异步一路贯穿到底;(2) 自动 GC 免除的是手动释放内存的负担,而非克制分配的责任——在高频热路径上随手的 Substring、拷贝、拼接,乘以巨大频次就是喂给 GC 的海量垃圾,对每一次分配都要保持敏感;(3) 编译期能做的事绝不留到运行时——序列化的反射、配置键的拼写、null 的可能性,这些过去要在运行时付出的动态代价,大多能靠源生成器、强类型绑定、可空引用类型提前消灭在编译期;(4) 声明式的优雅会掩盖真实的代价——LINQ 让人看不清一段查询到底打几次库,享受它的优雅就必须看穿它的延迟执行,对每一次枚举的真实开销心里有数;(5) 使用一个东西和创造、管理一个东西是两件该分开的事——让类只管声明和使用它的依赖,把创造与生命周期管理的控制权反转给 DI 容器,才有松耦合与可测试;(6) 一个应用要想轻盈可迁移,前提是它必须先成为一个不与任何特定环境纠缠的自给自足的独立单元——用 self-contained 和容器斩断它与宿主环境的每一处隐性依赖。这 6 条哲学,是我们用 7 个 P0 事故和 87 天攻坚换来的集体共识。它们共同指向一个认知:把一套 .NET Framework 祖传应用现代化到 .NET 8,真正的难点从不在于学会几个新 API,而在于看穿那些被旧时代的便利所掩盖的、关于线程、内存、编译期、执行代价、职责分离与环境依赖的本质,会写现代 .NET 的团队,敬畏每一个稀缺资源、警惕每一处被掩盖的代价、并坚信凡能交给编译器和容器守护的,就绝不留给运行时和运气。

十一、重构收益的量化:7 个关键数字

7 数字:(1) 并发承载:同样一台 32 核服务器,同步阻塞模型下流量高出三四倍就线程池耗尽全挂 → async/await 全程异步后用同样硬件撑起高出一个数量级的并发吞吐;(2) GC 暂停:热路径海量临时对象喂得 GC 频繁暂停、成片延迟毛刺 → Span/ArrayPool 低分配后 GC 回收频率与暂停大幅下降、毛刺被抹平;(3) 序列化开销:Newtonsoft.Json 运行时反射常年高居 CPU 热点榜前列 → System.Text.Json 源生成器后序列化既快又几乎不造垃圾、退出热点榜;(4) 数据库往返:一个报表接口因重复枚举加 N+1 一次请求打出上百次查询 → ToList 物化加 Include 投影后收敛成个位数往返;(5) 单元测试:依赖 new 死在类内部、关键逻辑必须连真库测、又慢又脆几乎没法写 → 构造注入加 DI 后可注入内存假库、单测快且稳、覆盖率大幅提升;(6) 配置与 null 类故障:配置键拼错与 NRE 一律潜伏到线上才炸 → 强类型配置加可空引用类型后这两类错误绝大多数在编译期就被拦下;(7) 部署形态:绑死 Windows Server 加 IIS、又重又只能单平台、装不一致就出诡异问题 → self-contained 容器化后一次构建哪都能跑、镜像精简、无缝接入 K8s 弹性伸缩。这些数字背后,是 87 天里 8 个人一仗一仗地改异步、压分配、换序列化、纠 LINQ、落 DI、收配置、开空安全、做容器化,但每一个都实打实地转化成了系统的并发能力、稳定性、可测试性和部署灵活度。当我们把这份数据汇报给管理层时,最有说服力的不是任何花哨的 .NET 新特性名词,而是"同样的服务器扛住了高一个数量级的并发再没因流量高峰挂过、过去全到线上才炸的配置错和空指针如今编译就拦下、应用从只能蜷在 Windows 角落变成了哪都能跑的精简容器"这几条。

十二、留给后来者的最后一句话

87 天的把 .NET Framework 祖传应用现代化到 .NET 8 的攻坚战,我们走过的不只是一条从同步阻塞 .Result 占线程死等到 async/await 全程异步、从 Substring 数组拷贝制造海量垃圾到 Span 与 ArrayPool 零拷贝少分配、从 Newtonsoft.Json 运行时反射到 System.Text.Json 源生成器、从不懂延迟执行重复枚举加 N+1 到 ToList 物化加 Include 投影、从到处手动 new 强耦合到 DI 容器构造注入、从 web.config 字符串键散落拼错运行时炸到 IOptions 强类型绑定、从引用默认可空 NRE 满天飞到可空引用类型编译期揪 null、从绑死 Windows 加 IIS 到 .NET 8 跨平台容器化的技术升级路,更是一次从"用伺候单机应用的朴素思维去写一个高并发服务、把线程内存编译期都当成取之不尽免费的东西随意挥霍"到"敬畏每一个稀缺资源、警惕每一处被旧时代便利掩盖的代价、把凡能交给编译器和容器守护的都从运行时和运气手里夺回来"的认知跃迁。当一台曾经流量高出三四倍就线程池耗尽全挂的服务器在全程异步之后用同样的硬件稳稳扛住了高一个数量级的并发、当一条曾经被海量临时对象喂得 GC 频繁暂停毛刺成片的热路径在 Span 与 ArrayPool 之后分配压到极低毛刺被抹平、当一个曾经反射序列化吃满 CPU 的网关在源生成器之后序列化既快又不造垃圾、当一个曾经重复枚举加 N+1 打出上百次查询的报表接口在物化与投影之后收敛成个位数往返、当一段曾经依赖 new 死根本没法测的逻辑在构造注入之后能注入假库被快而稳地覆盖、当一个曾经拼错配置键和空指针全到线上才炸的应用在强类型配置与可空引用类型之后让这两类错误在编译那一刻就被拦下、当一套曾经只能蜷在 Windows 角落里的祖传应用在 self-contained 容器化之后变成了哪都能跑的精简服务那一刻,真正让我们踏实的,不是用上了多少 .NET 8 的时髦特性,而是'系统的并发能力、稳定性、可测试性和演进能力,终于从依赖一套谁也不敢深碰的祖传代码不要出事的祈祷,变成了由异步非阻塞、低分配内存、源生成序列化、延迟执行认知、依赖注入、强类型配置、空安全和跨平台容器化这套工程方法对每一处稀缺资源与被掩盖代价的清醒驾驭'的笃定。.NET 现代化没有银弹,真正的功夫从不在记住几个新 API,而在理解异步对线程、低分配对 GC、源生成对反射、延迟执行对查询、依赖注入对耦合、强类型对配置、可空引用对 null、容器化对环境依赖各自解决什么本质问题、又如何共同服务于"用现代工程方法把那些被旧时代便利掩盖的代价一一驯服"这个核心目标,然后从把那颗最致命的同步阻塞定时炸弹拆掉这件最根本的事做起——尤其要克制"图省事用 .Result 同步等异步、图省事热路径上随手分配、图省事用反射序列化、图省事重复枚举不管 N+1、图省事 new 死依赖、图省事字符串键取配置、图省事不开空安全、图省事绑死 Windows"的旧习惯,因为每一处同步阻塞、每一次热路径上的随手分配、每一个 new 死的依赖、每一个游离在类型外的配置键和 null,都是在用旧时代的省事,去置换一颗会在某次流量高峰、某次线上特定路径下准时引爆的炸弹。愿每一位还在和祖传 C# 代码、线程池耗尽、GC 卡顿和满天飞的 NRE 搏斗的同行,都能早日让自己的系统被这套现代 .NET 的工程方法稳稳地托住。共勉,后会有期。

—— 别看了 · 2026