使用AOT编译时，千万别图省事用dotnet build——它只是编译，不是发布。必须走dotnet publish，还得带上运行时标识符（-r RID）和--self-contained true，以及/p:PublishAot=true。项目的SDK必须是Microsoft.NET.Sdk，隐式框架引用统统关掉；所有依赖包，像JSON序列化、HTTP客户端、数据库驱动，都得是8.0及以上版本，并且明确支持AOT。
直接敲dotnet build想生成AOT二进制？别想了。Native AOT本质上是发布阶段的行为，得用dotnet publish，并且显式指定RID。不指定的话，编译要么静默失败，要么直接甩你一句“The RuntimeIdentifier must be set for native AOT publish.”
必须用 Microsoft.NET.Sdk 基础 SDK，禁用所有隐式框架引用
AOT对SDK有严格要求：那些带宿主逻辑的SDK，比如Microsoft.NET.Sdk.Web或Microsoft.NET.Sdk.Worker，统统不支持。哪怕你写的是控制台程序，只要.csproj文件开头不是--aot或PublishAot参数就会被无视。
- 具体操作上，有几件事必须做：第一，删掉所有
Microsoft.AspNetCore.App，改用对应的NuGet包（比如Microsoft.AspNetCore.App.Ref），并确保版本≥8.0。 - 第二，如果用到日志、配置、HTTP客户端这些，统一换成
Microsoft.Extensions.*的8.x版本，比如Microsoft.Extensions.Http8.0.0。 - 第三，数据库驱动也得上8.0，例如
Npgsql、Microsoft.Data.Sqlite，否则连接字符串解析会因为反射被裁剪而直接崩溃。
dotnet publish 命令必须带 -r 和 --self-contained
AOT编译的本质是跨平台原生代码生成，不指定RID，构建系统根本不知道目标架构，直接就中断了。别想着用any或者干脆省略——win-x64、linux-x64、osx-arm64这些必须写全。
- 来看一个正确的命令示例：
dotnet publish -c Release -r linux-x64 --self-contained true /p:PublishAot=true /p:PublishTrimmed=true。 - 如果在Windows上遇到“LLVM not found”错误，那就手动安装LLVM，并确保
clang++在PATH环境变量里。Linux和macOS同理。 - 如果调试需要符号文件，加上
--strip-symbols false，否则默认会strip掉pdb，没法attach调试。
JSON 序列化和 HttpClient 必须提前“声明存在”
AOT的静态分析有个硬伤：它无法推导运行时才决定的类型名或方法签名。System.Text.Json默认走反射序列化路径，这条路径会被整段裁剪掉；HttpClient的构造器也可能被移除，运行时报MissingMethodException是常有的事。
- 怎么办？首先，禁用
System.Net.Http.Json扩展，它里面全是反射。改用原始的HttpClient加上StringContent手动发送JSON字符串。 - 其次，如果非要强类型序列化，那就得用
System.Text.Json.SourceGeneration，定义一个[JsonSerializable]上下文类，然后在DI或选项中显式注册TypeInfoResolver。 - 最后，在
rd.xml或项目文件中保留关键类型，比如
真正让人头疼的，不是写对第一行命令，而是所有第三方依赖都得过一遍AOT兼容性筛子。拿Newtonsoft.Json来说，即使升级到13.0.3，某些动态场景照样会崩。DI容器里注册的服务，如果用了表达式树或Activator.CreateInstance，也会在运行时突然消失。这些坑在编译时一声不吭，只会在目标机器上静默失败。
