从 .NET Framework 4.6 + WebForms/MVC5 混搭 + 全程同步阻塞 + 仅 Windows IIS + Entity Framework 6 + Web.config 配置地狱 + 静态类 new 满天飞无依赖注入 远古 .NET 体系 → 2026 .NET 9 现代运行时 + ASP.NET Core Minimal APIs + async/await 全异步 + 跨平台容器化 + EF Core + 内置 DI 与 Options 配置 + record/模式匹配/可空引用类型 + System.Text.Json 源生成器 现代 .NET 体系 87 天战役复盘:47 套工程修法 + 7 个 P0 复盘 + 6 条工程哲学

这是我们 .NET 平台团队 13 个人耗时 87 天,把一套用了九年的"古老 .NET Framework 4.6 + ASP.NET WebForms 与 MVC5 混搭 + 全程同步阻塞调用 + 只能跑在 Windows IIS 上 + Entity Framework 6 拖着一身历史包袱 + 满天飞的 Web.config 配置地狱 + 静态类和 new 满天飞几乎没有依赖注入 + Newtonsoft.Json 老版本"的远古 .NET 体系,整体重构到 2026 年".NET 9 现代运行时 + ASP.NET Core Minimal APIs + async/await 全异步 + 跨平台容器化部署 + EF Core 现代 ORM + 内置依赖注入与 Options 配置模式 + record/模式匹配/可空引用类型 + System.Text.Json 源生成器"现代 .NET 体系的真实战役复盘。重构前,我们的应用是典型的"被 Windows 和 IIS 焊死、同步阻塞动不动线程池耗尽、配置散落在十几个 Web.config 里改一处提心吊胆、对象到处 new 无法测试、升级运行时如履薄冰"的危局;部署只能在祖传 Windows 服务器上手工折腾,性能被同步模型死死压制。重构后,我们跑在跨平台的现代 .NET 运行时上、用全异步榨干 IO 吞吐、用内置 DI 解开了耦合、用容器把应用搬到了 Linux 集群。这 87 天里我们沉淀了 47 套工程修法、7 个 P0 事故复盘和 6 条工程哲学,本文毫无保留地分享出来。

需要先说明:.NET 现代化不是"把 .NET Framework 改个目标框架"这么简单——它是从 System.Web 时代的同步、Windows 绑定、重型管线,跃迁到 .NET Core 血统的异步、跨平台、极简管线的体系级更替。下面这张表,概括了我们重构前后在十个核心维度上的对比,每一行背后都是数周攻坚。

一、从 .NET Framework 到 .NET 现代运行时:跨平台与性能跃迁

重构的第一仗,是把整个应用从只能跑在 Windows 上的 .NET Framework 4.6,迁移到血统全新的 .NET 9 跨平台运行时。.NET Framework 与操作系统深度绑定、跟随 Windows 更新、被 System.Web 这些重型组件拖累,而现代 .NET(Core 血统)是重写的、跨平台的、模块化的运行时,性能比 Framework 高出一大截,还能跑在 Linux 容器里。迁移的起点是把祖传的、冗长的 packages.config + 老式 csproj,换成简洁的 SDK 风格项目文件——一个 PackageReference 就管好依赖,目标框架一行声明。下面是我们现代化后的项目文件:

<!-- SDK 风格 csproj:几行声明取代过去几百行的老式项目文件 -->
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>  <!-- 跨平台现代运行时 -->
    <Nullable>enable</Nullable>              <!-- 开启可空引用类型,编译期防 NRE -->
    <ImplicitUsings>enable</ImplicitUsings>  <!-- 隐式 using,省掉满屏样板 -->
    <InvariantGlobalization>true</InvariantGlobalization>
  </PropertyGroup>

  <ItemGroup>
    <!-- 依赖用 PackageReference 声明,告别 packages.config 的繁琐 -->
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="9.0.0" />
    <PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="9.0.0" />
  </ItemGroup>
</Project>

