Blazor WASM应用（Client/Server/Shared）发布耗时过长问题咨询

• 客户端全量编译+AOT编译开销
  Blazor WASM客户端本质是将.NET代码编译为WebAssembly指令，修改客户端代码后，发布流程通常会触发全量重新编译。如果开启了PublishAot（AOT编译），会把所有IL代码转换为Wasm原生指令，这个过程对项目规模、依赖数量敏感，项目越大耗时越久。而服务端仅需编译普通.NET代码，无Wasm编译步骤，速度自然快很多。

• 静态资源的打包与优化流程
  客户端发布时会执行一系列前端资源处理：wwwroot内的文件压缩（Gzip/Brotli）、资源哈希生成（用于缓存）、依赖模块合并。如果你的客户端包含大量静态资源（图片、字体、第三方库），或者启用了全量资源优化，这些步骤会大幅拉长发布时间。服务端发布基本不需要处理这类前端资源优化，耗时自然更短。

• 客户端依赖项的额外处理
  如果客户端项目引用了大量NuGet包，修改代码后发布时，会触发依赖项的重新解析、IL代码到Wasm的转换。而服务端依赖多为.NET服务器端库，无需Wasm转换，依赖处理效率更高。

• 发布配置中的冗余步骤
  检查你的发布配置（PublishProfile或csproj中的发布属性），是否开启了不必要的流程：比如自动运行测试、全量代码分析、多目标框架编译，或者发布后自动同步远程存储（FTP、CDN）的操作。这些步骤在客户端发布时会叠加耗时，而服务端发布可能未启用这些额外流程。

• 增量编译失效
  Blazor WASM的增量编译可能因项目结构变更、缓存文件损坏、编译选项冲突而失效。一旦失效，每次修改客户端代码都会触发全量编译，导致发布时间剧增。服务端的.NET增量编译稳定性更强，不容易出现这类问题。

内容的提问来源于stack exchange，提问作者Stefan Mostert