.NET Core 2.2自包含部署（含PublishTrimmed）响应缓慢问题咨询

针对非自包含模式响应耗时<1秒，但启用PublishTrimmed的自包含模式下响应超5秒的问题，结合.NET Core 2.2的特性，提供以下排查方向和解决方法：

• 修剪导致反射依赖丢失
  .NET Core 2.2的PublishTrimmed功能处于早期阶段，修剪逻辑容易误删运行时通过反射加载的类型或程序集。首次请求时系统需要动态尝试恢复这些依赖，直接拉长了响应时间。
  解决：在项目的.csproj文件中添加修剪排除规则，保留关键的程序集或类型：

  <ItemGroup>
    <!-- 保留整个程序集 -->
    <TrimmerRootAssembly Include="YourProjectAssembly" />
    <!-- 或者保留特定类型 -->
    <TrimmerRootType Include="YourNamespace.CriticalType" />
  </ItemGroup>
  

• 自包含模式冷启动开销放大
  自包含部署本身需要初始化完整的.NET运行时，而修剪后的程序集破坏了默认的预编译优化，导致首次请求时JIT编译工作量剧增。
  解决：启用ReadyToRun预编译优化，发布命令添加对应参数：

  dotnet publish -c Release -r linux-x64 --self-contained true /p:PublishTrimmed=true /p:PublishReadyToRun=true
  

  注意：.NET Core 2.2的ReadyToRun仅支持x64架构的Windows和Linux环境，需匹配目标部署的RID。

• 第三方依赖被过度修剪
  部分第三方NuGet包依赖动态加载逻辑，修剪工具无法识别这些隐式依赖，导致关键组件被移除，运行时需要重新加载或初始化这些组件。
  解决：对比非自包含模式的输出依赖列表，检查自包含发布包中缺失的必要文件，手动将对应的NuGet包添加到项目引用，或通过修剪规则排除该包：

  <ItemGroup>
    <TrimmerRootAssembly Include="ThirdParty.Package.Name" />
  </ItemGroup>
  

• Azure Pipeline部署未做预热处理
  部署完成后首次请求会触发应用的冷启动，加上修剪带来的额外初始化开销，导致响应超时。
  解决：在Azure Pipeline的部署阶段后添加预热步骤，调用应用的健康检查接口提前触发初始化：

  az rest --method GET --uri https://your-app-service-url/api/health
  

内容的提问来源于stack exchange，提问作者Stack Overflow