企业官网建设流程全解析

1. 从经典到革新：重新认识.NET的构建和发布

1.1 为什么这个话题值得再讲一遍

这几年.NET圈子里有个现象挺有意思：很多人还在用.NET Framework时代的老思路看待构建和发布，觉得“编译完拷过去不就行了”。但真正的老开发都知道，构建和发布从来不是“点一下发布”那么简单，它决定了你的程序怎么跑、跑多快、部署到哪、出问题怎么排查。尤其是到了.NET 8和.NET 9这个阶段，构建和发布方式已经不是小修小补，而是从根上换了一套逻辑。

我见过不少团队，项目写的没问题，但发布环节能折腾一整天。要么是目标机器缺少运行时，要么是启动速度慢到被运维投诉，要么是Docker镜像大到几百兆。这些问题，其实都和“还在用旧思路看待构建发布”有关。.NET这几年在构建发布上做的一系列革新，恰恰就是为了把这些老毛病一次性解决掉。

这篇文章会深入拆解.NET构建和发布方式的重大变化，重点讲NativeAOT、单文件发布、剪裁器、源生成器这些真正影响日常开发的方案。我尽量不讲空话，直接说清楚每个方案解决了什么问题、适合什么场景、怎么落地。如果你是刚开始接触.NET，或者正打算把老项目升级到新版本，这篇文章能帮你省不少试错的时间。

1.2 先弄明白“.NET的构建方式”到底指什么

在聊所有革新之前，得先把概念对齐。构建和发布这个词，在不同人口中意思差很多。我通常把它拆成三层来看：

• 编译层：源代码变成IL（中间语言），再由JIT（即时编译器）在运行时变成机器码，或者由AOT（提前编译）在发布时直接变成机器码。
• 打包层：编译产物如何组织，是带运行时一起发布，还是依赖目标机装的运行时，是散成一堆DLL，还是打包成单个文件。
• 部署层：产物如何放到目标环境，是传统的xcopy拷贝，还是走Docker镜像、Azure DevOps、GitLab CI/CD这类的自动化管道。

简单说，编译层决定了程序怎么运行，打包层决定了程序长什么样，部署层决定了程序怎么到达用户手里。.NET这几年所谓的“革新”，其实就是在这三个层面同时发力。老一代的.NET Framework时代，构建方式非常单一：编译成DLL，拷到IIS里，机器上必须装好对应版本的.NET Framework，配好各种权限和管道设置，发布一次像伺候老爷一样。

.NET Core 1.0出来的时候算第一次大革新，解决了跨平台和部署灵活性的问题。但从构建体验来看，很多细节依然别扭：自包含发布能免掉运行时依赖，可整个目录几百个文件，拷起来心惊胆战；JIT模式启动虽然比Framework时代快不少，但冷启动还是挺吃力；DLL地狱减轻了，可构建过程反而复杂了，各种SDK版本、目标框架、NuGet源的问题层出不穷。

到了.NET 7把NativeAOT正式摆上台面，再到.NET 8在剪裁、单文件、性能上继续加码，.NET 9在构建体验上又做了一轮优化，这才算真正意义的“再次革新”。那么这些变量是怎么凑到一起，然后把构建发布这件事彻底改写的？下面从这套全新方案的核心逻辑说起。

2. 新旧逻辑对比：革新前和革新后到底差在哪

2.1 旧的构建发布逻辑有哪些痛点

.NET Framework时代的构建发布，核心逻辑是“共享运行时 + 即时编译”。程序发布的时候，代码只是编译成IL中间语言，真正的机器码生成发生在用户机器上，由JIT按需编译。这套机制的好处是程序可以跨CPU架构运行，坏处也很明显：

• 目标机器必须安装对应版本的.NET Framework，版本装错了程序直接起不来。
• 第一次运行要等JIT把热路径代码编译完，启动速度明显偏慢，服务器上几百个DLL每次重新构建都像重新热身。
• 发布产物碎片化，一个Web应用动不动上百个文件，手工部署容易漏文件，自动化部署也要花不少心思处理文件清单。
• 不同版本之间还有GAC（全局程序集缓存）这种噩梦，DLL放进去之后整个机器都受影响，排查问题简直灾难。

