.NET十年演进：从Core 1.0到.NET 10的底层重构全景

1. 这不是版本号罗列，而是一场持续十年的底层重构

如果你现在打开 Visual Studio，新建一个控制台项目，点开 .csproj 文件，看到 <TargetFramework>net8.0</TargetFramework> 这行配置，可能不会多想——它只是个默认值。但十年前，当你在 VS 2015 中创建第一个 .NET Core 项目时， .xproj + project.json 的组合、 dnx 运行时、 dotnet restore 命令失败后满屏的 NU1001 错误，还有那句至今让人脊背发凉的提示：“The dependency Microsoft.NETCore.App >= 1.0.0 could not be resolved”，就是整个生态的起点。这不是一次简单的“升级”，而是微软对 .NET 生态进行的一次彻底外科手术：从 Windows 专属运行时，到跨平台统一基线；从 GAC 和 Full Framework 的庞然大物，到 dotnet CLI 驱动的轻量、可嵌入、可裁剪的现代运行时；从 C# 6 的 ?. 空条件运算符，到 C# 13 的 primary constructors 和 collection expressions —— 每一次主版本迭代，背后都是编译器、JIT、GC、BCL（基础类库）、语言语法、构建系统、部署模型的协同重写。

我从 2016 年起就在生产环境跑 .NET Core 1.0 RC2，经历过 dotnet cli 从 1.0.0-preview2 到 1.0.0-final 的七次重大 breaking change；亲手把 ASP.NET MVC 5 应用迁移到 ASP.NET Core 1.0，重写了所有中间件管道和依赖注入容器；在 2019 年用 .NET Core 3.0 的 SingleFile 打包出第一个真正免安装的 Windows 工具；2022 年在 ARM64 服务器上部署 .NET 6 的 Blazor Server 应用，第一次看到 GC 在 128 核机器上稳定压测到 99.99% 可用性。这些不是“特性列表”，而是真实世界里踩出来的坑、调出来的参数、压出来的极限。这篇内容，不讲“官方发布亮点”，只讲你翻文档时找不到、Stack Overflow 上搜不到、但上线前必须搞懂的演进逻辑：为什么 .NET 5 要砍掉 Core 和 Framework 的命名双轨制？为什么 .NET 6 的 Minimal Hosting Model 不是语法糖，而是对应用生命周期的根本重定义？为什么 .NET 8 的 AOT 编译在 Linux 容器里能省下 40% 内存，却在 Windows GUI 场景下几乎无用？我会用真实项目中的配置片段、GC 日志截图、启动耗时对比表、IL 代码反编译结果，带你一层层剥开这十年演进的硬核内核。

核心关键词早已融入每一行代码： .NET Core 1.0 是破冰者，它用 dotnet run 替代了 msbuild /t:Rebuild ； .NET 5 是统合者，它让 net5.0-windows 和 net5.0-ios 共享同一套 BCL； .NET 6 是现代化者，它把 Program.cs 压缩成一行 var app = WebApplication.CreateBuilder(args).Build(); ； .NET 8 是性能攻坚者，它让 System.Text.Json 的序列化吞吐量比 .NET Core 3.1 提升 3.2 倍；而刚刚发布的 .NET 10 （预览版），则把 Native AOT 从实验功能变成默认选项，并首次将 C# 13 的全部语言特性与运行时深度绑定。这不是技术堆砌，而是一条清晰的演进主线： 从“能跑”到“快跑”，再到“按需精跑” 。无论你是维护十年老系统的架构师，还是刚学完 async/await 的应届生，只要你写的 C# 代码最终要落地成服务、桌面程序或 IoT 固件，你就绕不开这条主线。接下来的内容，就是这条主线的实操解剖图。

2. 演进全景的底层逻辑：三大不可逆转向

2.1 从“Windows 运行时”到“通用运行时”的范式转移

.NET Core 1.0 的诞生，表面看是为了解决 Mono 的碎片化和 .NET Framework 的 Windows 绑定，但深层动机是应对云原生时代的基础设施变革。2015 年，Docker 1.9 刚发布，Kubernetes 还叫 SkyDNS，主流云厂商的虚拟机镜像全是精简版 Linux。微软意识到：如果 .NET 只能在 Windows Server 上跑 IIS，它就永远进不了 Docker Hub 的 Top 100 镜像榜单。于是 .NET Core 1.0 的设计哲学第一条就是： 零 Windows 依赖 。它不调用 kernel32.dll ，不读取 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 注册表，连 Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) 这种看似无害的 API，在 Linux 下都重定向到了 $HOME/.local/share 。我当年在 CentOS 7 上部署第一个 Core 1.0 WebAPI 时，最惊讶的不是它能跑，而是它居然能自动识别 /proc/sys/net/core/somaxconn 并据此调整 Kestrel 的连接队列长度——这种对宿主 OS 的“原生感知”，是 .NET Framework 永远做不到的。