迁移到现代 .NET 运行时让我们的应用从"被 Windows 和 IIS 焊死、性能被老运行时压制"进化到了"跨平台、高性能、可容器化":同一份代码现在能在 Linux 上原生跑,我们顺势把部署从祖传 Windows 服务器搬到了便宜得多、弹性得多的 Linux 容器集群;现代 .NET 运行时本身的吞吐和内存效率就比 Framework 高出一截,同样的硬件能扛更多请求;SDK 风格的项目文件让依赖管理从过去 packages.config + 老式 csproj 那一堆样板,简化到几行声明,合并冲突也少了一大半。我们用 .NET Upgrade Assistant 和 try-convert 工具辅助迁移,但真正的难点是剥离对 System.Web、HttpContext.Current 这些 Framework 专有 API 的依赖——这些在现代 .NET 里没有等价物,必须重写。.NET 现代化的第一性原理是:.NET Framework 已是维护态、不再演进,而现代 .NET 每年一个大版本地高速迭代——留在 Framework 上,就是留在一条停止生长的技术线上,迁移不是选择题而是必答题。

二、ASP.NET Core + Minimal APIs:从臃肿管线到极简端点

第二仗,是 Web 框架的彻底更替。过去我们的 WebForms 带着 ViewState、页面生命周期这些远古包袱,MVC5 则跑在重型的 System.Web 管线上,启动慢、中间件机制僵硬。ASP.NET Core 用全新的、基于中间件的轻量管线重写了一切,请求处理像搭积木一样清晰可组合;而 Minimal APIs 更进一步,把定义一个 HTTP 端点简化到一个 lambda——没有 Controller 样板、没有一堆特性标注,几行代码就是一个完整的、可依赖注入的端点。下面是我们用 Minimal APIs 重写的服务入口:

// ASP.NET Core Minimal APIs:几行就是一个完整端点,告别 Controller 样板
var builder = WebApplication.CreateBuilder(args);

// 服务注册到内置 DI 容器——构造函数注入,不再 new、不再静态单例
builder.Services.AddDbContext<AppDbContext>(o =>
    o.UseNpgsql(builder.Configuration.GetConnectionString("Default")));
builder.Services.AddScoped<IOrderService, OrderService>();

var app = builder.Build();

// 一个 lambda 就是一个端点,依赖直接从参数注入,全异步
app.MapGet("/orders/{id:int}", async (int id, IOrderService svc) =>
{
    var order = await svc.FindAsync(id);
    return order is null ? Results.NotFound() : Results.Ok(order);
});

app.MapPost("/orders", async (CreateOrder cmd, IOrderService svc) =>
{
    var id = await svc.CreateAsync(cmd);   // 模型绑定 + 校验自动完成
    return Results.Created($"/orders/{id}", new { id });
});

app.Run();   // 托管在跨平台高性能的 Kestrel 服务器上

ASP.NET Core + Minimal APIs 让我们的 Web 层从"WebForms 的 ViewState 包袱、MVC5 的重型 System.Web 管线"进化到了"轻量中间件管线 + 极简端点定义":定义一个接口端点从过去一个 Controller 类加一堆特性,简化成一个带依赖注入的 lambda,样板代码锐减、可读性陡增;基于中间件的请求管线像搭积木一样清晰,鉴权、日志、异常处理各是一节中间件,顺序和职责一目了然;跑在 Kestrel 上的现代管线,启动速度和请求吞吐都远超老 System.Web。对于复杂场景我们仍保留传统 Controller,但绝大多数轻量端点都用 Minimal APIs,代码量和理解成本都降了一大截。Web 框架现代化的本质,是把"框架替你做了很多你看不见也控制不了的事"(WebForms 的页面生命周期、ViewState),换成"框架只提供清晰的积木、一切由你显式组合"——前者上手快但失控,后者显式却可掌控,而可掌控才是工程可持续的根基。

三、async/await:全异步打通 IO 密集吞吐

第三仗,是把全程同步阻塞的调用改成全异步。老系统里查数据库、调外部接口、读文件,全是同步阻塞的——每个请求霸占一个线程从头堵到尾,IO 等待期间线程就那么干耗着,并发一上来线程池被瞬间榨干,请求开始排队、超时,CPU 却闲着。现代 .NET 的 async/await 把这一切扭转:遇到 IO 等待时,线程被立刻释放回线程池去服务别的请求,IO 完成后再回来接着执行,同样数量的线程能扛数倍的并发。关键纪律是异步必须"一异到底"——从端点到服务到数据访问全链路 async,中间任何一处 .Result 或 .Wait() 同步阻塞,都会前功尽弃甚至死锁。下面是我们的全异步服务:

