.NET 6下deals控制器返回全量数据报net::ERR_HTTP2_PROTOCOL_ERROR咨询

已确认的问题特征 #

• 服务共5个控制器，其余控制器接口运行正常，仅deals控制器全量查询接口报错
• 查询逻辑添加.Take(100)截断时可正常返回完整响应，全量查询返回不足20条结果即连接中断
• 排除数据总容量因素：deals表全量数据4.2MB，可正常返回全量结果的organization表数据量为3.9MB，容量差仅0.3MB
• 已尝试无效操作：调整IIS ASP缓冲区上限、升级Windows系统版本、更换多浏览器测试
• 排查限制：暂无法提供接口返回JSON内容、数据表结构，可按需提供对应业务代码定位问题

高频根因及对应修复方式 #

1. JSON序列化阶段触发未捕获异常 #

这是.NET 6默认使用System.Text.Json做序列化时的最高发诱因：

• 触发逻辑：deals实体大概率存在EF Core导航属性循环引用（例如Deals关联Contract、Contract下又挂载对应Deals集合的嵌套结构），或者第20条前后的某条数据存在特殊值（超大精度数字、非法格式日期、未配置序列化规则的枚举值），序列化执行到该位置时抛出异常；HTTP/2协议下服务端未正常返回500错误帧就直接断开连接，前端即报协议错误。前100条截断查询如果刚好没命中触发异常的条目/循环链，就可以正常响应。
• 修复配置：在Program.cs中修改JSON序列化默认规则，先覆盖容易触发异常的配置：

builder.Services.AddControllers()
    .AddJsonOptions(options =>
    {
        // 自动忽略循环引用，替换默认直接抛异常的行为
        options.JsonSerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
        // 兼容特殊浮点值、大数字序列化
        options.JsonSerializerOptions.NumberHandling = JsonNumberHandling.AllowNamedFloatingPointLiterals;
    });

• 快速验证：将接口返回值先映射为无导航属性的扁平DTO，或者在查询后手动调用JsonSerializer.Serialize()把结果序列化成字符串再返回，如果全量查询恢复正常即可确认是序列化问题。

2. HTTP/2单帧大小/连接窗口阈值触发协议中断 #

IIS、.NET 6 Kestrel对HTTP/2的单帧载荷大小、连接传输窗口有默认阈值，和响应总体积无关：如果deals表某条数据存在超长文本字段（例如备注、合同原文、长链接字段），序列化到该条时单HTTP/2帧大小超过默认16KB的阈值（部分IIS版本默认上限更低），就会直接触发协议层连接断开。

• 修复配置：同步调整Kestrel和IIS的HTTP/2参数
  1. 在Program.cs中配置Kestrel HTTP/2限制：

builder.WebHost.ConfigureKestrel(options =>
{
    // 单HTTP/2帧上限调整为1MB
    options.Limits.Http2.MaxFrameSize = 1024 * 1024;
    // 连接初始传输窗口调整为16MB
    options.Limits.Http2.InitialConnectionWindowSize = 1024 * 1024 * 16;
    // 单响应体最大允许大小调整为50MB
    options.Limits.MaxResponseBodySize = 1024 * 1024 * 50;
});

2. 在站点部署的web.config中添加IIS层面的环境变量配置：

<system.webServer>
  <aspNetCore processPath="dotnet" arguments=".\your-api.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess">
    <environmentVariables>
      <environmentVariable name="ASPNETCORE_HTTP2_MAX_FRAME_SIZE" value="1048576" />
    </environmentVariables>
  </aspNetCore>
</system.webServer>

3. EF Core延迟加载导致迭代期数据访问异常 #

如果deals查询开启了EF Core延迟加载（Lazy Loading），序列化阶段迭代结果集时才会逐次访问导航属性触发数据库查询，迭代到第20条左右时如果出现DbContext已释放、数据库查询超时、导航属性关联数据查询异常，同样会导致连接直接中断。

• 验证方式：修改查询语句，使用AsNoTracking().AsSplitQuery().ToList()提前一次性加载全量数据到内存后再返回，如果接口恢复正常即可定位为延迟加载问题，后续按需关闭对应实体的延迟加载、或者提前映射为DTO返回即可。

快速定位技巧 #

临时给站点绑定关闭HTTP/2，强制走HTTP/1.1协议访问接口：如果接口可以正常返回完整结果，或者返回明确的500错误详情，即可确认问题属于上述HTTP/2协议层兼容、序列化异常被吞的场景，不需要排查业务逻辑之外的网络、服务器配置问题。

内容的提问来源于stack exchange，提问作者Halan Oliveira