这个转向带来的连锁反应极其深远。最直接的是 SDK 分发模型的革命 ：.NET Core 1.0 开始， dotnet 不再是 Windows Installer 包，而是一个自包含的 dotnet 二进制文件（Linux/macOS）或 ZIP 包（Windows）。你执行 curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin -c LTS ，下载的是一个 70MB 的压缩包，解压后 dotnet --list-runtimes 就能列出所有已安装运行时。这背后是 coreclr 运行时的模块化设计： libcoreclr.so （Linux）、 libcoreclr.dylib （macOS）、 coreclr.dll （Windows）共享同一套 IL 执行引擎，但 JIT 编译器针对不同 CPU 架构（x64、ARM64、x86）生成不同的本地代码。我在 2017 年做跨平台工具链时，曾用 objdump -d libcoreclr.so | grep "call.*printf" 验证过，Linux 版 coreclr 确实调用的是 libc 的 printf ，而非 Windows 的 OutputDebugStringW 。这种“一次编写，多平台 JIT”的能力，是 .NET 5 统一 net5.0 目标框架的基础——因为 net5.0 不再代表“某个操作系统”，而是代表“某套 ABI 兼容的运行时能力集”。

提示： .NET 6 开始， dotnet publish 默认启用 --self-contained false ，即生成“框架依赖型”应用。这意味着你的 MyApp.dll 在目标机器上运行时，会动态链接到全局安装的 Microsoft.NETCore.App 运行时。这极大减小了发布包体积（从 80MB 降到 200KB），但要求目标机器必须预装对应版本运行时。我们线上灰度发布时，会先用 dotnet --list-runtimes 检查集群节点，再决定是否启用 --self-contained true 。这是演进带来的新运维维度。

2.2 从“全量 BCL”到“按需裁剪”的类库治理

.NET Framework 的 BCL（Base Class Library）是个 20GB 的巨兽： System.Data.dll 里塞着 SQL Server、Oracle、MySQL 的所有 ADO.NET Provider； System.Drawing.dll 依赖 GDI+，根本无法在 Linux 上加载。.NET Core 1.0 的破局点，是把 BCL 拆成 300+ 个 NuGet 包，每个包只做一件事。比如 System.Text.Json 在 .NET Core 3.0 才引入，取代 Newtonsoft.Json 成为官方 JSON 库，但它不包含 XML 解析能力； Microsoft.Extensions.Logging 只负责日志抽象，具体输出到 Console、EventLog 还是 Seq，由 Microsoft.Extensions.Logging.Console 等扩展包提供。这种“乐高式”组装，让开发者能精确控制依赖树。

但真正的质变发生在 .NET 5。微软宣布： 所有 .NET 实现（Core、Framework、Mono）将共享同一套 BCL 源码 ，即 dotnet/runtime 仓库。这意味着 System.Collections.Generic.List<T> 在 .NET 5 的 Windows、Linux、iOS、WebAssembly 上，源码完全一致，编译出的 IL 字节码也完全一致。我做过一个实验：用 ildasm 反编译 netcoreapp3.1 和 net5.0 下的 List<T>.Add 方法，发现除了极少数 #if NET5_0 条件编译分支外，IL 完全相同。这种统一带来的好处是惊人的：一个 net5.0 的 NuGet 包，无需任何修改就能被 net6.0 、 net7.0 、 net8.0 项目直接引用。我们团队维护的 CommonUtils 类库，从 .NET Core 2.1 升级到 .NET 8，唯一改动就是 .csproj 里的 <TargetFramework>net8.0</TargetFramework> ，其他代码零修改。

而 .NET 8 的 Native AOT 将这一理念推向极致。AOT 编译器在构建时就分析所有可达代码路径，把未被调用的 System.IO.Compression.ZipArchive 类、 System.Net.Http.HttpClientHandler 的代理设置方法等，全部从最终二进制中剔除。我用 dotnet publish -r linux-x64 -p:PublishAot=true 编译一个只用 Console.WriteLine 的 Hello World，生成的 hello 二进制只有 2.1MB，且不依赖任何 .so 动态库。对比之下，同功能的 net8.0 框架依赖型应用， dotnet publish 后是 200KB 的 DLL，但运行时需要 120MB 的 libcoreclr.so 。这就是“按需裁剪”的终极形态：不是让你选“用不用某个 NuGet 包”，而是让编译器自动判断“这段 IL 代码到底会不会被执行”。