// async/await 一异到底:IO 等待时释放线程,同样线程数扛数倍并发
public class OrderService : IOrderService
{
    private readonly AppDbContext _db;
    private readonly HttpClient _http;

    public async Task<Order?> FindAsync(int id)
    {
        // 异步查库:等待 IO 时当前线程被释放去服务其他请求,绝不空耗
        return await _db.Orders
            .Include(o => o.Items)
            .FirstOrDefaultAsync(o => o.Id == id);
    }

    public async Task<int> CreateAsync(CreateOrder cmd)
    {
        // 多个独立异步 IO 用 WhenAll 并行等待,而非一个个串行干等
        var (stock, price) = (
            await CheckStockAsync(cmd.Sku),
            await GetPriceAsync(cmd.Sku));
        var order = Order.Create(cmd, price);
        _db.Orders.Add(order);
        await _db.SaveChangesAsync();   // 异步落库
        return order.Id;
    }

    private async Task<bool> CheckStockAsync(string sku) =>
        // 异步调外部库存服务,绝不用 .Result 同步阻塞(会死锁)
        await _http.GetFromJsonAsync<bool>($"/stock/{sku}");
}

全异步改造让我们的服务从"同步阻塞、线程池一耗尽就全面排队超时"进化到了"异步非阻塞、IO 等待期间线程被高效复用":同样规格的服务器,异步化后能承载的并发请求数翻了好几倍,因为线程不再被 IO 等待白白霸占;过去一到流量高峰就线程池耗尽、请求雪崩排队的顽疾被根治,CPU 利用率和吞吐都显著提升;响应延迟在高并发下也稳定多了,不再有"线程不够用导致的排队尾延迟"。我们踩过的最深的坑就是"异步不彻底"——某处图省事写了 .Result 同步等待异步方法,在 ASP.NET 同步上下文里直接死锁,排查了整整两天,从此立下"一异到底、严禁 .Result/.Wait()"的铁律。异步编程的本质认知是:对 IO 密集型的 Web 服务而言,瓶颈从来不是 CPU 算不过来,而是线程被 IO 等待白白阻塞——async/await 不让你算得更快,而是让你在等待时不浪费线程,这才是 Web 服务高并发的关键。

四、EF Core + LINQ:从 EF6 到现代 ORM

第四仗是数据访问层。老系统用 Entity Framework 6,它绑定 Framework、不支持异步查询的地方多、性能调优手段有限、批处理弱。我们迁移到 EF Core——它是为现代 .NET 重写的轻量 ORM,全异步、跨平台、性能大幅提升,还支持编译查询、批量更新、拆分查询等现代特性。配合 LINQ,我们能用强类型的、编译期检查的 C# 表达式来写查询,而不是拼裸 SQL 字符串,既安全又能被重构工具理解。下面是我们的 EF Core 数据访问:

// EF Core + LINQ:强类型查询编译期检查,全异步,告别裸 SQL 拼接
public class AppDbContext : DbContext
{
    public DbSet<Order> Orders => Set<Order>();

    protected override void OnModelCreating(ModelBuilder b)
    {
        // Fluent 配置:索引、关系、约束都在代码里声明,随迁移演进
        b.Entity<Order>().HasIndex(o => o.UserId);
        b.Entity<Order>().HasMany(o => o.Items).WithOne().HasForeignKey("OrderId");
    }
}

// 仓储查询:LINQ 强类型表达,EF Core 翻译成参数化 SQL,天然防注入
public async Task<List<OrderView>> RecentPaidAsync(int userId)
{
    return await _db.Orders
        .Where(o => o.UserId == userId && o.Status == OrderStatus.Paid)
        .OrderByDescending(o => o.CreatedAt)
        .Select(o => new OrderView(o.Id, o.TotalAmount, o.CreatedAt)) // 投影只取所需列
        .Take(20)
        .AsNoTracking()       // 只读查询关闭变更跟踪,更快更省内存
        .ToListAsync();       // 异步执行
}

