Express.js返回大体积JSON数据不完整 浏览器加载响应报错

1. 优先排查服务端响应输出逻辑 #

• 大JSON返回时如果没有正确设置Content-Length响应头，或者输出流提前关闭、未完全flush，就会导致浏览器只收到部分数据就判定传输结束，触发JSON解析失败。
• 排查点：
  • 对比响应头里的Content-Length数值和实际返回JSON的字节长度，两者不一致就说明响应被截断
  • 检查接口超时配置：如果接口本身、上层网关/反向代理的超时阈值小于大JSON的序列化+传输耗时，偶发的服务端负载升高就会导致请求中途被掐断，出现截断
  • 检查代码逻辑：确认JSON序列化完成、全量写入输出流之后，再执行流关闭、连接回收的操作，不要在序列化过程中提前return释放资源
• 修复：
  • 大体积响应优先计算准确的Content-Length后再返回，减少分块传输的异常概率
  • 把对应接口、网关、反向代理的超时阈值调整到匹配大响应的传输耗时，留足冗余

2. 反向代理/网关层截断是这类问题最高发的诱因 #

• 反向代理（Nginx、APISIX等）默认的响应缓冲区通常比较小，当返回的JSON体积超过缓冲区阈值时，高负载场景下很容易出现缓冲区刷盘不完整、响应被截断的问题。
• 排查方式：绕过代理层直连后端服务，连续请求20次以上，如果直连从未出现截断，就能确定问题出在代理层。
• 修复：
  • 调大代理层的缓冲配置，以Nginx为例，调整proxy_buffer_size、proxy_buffers参数值，适配大JSON的体积
  • 对返回大JSON的接口单独关闭代理缓冲（Nginx配置proxy_buffering off;），让响应直接流式透传给客户端，绕开缓冲区截断的问题

3. 排除浏览器DevTools的误报情况 #

• Chrome抛出的failed to load response data: no data found for a resource with the given identifier报错，有不小概率是DevTools自身的资源回收机制导致的：页面重载时旧请求的响应缓存被浏览器提前清理，DevTools找不到对应资源就会抛这个错，并不代表接口实际返回异常。
• 排查方式：
  • 打开DevTools后勾选Network面板的Disable cache选项，关闭缓存后再复现
  • 不要通过页面刷新触发请求，直接在浏览器控制台用fetch调用接口，拿到响应后直接输出await response.text()的长度，和服务端计算的JSON实际长度做对比，如果长度一致、JSON.parse()可以正常执行，就说明接口本身没问题，是调试工具的误报

4. 排查响应压缩逻辑异常 #

• 如果接口开启了gzip、brotli等响应压缩，压缩流提前终止的偶发bug会导致浏览器拿到不完整的压缩包，解压后就是截断的JSON内容。
• 排查方式：临时关闭该接口的响应压缩，连续请求多次验证，如果截断问题消失，就定位为压缩逻辑问题。
• 修复：升级或调整压缩中间件配置，确保压缩逻辑读取完完整响应体、完成全量压缩后再结束输出流。

验证修复效果的简易方法：写个简单脚本循环请求接口100次，每次拿到响应后先做JSON.parse()校验，只要出现解析失败就记录响应长度和内容，连续100次无解析错误就说明截断问题已解决。

内容的提问来源于stack exchange，提问作者sabin shree