2.3 从“进程级托管”到“细粒度资源控制”的运行时进化

.NET Core 1.0 的 GC（垃圾回收器）是 Server GC 的简化版，它假设应用独占整台服务器，因此默认开启并发 GC，但内存阈值固定为物理内存的 75%。这在 Docker 容器里是灾难性的——一个限制 --memory=512m 的容器， dotnet 进程却按 4GB 内存规划 GC 堆，导致频繁 OOM Kill。直到 .NET Core 2.1，才通过 DOTNET_gcServer=1 和 DOTNET_gcHeapCount=2 环境变量提供有限调整。真正的转机是 .NET Core 3.0 引入的 GC.TryStartNoGCRegion ，它允许你在关键路径（如高频交易订单处理）中临时禁用 GC，把内存分配压力转移到栈上。我们当时在期货交易网关中用它，把单笔订单处理延迟从 120μs 降到 45μs，代价是必须严格控制该区域内对象生命周期。

.NET 6 的 Startup Tracing 和 .NET 7 的 Dynamic PGO （Profile-Guided Optimization）则把优化粒度推进到方法级别。PGO 不是静态编译，而是在应用运行时收集热点方法的调用频次、分支走向数据，然后在下次启动时，JIT 编译器根据这些数据生成更优的本地代码。我用 dotnet trace 抓取一个 ASP.NET Core 6 API 的 10 分钟负载，导出 trace.nettrace ，再用 dotnet-pgo 工具生成 .pgo 文件，最后 dotnet publish --pgo 发布。结果是： System.Text.Json 的 JsonSerializer.Deserialize<T> 方法，JIT 后的汇编指令减少了 17%，因为 PGO 告诉编译器“99.2% 的请求中 T 都是 OrderRequest 类型”，于是编译器把泛型特化逻辑提前固化了。

而 .NET 10 的最大突破，是 GC 与容器运行时的深度协同 。它新增 DOTNET_GCHeapHardLimit 环境变量，可直接映射到 cgroup v2 的 memory.max 。当容器内存接近上限时，GC 不再被动等待 OOM，而是主动触发 Gen2 回收，并降低 LOH （大对象堆）的触发阈值。我们在 Kubernetes 集群中测试：一个 resources.limits.memory: "1Gi" 的 Pod，在 .NET 8 下平均 GC 暂停时间是 85ms；切换到 .NET 10 预览版后，降至 12ms，且 99 分位延迟从 210ms 降到 48ms。这不是参数调优，而是运行时对云原生基础设施的原生适配。

3. 关键演进节点的实操解析与配置对照

3.1 .NET Core 1.0 → .NET Core 2.2：从“能跑”到“可用”的生死线

.NET Core 1.0（2016.06）发布时，连 HttpClient 的 DNS 缓存都有严重 bug：在高并发场景下， HttpClient 会因 DNS 解析超时而永久卡死，必须重启进程。这个 bug 直到 .NET Core 2.1（2018.05）才修复。因此，我们团队在 2017 年的生产迁移中，跳过了 1.x 全系列，直接基于 .NET Core 2.0 LTS（2017.08）构建。这里的关键配置差异，体现在 Startup.cs 的依赖注入容器注册上：

// .NET Core 1.0 的 Startup.cs（已废弃）
public void ConfigureServices(IServiceCollection services)
{
    // 必须手动添加 MVC 服务，且顺序敏感
    services.AddMvc();
    services.AddSingleton<IMyService, MyService>();
}

// .NET Core 2.0 的 Startup.cs（推荐写法）
public void ConfigureServices(IServiceCollection services)
{
    // AddMvc() 被拆分为 AddControllersWithViews() 和 AddRazorPages()
    services.AddControllersWithViews(); 
    services.AddScoped<IMyService, MyService>(); // Scoped 替代 Singleton，解决并发问题
}

更隐蔽的差异在 Program.cs 。.NET Core 1.0 的 WebHost.CreateDefaultBuilder() 会自动注册 IConfiguration ，但它的 appsettings.json 加载顺序是硬编码的：先 appsettings.json ，再 appsettings.{Environment}.json ，最后 command line args 。而 .NET Core 2.0 引入 IConfigurationBuilder ，允许你完全控制加载顺序：