迁移到 EF Core 让我们的数据访问从"EF6 同步为主、性能受限、绑定 Framework"进化到了"全异步、高性能、跨平台的现代 ORM":查询全程异步,和上层 async/await 链路无缝衔接;LINQ 强类型查询在编译期就能发现字段写错、类型不匹配,而不是等到运行时炸,且 EF Core 自动把查询翻译成参数化 SQL,天然杜绝了 SQL 注入;AsNoTracking、投影只取所需列、拆分查询这些手段让我们能精细地优化每条查询的开销,性能比 EF6 时代好了一大截。我们也警惕 ORM 的经典陷阱:用 LINQ 写出隐式的 N+1 查询、或一不小心把整张表拉进内存再过滤,这些都靠开启 EF Core 的查询日志和用 Include/投影显式控制来规避。现代 ORM 的本质,是在"开发效率(强类型、不写 SQL)"和"性能可控(能看到、能调优生成的 SQL)"之间取得平衡——它替你写 SQL,但绝不让你看不见 SQL,这才是既高效又不失控的数据访问之道。

五、内置依赖注入 + Options 配置模式:告别 Web.config 地狱

第五仗,是解耦与配置。老系统对象到处 new、静态类和单例满天飞,组件之间硬耦合,根本没法做单元测试,换个实现要改一大片;配置则散落在十几个 Web.config 和它们的 transform 文件里,改一个连接串提心吊胆,还没有强类型、没有环境隔离。现代 .NET 内置了一流的依赖注入容器:所有依赖在启动时注册、运行时由容器构造注入,组件只依赖接口、不关心实现,可测试性和可替换性天差地别。配置则用 Options 模式:多源(JSON、环境变量、密钥库)分层合并,绑定到强类型选项类。下面是我们的 DI 注册与 Options 配置:

// 内置 DI + Options 模式:依赖注入解耦 + 强类型分层配置,告别 Web.config
// 1) Options:把配置绑定到强类型类,而非到处读魔法字符串
public class OrderOptions
{
    public int MaxItemsPerOrder { get; set; }
    public decimal FreeShippingThreshold { get; set; }
}

var builder = WebApplication.CreateBuilder(args);

// 配置多源分层:appsettings.json < 环境变量 < 密钥库,高优先级覆盖低优先级
builder.Services.Configure<OrderOptions>(
    builder.Configuration.GetSection("Order"));

// 2) DI:按接口注册实现,生命周期(Scoped/Singleton/Transient)显式声明
builder.Services.AddSingleton<IClock, SystemClock>();
builder.Services.AddScoped<IOrderRepository, EfOrderRepository>();
builder.Services.AddScoped<IOrderService, OrderService>();

// 消费方只声明依赖接口,容器负责构造注入——单测时换 mock 即可
public class OrderService(
    IOrderRepository repo,
    IOptions<OrderOptions> opts) : IOrderService   // 主构造函数,样板更少
{
    private readonly int _max = opts.Value.MaxItemsPerOrder;
}

内置 DI + Options 模式让我们的代码从"对象到处 new、静态单例硬耦合、Web.config 配置地狱"进化到了"依赖注入解耦 + 强类型分层配置":组件只依赖接口、由容器注入实现,单元测试时轻松换成 mock,可测试性从"几乎为零"到"想测哪测哪";生命周期由容器统一管理,再不会有手写单例的线程安全坑;配置从散落的 Web.config 字符串,变成强类型的 Options 类,改错字段名编译期就报错,且多源分层让"开发用本地配置、生产用环境变量和密钥库"的环境隔离干净利落,连接串这类敏感信息也终于离开了代码库。DI 的本质不是炫技,而是把"我自己造我依赖的东西"(硬耦合、不可测)反转为"我声明我需要什么、由外部注入"(松耦合、可测可换)——这个控制反转,正是现代应用能够被测试、被演进、被维护的结构性前提。

六、现代 C# 语言特性:record / 模式匹配 / 可空引用类型