.NET Core时代解决了跨平台和部分部署问题，但“JIT + 共享运行时”的底层逻辑没有根本改变。直到NativeAOT正式落地，才真正把“代码到机器码”这件事放到了构建阶段完成。

2.2 革新后的逻辑：编译时完成更多事情

革新后的.NET构建逻辑，核心思路就一句话：把更多工作从运行时挪到构建期。具体来说有四个维度：

• 提前编译（AOT）：直接用RyuJIT把IL编译成目标平台的机器码，打包成原生可执行文件，运行时不再需要JIT，启动速度直接降一个量级。
• 剪裁（Trimming）：构建时静态分析程序集引用关系，把没用到的那部分框架代码从产物里摘掉，体积能缩小不少。
• 单文件打包：把所有托管DLL、原生库、配置文件按需合并进一个可执行文件，部署不再靠目录结构，而是一个文件走天下。
• 源生成器（Source Generator）：编译期间动态生成代码，替代过去的反射调用。反射是运行时的黑盒，性能差还容易被剪裁切掉，源生成器把需要的信息在编译期就固定下来。

这四个维度叠加在一起，效果非常惊人。一个用JIT模式发布可能要100MB左右的小型服务，换成NativeAOT加剪裁，发布出来可能就10MB上下，启动速度从秒级变成毫秒级，而且不需要目标机预装任何运行时。

在这个新逻辑下，程序跑起来几乎不依赖外部环境了。这一点对容器化部署尤其重要，镜像小了，拉取快了，安全面也窄了，这是运维和开发同时受益的地方。

3. NativeAOT实操：从项目创建到发布一次跑通

3.1 什么项目适合用NativeAOT

先说清楚，NativeAOT不是银弹。我见过有人啥都往上套，结果碰到第三方库不兼容，折腾半天又退回JIT模式。根据我自己的实践，下面几类项目很适合NativeAOT：

• 命令行工具、后台Worker服务，这类程序不依赖大量反射，启动速度要求高。
• 微服务中的小服务，单文件部署到容器里，非常清爽。
• 高性能网关、边缘计算节点这类对启动速度和内存占用有要求的场景。

不太适合的场景包括：严重依赖反射和动态加载的项目、用了大量第三方库但不支持AOT的项目、需要运行时动态生成类型或Emit IL代码的项目。这不是说完全不能用，而是需要额外做兼容改造，成本你得提前算进去。

一个很容易被忽略的点是NativeAOT对平台有要求。你发布到Linux x64就得在Linux环境编译，发布到Windows ARM64就需要对应的SDK和交叉编译条件，比JIT时代的“一次编译到处运行”要复杂一些。

3.2 对象关系映射和JSON序列化的兼容处理

很多人第一次用NativeAOT会踩这个坑：明明代码没问题，发布出来一运行，某个操作就抛异常，提示找不到某个类型或方法。原因通常是反射和动态代码生成在NativeAOT下不可用的连带反应。像Entity Framework Core这种重度依赖反射和运行时模型构建的框架，在NativeAOT下有很多限制。

实际操作中我的建议是，先在项目里启用源生成器版本的EF Core配置，即DbContext和实体模型通过DbContextOptionsBuilder明确注册，不要依赖运行时扫描。EF Core的UseNpgsql、UseSqlServer这类方法本身是支持AOT的，关键是模型配置要走显式方式：

var optionsBuilder = new DbContextOptionsBuilder<MyDbContext>(); optionsBuilder.UseSqlServer(connectionString); optionsBuilder.UseModel(MyDbContextModel.Instance);

这里的MyDbContextModel就是EF Core编译期生成的那个模型类。这个类在传统模式里不存在，但在开启dotnet publish的AOT编译后，EF Core的源生成器会自动生成它。所以项目里不要再用OnModelCreating里动态反射找实体了，尽量把所有实体关系写清楚。

JSON序列化同样有坑。System.Text.Json在JIT模式下可以反射任意类型，但AOT下反射元数据没了，就得靠源生成器提前把序列化代码写出来：