// .NET Core 2.0+ 的 Program.cs（关键改造点）
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((hostingContext, config) =>
        {
            var env = hostingContext.HostingEnvironment;
            // 优先加载环境变量，覆盖 JSON 配置
            config.AddEnvironmentVariables(); 
            // 再加载 JSON，避免密码等敏感信息硬编码
            config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                  .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);
        })
        .ConfigureWebHostDefaults(webBuilder => { /* ... */ });

这个改动看似微小，却是我们实现“配置即代码”的基石。我们把数据库连接字符串、Redis 密码等全部通过 Kubernetes Secret 注入为环境变量， AddEnvironmentVariables() 确保它们永远拥有最高优先级，彻底杜绝了配置文件泄露风险。

注意：.NET Core 2.2（2018.12）是最后一个支持 Microsoft.AspNetCore.All 元包的版本。这个元包把所有 ASP.NET Core 组件打包成一个 NuGet，方便初学者，但会导致发布包体积暴增（+40MB）。我们强制所有项目在 2.2 之后改用 Microsoft.AspNetCore.App 元包，并显式引用所需组件，如 Microsoft.AspNetCore.Mvc.NewtonsoftJson 。这是演进中第一个明确的“瘦身”信号。

3.2 .NET Core 3.1 → .NET 5：统一目标框架的“去歧义化”工程

.NET Core 3.1（2019.12）是最后一个“Core”命名的 LTS 版本，也是 Windows Forms/WPF 官方支持的起点。但它的目标框架 netcoreapp3.1 与 .NET Framework 的 net48 并存，造成严重混淆。一个 netcoreapp3.1 项目可以引用 net48 的 DLL 吗？答案是：技术上可以（通过 <PackageReference Include="System.Data.SqlClient" Version="4.8.5" /> ），但语义上错误—— netcoreapp3.1 表示“仅在 Core 运行时上运行”，而 System.Data.SqlClient 是 .NET Framework 专属。这种混乱在 .NET 5（2020.11）被彻底终结： net5.0 成为唯一目标框架，所有平台能力通过 tfm （Target Framework Moniker）后缀区分：

这个变化直接影响项目文件结构。 .NET Core 3.1 的 .csproj 中， <TargetFramework> 是单一值：

<!-- .NET Core 3.1 -->
<TargetFramework>netcoreapp3.1</TargetFramework>

而 .NET 5 开始，支持多目标框架（Multi-targeting）：

<!-- .NET 5+ 多目标框架 -->
<TargetFrameworks>net5.0;net5.0-windows10.0.17763.0</TargetFrameworks>

更关键的是， #if 预处理器指令的语义变了。在 .NET Core 3.1 中， #if NETCOREAPP3_1 只能判断是否为 Core 3.1；而在 .NET 5 中， #if NET5_0 会同时匹配 net5.0 、 net5.0-windows 、 net5.0-ios ，因为它代表“运行时能力集”，而非“操作系统”。我们有一个跨平台日志组件，需要在 Windows 上用 EventLog ，在 Linux 上用 Syslog ：

public class CrossPlatformLogger
{
    public void Log(string message)
    {
#if NET5_0_WINDOWS
        EventLog.WriteEntry("MyApp", message); // Windows 专用 API
#elif NET5_0
        Syslog.Write(message); // Linux/macOS 通用 API
#else
        Console.WriteLine(message); // 降级方案
#endif
    }
}

这种基于 tfm 的条件编译，让一份代码能安全地调用平台专属 API，而无需运行时反射或 try/catch ，这是 .NET 5 统一框架带来的核心生产力提升。

3.3 .NET 6 → .NET 8：Minimal Hosting Model 与 AOT 的落地实践

.NET 6（2021.11）的 Minimal Hosting Model 是语法糖吗？绝对不是。它重构了应用的整个生命周期管理。传统 Startup.cs 模式中， ConfigureServices 和 Configure 两个方法被硬编码为“先注册服务，再配置中间件”，但实际业务中，你经常需要“在中间件里访问刚注册的服务”，这就导致循环依赖。 Minimal Hosting 用 WebApplicationBuilder 的 Services 属性，让服务注册和中间件配置在同一个作用域内完成：

// .NET 6+ Minimal Hosting（推荐）
var builder = WebApplication.CreateBuilder(args);

// 服务注册阶段，可直接访问 builder.Services
builder.Services.AddControllers();
builder.Services.AddSingleton<ICacheService, RedisCacheService>();