迁到现代运行时,我们也顺势把代码升级到了现代 C# 的写法。老代码里满是冗长的样板:写个不可变的数据载体要手写一堆属性、构造函数、Equals、GetHashCode;判空和类型分支是层层嵌套的 if-else;null 引用异常(NRE)更是线上头号杀手。现代 C# 用 record 一行就声明一个带值相等语义的不可变类型;用模式匹配把繁琐的类型与条件分支写成清爽的 switch 表达式;用可空引用类型让编译器在编译期就揪出潜在的 null 解引用。现代 C# 特性让我们的代码从"样板冗长、判空嵌套、NRE 频发"进化到了"简洁、表达力强、编译期就拦住空引用":一个 record 取代过去几十行的 DTO 样板,且天生不可变、值相等,用作领域值对象和 DTO 再合适不过;模式匹配把过去层层缩进的 if-else 类型判断,压成一目了然的 switch 表达式;而开启可空引用类型后,编译器把"这里可能是 null"标成警告,我们在编译期就消灭了一大批过去要等到线上才暴露的 NRE。这些不只是语法糖——可空引用类型实实在在地把 NRE 这个困扰了我们多年的线上崩溃头号原因,从运行时炸提前到了编译期挡。语言现代化的价值在于:更少的样板意味着更少藏 bug 的地方,更强的类型表达意味着更多错误在编译期就被拦下,而编译期拦下的每一个错误,都是线上少出的一次事故。

七、System.Text.Json + 源生成器:高性能序列化

JSON 序列化是 Web 服务每个请求都要走的热路径,过去我们用 Newtonsoft.Json,它功能全但基于运行时反射,性能和内存分配都不理想。现代 .NET 内置的 System.Text.Json 专为高性能设计,默认就比 Newtonsoft 快、省内存;更进一步,它的源生成器(source generator)能在编译期为你的类型生成序列化代码,彻底免去运行时反射,还能配合 AOT 编译。切换到 System.Text.Json + 源生成器让我们的序列化从"运行时反射、每次都现算"进化到了"编译期生成、零反射高吞吐":作为每个请求的必经热路径,序列化的提速和内存分配的降低直接转化成了整体吞吐的提升和 GC 压力的减轻;源生成器在编译期就把每个 DTO 的读写代码生成好,运行时直接调用、不碰反射,延迟更低更稳定,也为将来上 Native AOT 铺平了路。迁移时我们也踩了兼容性的坑——System.Text.Json 默认行为比 Newtonsoft 严格(比如对大小写、对注释的处理不同),有些老接口的 JSON 契约需要显式配置选项来对齐,我们靠契约测试逐个校准。序列化现代化的本质认知是:在高频热路径上,"基于反射的通用方案"虽然省心,但运行时的反射开销会被请求量成倍放大——把工作从运行时挪到编译期(源生成),是高性能服务榨取吞吐的通用思路。

八、迁移策略:Upgrade Assistant 辅助 + 增量迁移

把一个九年的、跑着核心业务的 .NET Framework 应用迁到现代 .NET,绝不能停机一年大重写。我们的策略是增量迁移:先用 .NET Upgrade Assistant、try-convert 这些官方工具把项目文件转成 SDK 风格、把能自动迁的依赖迁掉,扫描出所有用到 Framework 专有 API(System.Web、HttpContext.Current、WebForms 控件)的地方列成清单;然后一个模块一个模块地剥离、重写、迁移,期间用 .NET Standard 类库作为新老都能引用的桥梁来共享业务逻辑,避免重复代码;迁移好的模块先上线小流量验证,稳了再迁下一个。增量迁移让我们在核心业务持续运行的前提下,平滑地完成了整个技术栈的更替:借助官方工具自动化掉了大量机械的转换工作,人力集中在那些真正需要重写的 Framework 专有依赖上;用 .NET Standard 类库做桥梁,让新老两侧能共享同一份业务逻辑、不必维护两套;每个模块迁移都是小步、可验证、可回退的,而不是把全部风险押在某次大爆炸切换上。最关键的纪律是:绝不一边迁移一边给老系统加新功能堆历史包袱,迁移期间老系统只接受必要的维护性改动,把变化集中到新系统这一侧。技术栈迁移的本质智慧和架构迁移一样——大型系统的现代化从来不是"推倒重来",而是"在系统持续运行中,一块一块地把旧的替换成新的",唯有如此,迁移才能在真实业务的重压下走到终点。

九、7 个 P0 事故复盘