[JsonSerializable(typeof(OrderDto))] [JsonSerializable(typeof(List<OrderDto>))] internal partial class AppJsonSerializerContext : JsonSerializerContext { }

然后序列化的时候显式传这个Context：

var json = JsonSerializer.Serialize(order, AppJsonSerializerContext.Default.OrderDto);

你别嫌麻烦，等发布出来跑起来就会发现，这个多写的几步其实换来的是序列化速度提升，以及“少了反射元数据”带来的体积下降和安全提升。

3.3 发布命令与参数选择

创建一个新项目时，可以用模板直接带上AOT支持。Visual Studio 2022的ASP.NET Core Minimal API模板里勾选“Enable Native AOT publish”，或者直接用命令行：

dotnet new webapiaot -n AotDemo

这个模板会生成一个精简版的最小API项目，并且带好了上述源生成器相关的配置，适合新手直接从这个模板起步。但如果你改造现有项目，就要手动加几个关键属性到csproj里：

<PropertyGroup> <PublishAot>true</PublishAot> <InvariantGlobalization>true</InvariantGlobalization> <StripSymbols>true</StripSymbols> </PropertyGroup>

InvariantGlobalization意思是使用不区分区域性的全球化模式，能进一步减小体积。如果你的程序不需要处理多语言、时区、特定文化习惯的字符串格式化，可以开启。StripSymbols会把调试符号从产物里去掉，减少体积，但出问题时排查难度会增大，生产环境建议配合单独的符号文件再开。

发布命令是极其简单的：

dotnet publish -c Release -r linux-x64 --self-contained

这里-r linux-x64指定目标运行时，--self-contained确保所有依赖都打进产物。跑完命令后，你会在bin/Release/net8.0/linux-x64/publish/下看到一个可执行文件，没有其他一堆DLL。直接拷走，拷到没装.NET的机器上也能跑。

需要提醒的是，首次编译NativeAOT会比较慢，因为编译核心要做“完整程序静态分析 + 原生代码生成 + 优化”，这比普通发布要多花不少时间。如果是大项目，有个心理准备，可能从十几秒到几分钟不等。建议配合CI/CD的缓存机制，把对象文件缓存下来，增量编译会快很多。

3.4 发布体积和启动性能实测对比

我自己拿一个空的最小API项目做了一组对比，在同样的代码、同样的目标框架为.NET 8的情况下：

数字会因为机器性能有浮动，但量级差别是真实的。特别是冷启动那个数据，从秒级到毫秒级，对服务扩容时冷启动调度的影响是非常大的。实际生产场景中，如果你跑的是Kubernetes，Pod从创建到Ready的时间大大缩短，滚动发布和弹性伸缩的体验会完全不一样。

内存降幅也值得一提。同样是空服务，NativeAOT少了JIT本身占用的内存，也没有多余的反射元数据，内存直接少了六成左右。在内存按GB计费的云原生环境里，这个节省对成本控制是实打实的。

4. 单文件发布和剪裁器：打造轻量部署产物

4.1 单文件不是“把文件打成一个压缩包”那么简单

很多第一次接触单文件发布的同学有个误解，以为就是把输出目录打个zip改个exe后缀。实际上单文件发布是让.NET在生成时启用了AppHost捆绑机制，把所有托管程序集、原生依赖、配置文件都规划妥当后，嵌入到可执行文件里。运行时启动后直接在内存里加载这些程序集，并不是解压到临时目录再跑的。

单文件发布的好处不止是文件数量少了。我维护过几个老项目，传统自包含发布动不动几十个DLL，每次线上更新都要确认文件是否拷全。换成单文件后，发布产物就一个exe，更新的时候替换一个文件就完事，回滚也简单：把旧文件再拷回去就行。

继续用前面的示例项目，在csproj里引入这几项：

<PropertyGroup> <PublishSingleFile>true</PublishSingleFile> <SelfContained>true</SelfContained> <RuntimeIdentifier>linux-x64</RuntimeIdentifier> <PublishTrimmed>true</PublishTrimmed> <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract> </PropertyGroup>