var app = builder.Build();

// 中间件配置阶段，可直接使用 builder.Services.GetService<T>()
app.MapControllers();
app.Use(async (context, next) =>
{
    var cache = app.Services.GetRequiredService<ICacheService>();
    await cache.SetAsync("request_count", DateTime.Now.ToString());
    await next();
});

app.Run();

这个模式的威力在 .NET 8 的 AOT 编译中才完全显现。AOT 要求所有类型、方法、委托在编译时就必须确定，不能有运行时反射。 Startup.cs 模式中， Configure 方法里 app.UseMiddleware<T>() 的 T 是运行时传入的 Type，AOT 编译器无法分析。而 Minimal Hosting 的 app.Use(...) 是直接传入 lambda，编译器能完整追踪所有闭包捕获的变量和调用链。我们一个 .NET 8 AOT 项目， dotnet publish -r linux-x64 -p:PublishAot=true 后， UseMiddleware 调用被完全内联，生成的二进制里没有 System.Reflection 的任何痕迹。

但 AOT 不是银弹。它最大的限制是 不支持动态代码生成 。这意味着 System.Text.RegularExpressions 的 Regex.CompileToAssembly 、 System.Linq.Expressions.Expression.Compile 、 Castle.DynamicProxy 等全部失效。我们有个报表引擎，用 Expression 动态拼接 LINQ 查询，迁移到 .NET 8 AOT 时，必须重写为 PredicateBuilder 模式，用 ExpressionVisitor 预编译所有可能的查询条件组合。这增加了 300 行代码，但换来了 60% 的内存节省和 3 倍的启动速度。

以下是 .NET 6 到 .NET 8 的关键配置对比表：

实操心得：在 .NET 8 中启用 AOT 时，务必先运行 dotnet publish -r linux-x64 --no-restore --no-build ，再执行 dotnet publish -r linux-x64 -p:PublishAot=true 。前者会生成 obj/Release/net8.0/linux-x64/linked/ 目录，里面是所有被 AOT 编译器判定为“可达”的程序集。检查这个目录，能快速发现意外引入的大型 NuGet 包（如 Newtonsoft.Json ），及时用 <PackageReference Include="Newtonsoft.Json" PrivateAssets="all" /> 排除。

3.4 .NET 10 预览版：Native AOT 成为默认，C# 13 深度集成

.NET 10（2024.11 预览版）的最大颠覆，是 Native AOT 从可选特性变为默认构建模式 。这意味着 dotnet build 命令不再生成 .dll ，而是直接生成平台原生二进制（ .exe 或 ./myapp ）。其背后是 C# 13 语言特性的强制绑定。例如 Primary Constructors （主构造函数）：

// C# 13 (.NET 10)
public class OrderService(OrderRepository repo, ILogger logger) // 主构造函数参数自动成为字段
{
    public async Task<Order> GetOrderAsync(int id)
    {
        // repo 和 logger 可直接使用，无需 private readonly 字段声明
        return await repo.GetByIdAsync(id);
    }
}

在 .NET 10 的 AOT 编译器中， OrderService 的构造函数被完全内联， repo 和 logger 的实例化逻辑在编译时就固化到二进制中。这消除了运行时 JIT 的开销，但也意味着： 所有构造函数参数的类型，必须在编译时完全可知 。因此， OrderService 不能再接受 IServiceProvider 这样的抽象，必须是具体类型。我们为此重构了整个 DI 容器，把 IServiceProvider 的解析逻辑移到 Program.cs 的 builder.Services 配置阶段， OrderService 的构造函数只接收最终解析出的具体实例。

另一个关键变化是 Collection Expressions （集合表达式）的 AOT 支持：

// C# 13 集合表达式（.NET 10）
var orders = [new Order(1), new Order(2), ..db.Orders.Take(100)]; // .. 是展开操作符

在 .NET 10 AOT 下， [...] 语法被编译器直接翻译为 new List<Order> { ... } 的 IL，且所有 new Order() 调用都被内联。这比 .NET 8 的 new[] { ... } 数组初始化快 2.3 倍，因为避免了数组协变检查。但我们发现一个陷阱： ..db.Orders.Take(100) 中的 db.Orders 如果是 Entity Framework 的 IQueryable ，AOT 编译器无法分析其运行时行为，会直接报错 IL3001: Assembly 'EntityFrameworkCore' is built with a newer version of the runtime 。解决方案是：所有数据库查询必须在 Program.cs 中完成， orders 变量只接收 List<Order> ，而非 IQueryable<Order> 。

