Blazor WebAssembly AOT 编译是否值得开启
启用 AOT（Ahead-of-Time）编译对 Blazor WASM 项目有明显性能收益，但不是“开就变快”的开关。它确实能缩短启动时间、减少 JIT 开销、提升执行效率，尤其在中大型应用或计算密集型场景下效果更明显；但代价是构建时间显著增长（常翻倍）、发布包体积增大（约 20–40%）、调试体验退化（无法在浏览器 DevTools 中单步调试 C# 源码），且目前仅支持 .NET 6+ 的 Release 构建，Debug 模式下完全不生效。
如何在项目中正确启用 AOT 编译
必须同时满足三个条件才能触发 AOT：目标框架为
net6.0或更高、SDK 版本 ≥ 6.0.300、且在发布时显式启用。关键操作是修改项目文件（
.csproj），添加以下两处配置： 设置
<targetframework>net7.0</targetframework>或
net8.0（推荐用
net8.0，AOT 支持更成熟） 添加
<runaotcompilation>true</runaotcompilation>（注意：不是
AotCompilation或其他拼写） 确保使用
dotnet publish -c Release -p:PublishAot=true命令发布（仅
dotnet build不会触发 AOT）
漏掉任一条件都会静默降级为解释执行（即 IL + interpreter），不会报错，也无日志提示——这是最常被忽略的坑。
AOT 编译失败的典型错误和绕过方法
AOT 是全静态编译，不支持运行时反射、动态代码生成、部分泛型构造等。常见报错包括：
IL9705（反射调用未标注
[UnconditionalSuppressMessage]）、
IL9714（缺少
DynamicDependency）、
IL9721（无法解析泛型实例）。解决思路不是“禁用 AOT”，而是精准补全元数据： 对使用了
typeof(T).GetMethod()等反射调用的类，加
[DynamicDependency(DynamicallyAccessedMemberTypes.PublicMethods, typeof(YourType))]若依赖第三方库（如
Newtonsoft.Json），改用
System.Text.Json（原生支持 AOT）或确认该库已标注 AOT 兼容属性 避免在构造函数或静态初始化器中调用不确定的泛型逻辑；可将部分初始化延迟到
OnInitializedAsync中
错误信息里带
IL9xxx编号的，直接搜 .NET 官方文档 “NativeAOT diagnostics” 能定位具体缺失的注解类型。
验证 AOT 是否真正生效
不能只看构建输出里有没有 “AOT” 字样。真正验证方式只有两个：
检查发布目录下的wwwroot\_framework\文件夹：如果存在大量以
.aot结尾的二进制文件（如
Microsoft.AspNetCore.Components.Web.aot），说明 AOT 成功 打开浏览器 DevTools → Network 面板，加载页面后观察
wasm请求：AOT 启用后，主 wasm 文件名通常含
aot.（如
app.aot.wasm），而非
app.wasm
若看到的是
app.wasm且无
.aot文件，则 AOT 未生效，需回头检查
.csproj和发布命令——很多人卡在这一步却以为“已经开了”。