PublishSingleFile启用单文件模式，SelfContained必须为true。IncludeNativeLibrariesForSelfExtract表示把原生库也嵌进去。但注意，原生库在部分场景下是没法直接内存加载的，比如需要指定路径的算法库或中间件，这种情况下运行时会在需要时自动解压到临时目录，这叫“自解压模式”。如果你的应用对临时目录有安全要求，要提前评估好。

4.2 剪裁器的原理和配置

配合单文件同时出现的往往是PublishTrimmed。剪裁器的工作原理是做“程序集级静态分析”，从程序的入口点出发，沿着程序集的引用关系图，遍历所有可能被访问到的代码路径，把那些“不可能被访问到”的类型和成员删掉。

但这个“可能被访问”的判断有局限。反射就是一个典型盲区：你在代码里写typeof(Foo).GetMethod("Bar")，剪裁器不知道字符串“Bar”对应哪个方法，它只能保守地保留所有可能被反射的类型，或者干脆警告你这里不安全。这就是为什么剪裁器有“警告”机制，它检测到可能被剪掉的代码调用时，会输出IL2xxx系列警告。

处理剪裁警告的标准姿势是使用DynamicDependency特性，显式告诉剪裁器某个类型或成员在运行时会被调用，务必保留：

[DynamicDependency(DynamicallyAccessedMemberTypes.PublicMethods, typeof(SomeReflectedType))] public void InvokeReflectedMethod() { var method = typeof(SomeReflectedType).GetMethod("DoSomething"); method.Invoke(null, null); }

这种处理方式比给整个程序集加[DynamicallyAccessedMembers]更精准，剪裁效果也更好，需要维护的点也更少。

4.3 剪裁的影响范围分析和配置细节

剪裁产生的告警分两种：一种是“这个代码可能因为剪裁而出问题”的警告（IL2026等），另一种是“某些程序集未完全兼容剪裁”的提示。前者需要你逐个检查并写特性声明；后者通常是第三方库，需要等库作者适配，或者你在csproj里排除掉那个程序集：

<ItemGroup> <TrimmerRootAssembly Include="ThirdParty.Library" /> </ItemGroup>

TrimmerRootAssembly表示该程序集是“根”，剪裁器会把它整个保留下来，不进行裁剪。这种做法会损失体积，但在第三方库不支持剪裁时它是最快的解法。

有一点要特别提醒：剪裁和反射深度结合的框架，比如某些老版本的Automapper、某些服务定位器容器，碰上裁剪后经常在运行时报“找不到类型”。升级到新版本、切换到源生成器，或者用TrimmerRootAssembly兜底，总得选一条。我在生产环境里最常用的排查方法是在发布时加上--enable-analyzer参数，让编译器多输出分析信息，快速定位有风险的调用。

5. 构建效率与依赖管理：中央包管理和源生成器

5.1 中央包管理解决的是什么问题

说完了发布产物，再来看构建过程本身。.NET 8起官方推荐了中央包管理（Central Package Management，简称CPM），这是一个非常实用的变化。

过去多项目解决方案里，每个csproj都要写包引用版本号。比如Solution里有OrderService、UserService、PaymentService三个项目都用了Microsoft.Extensions.Http，版本可能分别写着8.0.0、8.0.1、8.0.2。时间久了这些版本会悄悄漂移，行为不一致排查起来特别累。基于这种情况，可能就会出现重复、冲突的问题，每个项目的包引用列表还特别长，看着就烦。

CPM的思路是，在解决方案根目录放一个Directory.Packages.props文件，所有项目的包版本都集中在这里定义：

<Project> <PropertyGroup> <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally> </PropertyGroup> <ItemGroup> <PackageVersion Include="Microsoft.Extensions.Http" Version="8.0.2" /> <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" /> </ItemGroup> </Project>

然后在各项目csproj里引用包时只写包名，不写版本号：

<ItemGroup> <PackageReference Include="Microsoft.Extensions.Http" /> </ItemGroup>

注意版本号是写在Directory.Packages.props的PackageVersion节点里的，这个文件用的是根Project标签，不是Project Sdk那种项目文件格式。如果项目里还有老式的PackageReference带版本，CPM模式下会直接报错，你需要把所有版本统一迁移到中央文件里。