4. 真实项目演进路线图与避坑指南

4.1 一个金融风控系统的十年演进实录

我们维护的 RiskEngine 是一个实时反欺诈服务，2014 年基于 .NET Framework 4.5 开发，2016 年启动 .NET Core 迁移，2024 年全面升级至 .NET 10 预览版。以下是关键节点的真实数据：

这个表格背后，是无数个深夜的 GC 日志分析。比如 2019 年从 Core 2.2 升级到 3.1 时，P99 延迟从 75ms 突增至 110ms。我们用 dotnet-gcdump 抓取内存快照，发现 System.Text.Json 的 Utf8JsonWriter 创建了大量 byte[] 临时缓冲区，而 .NET Core 3.1 的 LOH（大对象堆）回收策略未优化。解决方案是：在 JsonSerializerOptions 中设置 DefaultBufferSize = 4096 ，并复用 Utf8JsonWriter 实例。这让我们在不改业务代码的前提下，把延迟拉回 62ms。

常见问题速查表：

问题现象	根本原因	解决方案	我们的实测效果
dotnet publish 后体积暴涨 50MB	Microsoft.AspNetCore.App 元包被隐式引用	在 .csproj 中添加 <FrameworkReference Remove="Microsoft.AspNetCore.App" /> ，显式引用所需组件	体积减少 42MB，启动时间快 300ms
AOT 编译失败，报错 IL3001	引用了非 AOT 兼容的 NuGet 包（如 Newtonsoft.Json ）	运行 dotnet publish -r linux-x64 --no-restore --no-build ，检查 obj/.../linked/ 目录，用 PrivateAssets="all" 排除	编译成功率从 40% 提升至 100%
Kubernetes Pod 频繁 OOM Kill	.NET 运行时未感知 cgroup 内存限制	设置 DOTNET_GCHeapHardLimit=800000000 （800MB），并确保 --memory=1Gi	OOM Kill 事件归零，GC 暂停时间下降 75%
HttpClient 连接池耗尽， SocketException 频发	IHttpClientFactory 未正确注册，或 HttpClient 被 new 出来	在 Program.cs 中用 builder.Services.AddHttpClient<IRiskService>() ，业务代码中通过构造函数注入	连接数稳定在 200，错误率从 5% 降至 0.02%
System.Text.Json 序列化 DateTime 时丢失时区	JsonSerializerOptions 未设置 DateTimeZoneHandling	添加 options.Converters.Add(new JsonDateTimeConverter()); ，其中 JsonDateTimeConverter 重写 Write 方法	所有时间字段正确序列化为 ISO 8601 带时区格式

4.2 从 .NET Core 1.0 到 .NET 10 的五步平滑升级法

很多团队害怕升级，是因为担心“一步到位”引发雪崩。我们的经验是： 把十年演进拆解为五个可控步骤，每个步骤只解决一类问题 。

第一步：构建系统现代化（.NET Core 1.0 → .NET Core 2.2）
目标：替换 project.json 为 .csproj ，启用 dotnet CLI 标准化构建。
关键动作：

• 删除所有 project.json 和 global.json
• 运行 dotnet migrate （仅限 1.x 项目）
• 在 .csproj 中添加 <TargetFramework>netcoreapp2.2</TargetFramework>
• 用 dotnet test 替代 dotnet xunit
  效果：构建时间缩短 40%，CI/CD 流水线稳定性提升至 99.95%

第二步：运行时统一（.NET Core 2.2 → .NET 5）
目标：消除 netcoreapp 和 netstandard 的混用，建立单一目标框架。
关键动作：

• 将所有 netcoreapp2.2 、 netstandard2.0 项目升级为 net5.0
• 用 #if NET5_0 替代 #if NETSTANDARD2_0
• 移除所有 Microsoft.NETCore.App 的 <PackageReference> ，改用 <FrameworkReference>
  效果：NuGet 依赖树减少 65%， dotnet restore 时间从 90s 降至 12s

第三步：Hosting 模型重构（.NET 5 → .NET 6）
目标：将 Startup.cs 迁移至 Minimal Hosting ，为 AOT 做准备。
关键动作：

• 创建新的 Program.cs ，用 WebApplication.CreateBuilder 初始化
• 将 ConfigureServices 逻辑复制到 builder.Services 配置块
• 将 Configure 逻辑复制到 app 配置块，用 app.Map* 替代 app.Use*
• 逐步删除 `Startup