ASP.NET Core 与 .NET 高性能 Web API 内存零分配与 Native AOT 编译实战

引言

在高并发云原生微服务场景下，Web API 的吞吐量、尾延迟以及容器冷启动速度直接决定了系统资源的利用率与用户体验。传统的 .NET Web API 往往依赖运行时反射与频繁的堆内存分配，这不仅增加了垃圾回收（GC）的停顿时间，也限制了服务在 Serverless 或弹性伸缩场景下的启动表现。本文将围绕 内存零分配技术 与 Native AOT 编译 两大核心方向，结合代码示例与架构实践，探讨如何打造极致性能的 ASP.NET Core Web API。

一、利用 Span<T> / Memory<T> 与 ArrayPool<T> 减少 GC 压力

在日常请求处理中，字符串切片、字节数组拷贝和临时缓冲区创建是导致 Gen 0/Gen 1 GC 频繁触发的主要原因。借助 Span<T>、Memory<T> 与 ArrayPool<T>，我们可以在不产生额外托管堆分配的前提下完成数据处理。

1. Span<T> 与 Memory<T> 的零拷贝切片

Span<T> 是一个 ref struct，仅能分配在栈上，适合同步方法中的高性能切片与解析；而 Memory<T> 可以跨越 async/await 异步边界，用于异步 I/O 管道。

public static bool TryParseHeaderValue(ReadOnlySpan<char> header, out ReadOnlySpan<char> key, out ReadOnlySpan<char> value)
{
    int colonIndex = header.IndexOf(':');
    if (colonIndex <= 0)
    {
        key = default;
        value = default;
        return false;
    }

    key = header[..colonIndex].Trim();
    value = header[(colonIndex + 1)..].Trim();
    return true;
}

通过 ReadOnlySpan<char> 切片，整个解析过程不会生成任何新的 string 对象，彻底消除了中间字符串的堆分配。

2. ArrayPool<T> 复用大型缓冲区

对于需要临时缓冲区的场景（如网络流读取或自定义协议编解码），直接 new byte[4096] 会给 GC 带来负担，若超过 85,000 字节更会直接进入大对象堆（LOH）。使用 ArrayPool<byte>.Shared 可以安全地租借和归还数组：

public async Task ProcessPayloadAsync(Stream body, CancellationToken ct)
{
    byte[] buffer = ArrayPool<byte>.Shared.Rent(16 * 1024);
    try
    {
        int bytesRead;
        while ((bytesRead = await body.ReadAsync(buffer.AsMemory(), ct)) > 0)
        {
            ReadOnlyMemory<byte> slice = buffer.AsMemory(0, bytesRead);
            await HandleChunkAsync(slice, ct);
        }
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer, clearArray: false);
    }
}

二、System.Text.Json 源生成器替代反射序列化

传统的 JSON 序列化框架在运行时通过反射分析类型元数据，不仅启动慢、内存占用高，而且与 Native AOT 的裁剪机制不兼容。.NET 提供的 System.Text.Json 源生成器（Source Generator）能够在编译期生成强类型的序列化与反序列化代码，实现零反射开销。

定义 JsonSerializerContext

using System.Text.Json.Serialization;

public record OrderSummary(long OrderId, string Status, decimal TotalAmount);

[JsonSourceGenerationOptions(
    PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase,
    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull)]
[JsonSerializable(typeof(OrderSummary))]
[JsonSerializable(typeof(List<OrderSummary>))]
public partial class AppJsonSerializerContext : JsonSerializerContext
{
}

在序列化时直接传入 AppJsonSerializerContext.Default.OrderSummary，即可跳过运行时反射元数据的构建，显著提升吞吐量并降低内存占用。

三、Minimal API 与 Native AOT 裁剪配置及冷启动性能对比

ASP.NET Core 的 Minimal API 配合 WebApplication.CreateSlimBuilder(args)，移除了不必要的传统 MVC 反射中间件，是构建 Native AOT 服务的理想基座。

1. 项目文件（.csproj）配置

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
    <OptimizationPreference>Speed</OptimizationPreference>
  </PropertyGroup>
</Project>

• <PublishAot>true</PublishAot>：开启 Native AOT 编译与 IL 裁剪（Trimming）。
• <InvariantGlobalization>true</InvariantGlobalization>：若无需多区域文化特性，可进一步缩减二进制体积。

2. Minimal API 集成源生成器

var builder = WebApplication.CreateSlimBuilder(args);

builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default);
});

var app = builder.Build();

app.MapGet("/orders/{id:long}", (long id) =>
{
    var order = new OrderSummary(id, "Confirmed", 299.00m);
    return Results.Ok(order);
});

app.Run();

3. JIT 与 Native AOT 冷启动及资源对比

在实际容器化部署测试中，相同业务逻辑的 Minimal API 在开启 Native AOT 后表现出显著优势：

注：JIT 模式在长期稳态运行下凭借分层编译（Tiered Compilation）与 PGO 仍具备极高的峰值吞吐，而 Native AOT 则在冷启动敏感、内存受限的 Serverless 与边缘计算场景下具有压倒性优势。

总结

通过结合 Span<T> / Memory<T> 与 ArrayPool<T> 消除请求链路中的多余堆分配，利用 System.Text.Json 源生成器替代运行时反射，并依托 Minimal API 与 Native AOT 进行深度裁剪编译，开发者能够构建出兼具极低内存占用、极速冷启动与高并发处理能力的现代化 .NET Web API 服务。