这样做的直接好处是版本全局统一，升级一个包版本只改一处，所有项目同步生效，不会出现A项目用了新版B项目还在老版的情况。在大型解决方案里，这个机制的收益非常可观。

5.2 版本覆盖和传递依赖的细节

有统一版本控制的诉求，就必然有例外情况。CPM允许在具体项目csproj里覆盖中央版本，方法是显式写上VersionOverride属性：

<PackageReference Include="Newtonsoft.Json" VersionOverride="12.0.3" />

VersionOverride的优先级高于中央包管理版本。但使用时要克制，这相当于把版本管理又拉回局部化，每用一次就增加一份维护成本。我一般只在迁移过渡期用，长期还是尽量全区统一。

还有一个容易踩的坑是传递依赖版本与中央版本冲突。比如你直接引用了A包，A包又依赖B包2.0，但中央管理文件里定义了B包1.5，这时候NuGet会怎么处理？用自己的实践结论是：中央包管理不会强制覆盖传递依赖的版本，除非你显式设置CentralPackageTransitivePinningEnabled为true，让所有传递依赖也锁定到中央文件中的版本。

<PropertyGroup> <CentralPackageTransitivePinningEnabled>true</CentralPackageTransitivePinningEnabled> </PropertyGroup>

开启这个选项后，整个依赖图会更可控，但偶尔也会出现A包需要B包2.0的新特性，却被锁在1.5上的情况，所以要根据实际项目权衡。总体来说，在大型解决方案里我倾向于开启，并且配合dotnet list package --vulnerable定期检查已知漏洞版本，安全和统一性会有保障许多。

5.3 源生成器如何优化编译期

源生成器是另一个改变“构建方式”的特性。简单理解，它是在编译期间执行的一段代码，可以在编译时读取你的源代码、项目文件甚至环境信息，然后生成额外的C#代码，这些生成的代码和手写的代码一起参与编译。

这个机制和构建方式有什么关系？很大关系。最典型的是解决了反射性能问题。传统反射在运行时查找类型信息，性能差不说，还容易在剪裁时被切掉。源生成器把“查找类型并生成调用代码”这一步挪到编译期间，生成的代码是强类型直调，性能和手写的一样。

拿依赖注入举例，IServiceCollection的传统注册是运行时通过反射扫描程序集来找IService接口的实现类。而源生成器版的注册器，可以在编译期直接生成AddXxx方法，把每个服务注册写死。这样程序启动时少了几千次反射调用，启动速度快了不少。对应到代码上，就是builder.Services.AddSingleton<IMyService, MyService>()这种显式注册比builder.Services.Scan(...)要好。

JSON序列化的源生成器模式我已经在3.2节写过，这里不再重复。核心思想是一致的：能用编译期解决的就不要拖到运行期。这不仅是性能优化，更是新构建方式（AOT、剪裁）的前提条件。对.NET开发者来说，以后写库或者写框架层代码，源生成器会逐渐成为标配，早点习惯这种思维模式有好处。

5.4 构建加速的实战技巧

最后说一个所有人都会遇到的事：构建慢怎么办。.NET本身在这几年做了很多改进，比如增量构建、并行编译、静态缓存等，但项目复杂之后，构建时间还是会上去。几个亲测有效的办法：

• 启用二进制日志分段存储：dotnet build -bl生成构建日志，用dotnet build -flp分段存储，方便定位慢的步骤。
• 把NuGet包源改成国内可访问的镜像地址，或者在公司内网搭一个NuGet私有服务器，第一次拉包的体验会好很多。
• 尽量用global.json锁定SDK版本，避免CI和本地SDK版本不一致导致的重新还原。
• 在CI/CD中开启构建缓存，GitLab Runner可以用cache关键字缓存~/.nuget/packages目录，GitHub Actions也可以配置NuGet缓存插件。
• MSBuild节点复用：dotnet build /m开启多进程编译，多核机器上效果明显。