7 事故:(1) 异步不彻底,某处用 .Result 同步等待异步方法在 ASP.NET 上下文死锁,全链路改 async + 严禁 .Result/.Wait();(2) EF Core 的 LINQ 写出隐式 N+1 查询拖垮库,开查询日志 + Include/投影显式控制;(3) System.Text.Json 默认行为比 Newtonsoft 严格导致老接口反序列化失败,补齐 JsonSerializerOptions + 契约测试;(4) DI 生命周期错配,把 Scoped 的 DbContext 注入了 Singleton 导致并发数据错乱,校准生命周期 + 启动时校验;(5) 迁移期残留 HttpContext.Current 在异步下取不到值,改用注入 IHttpContextAccessor;(6) 容器里时区/编码与 Windows 不一致导致解析出错,显式设定 InvariantGlobalization + 时区;(7) 可空引用类型开启后大量警告被图省事用 ! 强行抑制,反而埋下 NRE,要求真正处理 null 而非压警告。每个 P0 都做 5-Why 复盘,固化成代码评审清单或分析器规则,确保同类问题不再复发。

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

6 哲学:(1) 异步要一异到底——半异步比全同步更危险,严禁 .Result/.Wait() 同步阻塞;(2) 依赖注入而非自己 new——控制反转是可测试、可演进的结构前提;(3) 配置用强类型 Options——魔法字符串散落各处是配置地狱的根源;(4) 让编译器替你抓 bug——开可空引用类型、用 record、用模式匹配,把错误挡在编译期;(5) ORM 要看得见 SQL——享受 LINQ 强类型的同时必须能看到、能调优生成的 SQL;(6) 迁移要增量不要重写——用工具辅助 + .NET Standard 桥接,一块块平滑替换。这 6 条哲学,是我们用 7 个 P0 事故和 87 天攻坚换来的集体共识。它们共同指向一个认知:现代 .NET 的优势不只是性能和跨平台,更是它把"异步、依赖注入、强类型配置、编译期检查"这些工程化的好习惯,从需要自律变成了框架默认——顺着框架的现代设计走,你自然就写出了可测、可维护、高性能的代码。

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

7 数字:(1) 同等硬件并发承载:同步模型受限 → 全异步后翻数倍;(2) 请求吞吐:.NET Framework 基线 → 现代 .NET + 异步提升一大截;(3) 部署成本:祖传 Windows 服务器 → Linux 容器集群,license 和资源成本大降;(4) 序列化开销:Newtonsoft 反射 → System.Text.Json 源生成,热路径显著提速;(5) 线上 NRE 崩溃:频发 → 可空引用类型编译期拦截后大幅归零;(6) 单元测试覆盖:几乎为零(无法 mock)→ DI 解耦后想测哪测哪;(7) 配置变更风险:改 Web.config 提心吊胆 → 强类型 Options 编译期校验 + 环境隔离。这些数字背后,是 87 天里 13 个人无数次的异步改造、依赖解耦和迁移演练,但每一个都实打实地转化成了性能、成本和稳定性的提升。当我们把这份数据汇报给管理层时,最有说服力的不是任何 .NET 名词,而是"部署搬到 Linux 后成本砍了一大块、线上空引用崩溃几乎绝迹"这两条。

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

87 天的 .NET 现代化战役,我们走过的不只是一条从 .NET Framework 到 .NET 9、从同步阻塞到全异步、从 Windows 焊死到跨平台容器的技术升级路,更是一次从"被老运行时和重型框架拖累、配置耦合得动弹不得"到"轻量、异步、解耦、跨平台的现代工程体系"的认知跃迁。当应用第一次原生跑在便宜弹性的 Linux 容器上、当同样的服务器在异步化后扛起数倍并发、当开启可空引用类型后线上空引用崩溃几乎绝迹、当我们终于能给每个服务写上单元测试的那一刻,真正点燃我们的,不是 .NET 9 这个版本号,而是"一个被九年历史包袱压得喘不过气的老系统,终于变得轻盈、可测、跑得又快又稳"的踏实与笃定。.NET 现代化没有银弹,关键是理解异步、依赖注入、现代 ORM、强类型配置各自解决什么问题,然后用增量迁移的方式把它们一块块落地——尤其要克制"反正能跑就先不动"的拖延,因为 .NET Framework 已停止演进,留得越久迁移成本越高。愿每一位还困在 Framework、被同步阻塞和 Web.config 折磨的 .NET 同行,都能早日把自己的系统迁上现代的、还在高速生长的技术线。共勉,后会有期。

—— 别看了 · 2026