有一点容易被忽略，构建速度和发布模式的选择也有关。如果你在CI里发布NativeAOT，首次编译很慢，但如果你把编译缓存做好，改动后只重编受影响的那部分，速度会快很多。像GitLab CI的cache:key可以按分支和提交号做，这样每次流水线能复用上次编译的中间产物。

6. 构建和发布过程中的常见问题与排查技巧

6.1 NativeAOT运行时报“方法找不到类型”怎么查

这个问题在NativeAOT下遇到得最多。典型现象是发布成功、启动成功，某个功能点一触发就抛TypeNotFound或者MissingMethodException，但同样的代码JIT模式完全正常。

我建议的排查顺序是：

1. 先把发布时的警告全部过一遍，看有没有IL2xxx系警告，这种警告基本是在提示“某个反射调用可能被剪掉”。
2. 在触发问题的代码前后加日志，打印出反射使用的类型名和成员名，再去源码里查这个类型是否被[DynamicallyAccessedMembers]覆盖了。
3. 找到具体的类型引用后，按前面4.2节的方法补DynamicDependency特性，或者用TrimmerRootAssembly兜底。
4. 重新发布，看警告是否消除，再用问题触发步骤复测。

这个流程听着简单，但实场找起来常常要来回几轮，特别是问题藏在很深的调用链里时。建议在项目早期就开启AOT并跑一遍自动化测试，把这类问题尽早暴露，别拖到上线前。

6.2 单文件发布后配置文件读不到

单文件发布模式下，appsettings.json默认会嵌入程序集里。运行时能通过默认的配置加载机制读到它，但如果你用File.ReadAllText("appsettings.json")去读，就会发现问题：文件不在磁盘上或路径不对。

处理办法有两种：一是把配置文件标记为“复制到输出目录”，同时设置ExcludeFromSingleFile为false，这样它会被正常排出并放在可执行文件旁边；二是用Environment.GetCommandLineArgs()读取运行时解压的实际路径，再拼接配置路径。

在csproj里显式控制一个文件是否嵌入单文件，需要在这类文件上设置ExcludeFromSingleFile属性：

<ItemGroup> <None Update="appsettings.json"> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> <ExcludeFromSingleFile>true</ExcludeFromSingleFile> </None> </ItemGroup>

ExcludeFromSingleFile设为true表示这个文件在单文件发布后依然以独立文件的形式放在输出目录，运行时直接按当前目录读取。注意，“嵌入”和“排除”各有利弊：嵌入后部署简单，但想改配置就得重新发布整个文件；排除后修改配置方便，但发布产物就不是严格意义的单文件了。

6.3 剪裁后第三方库行为异常

剪裁器在对第三方库下手时，如果库本身没声明反射依赖，剪裁器可能过度裁剪掉一些“它以为用不到”的代码。典型例子是一些ORM、序列化工具、表达式树解析库，它们在运行时大量使用反射，但剪裁器静态分析看不出来。

这个问题的隐蔽性在于，不是所有第三方库都出问题，而是取决于库的实现方式。老版本的Newtonsoft.Json由于兼容性包袱，反射用得深，剪裁后经常丢字段。新版System.Text.Json通过源生成器或[JsonSerializable]可以完全规避这个问题。

我处理这类问题时会先看这个库有没有官方AOT支持说明。很多流行库已经在README里写了“Trim/AOT supported”字样，并附上启用方法。如果库确实不支持，最简单的做法是<TrimmerRootAssembly Include="库名" />，放弃对它裁剪，代价是体积回升几MB。如果这个库对性能影响很大，那就要考虑替换库路线，比如Newtonsoft.Json换System.Text.Json，或者找对应支持AOT的替代品。

6.4 发布命令常见报错速查

总结一下我过去一年在群里答疑遇到最高频的报错，方便你对症下药：

如果发布流程走到Docker这一步，还有两个经典坑要提一下。一是容器的base image选择，尽量用官方mcr.microsoft.com/dotnet/aspnet，别自己在基础镜像上装SDK，体积大且容易被攻击面牵连。二是构建镜像时注意--no-restore参数，还原这一步单独跑，可以配合缓存大幅提高构建效率。

7. 把新技术用到老项目的改造经验

7.1 从老项目迁移要先做“体检”

很多人看到新发布方式心痒痒，直接拿老项目开刀，结果搞得鸡飞狗跳。我的建议是迁移之前先做一轮体检，评估一下你的项目到底适不适合这套新方式。

体检清单大致如下：

• 项目里有多少处反射调用？如果大量使用了typeof().GetMethod()、Assembly.GetType()、Activator.CreateInstance这类模式，AOT改造工作量会比较大。
• 是否依赖动态代码生成，比如System.Linq.Expressions的Compile()、Reflection.Emit、Roslyn脚本引擎。这些在AOT下基本无法使用。
• 第三方库的AOT支持度如何。把csproj里的PackageReference全部列出来，逐个查文档或GitHub仓库的AOT兼容说明，这个工作很枯燥但非常必要。
• 有没有使用AppDomain相关的功能，比如AppDomain.CreateInstanceAndUnwrap这种，NativeAOT下的Compatibility模式中部分支持，但限制不少。
• 构建管道里是否依赖了旧版SDK或工具链，如果是，得先统一升级到新版本。

做完这份体检，你会对自己项目的“迁移成本”有一个清晰的判断。如果反射调用数量很少，第三方库也适配得不错，那大胆迁。如果反射满天飞，建议先做一个最小验证项目，把核心流程跑通再动手。

7.2 渐进式改造路线

老项目整体迁移风险大，我更推荐渐进式改造。第一步先在解决方案里新增一个有代表性的小服务，用NativeAOT或者单文件发布跑起来，验证从构建到部署整条链路。第二步把通用的序列化配置、依赖注入注册改成源生成器友好的写法，这一步即便不做AOT，对代码质量和性能也是有益的。第三步再对核心服务做AOT发布试点，结合测试和灰度验证效果。

渐进式改造避免了一次性切换带来的巨大风险，也让团队有时间学习和适应新技术。我见过不少团队为了追求“极致的启动速度”，一把梭把核心服务全改成NativeAOT，结果第三方库在某个边界场景下表现异常，最终被迫回滚。与其这样，不如先把门面服务切过去，用数据说话，再逐步推进。

还有一个容易忽略的点是团队协作。构建发布方式的革新，不只是主程的事，涉及CI/CD配置的维护者、部署环境的管理者、甚至测试环境的搭建方式。建议先在内部做一次技术分享，把新方式的优势和限制说清楚，让相关人员都有心理预期，再动手改造。

8. 构建发布这块后续还能怎么玩

我对这套新构建体系的终极感受是，它让.NET在“云原生友好”这件事上向前迈了一大步。以前做微服务，Java那边有Spring Native和GraalVM，.NET这边总觉得差点意思。现在NativeAOT配合单文件和剪裁，.NET服务可以做得很轻、很快、很依赖环境，容器化部署的体验已经完全不输其它主流生态了。

如果你已经把手上的服务切换成NativeAOT发布，下一步可以试试把PublishAot和PublishTrimmed结合的优化参数调一调，比如<OptimizationPreference>Speed</OptimizationPreference>指定优化目标是速度还是体积，这个参数在.NET 8以后的版本里很好用。还可以尝试用--analyze配合--report生成详细的剪裁报告，让每个程序集被裁剪了多少、哪些成员被保留，全部一目了然。

做容器化的时候，.NET 8开始官方推荐了Chiseled Ubuntu基础镜像。这种镜像去掉了没有必要的包管理器和Shell，攻击面大幅缩小，配合AOT单文件发布，最终镜像体积能压缩到很小的量级。我实际测试过，一个空的最小API在Chiseled镜像上可以做到十几MB的镜像体积，这在以前根本不敢想。

我自己在实验一个想法：把所有业务服务全部统一发布为“单文件原生可执行文件”，然后在CI里做镜像栈的缓存，让每条流水线构建镜像的时间降到一分钟内。目前实践下来，效果很理想，后续细节成熟了我会再展开聊。这篇是系列的第一篇，先把新构建发布方式的主体框架讲清楚，后面再针对NativeAOT的深度调优、单文件的边界场景、以及CI流水线里的最佳实践，继续往深里挖。