Go HTTP Server 为什么读取请求体后响应变慢

如果一个 Go HTTP 接口“读取请求体以后”才开始变慢，先不要把锅甩给 ResponseWriter。更常见的情况是：客户端还没有上传完，Handler 正在等待 Request.Body；或者服务端已经写出响应，但请求体仍有剩余数据，HTTP/1.x 连接无法顺利复用。

结论：把请求体读取耗时和业务耗时分开记录，在写响应前完成必须读取的数据，并给请求体设置上限。这样才能判断慢在上传、读取、业务还是连接边界。

下面用一个小型“文本摘要接口”串起完整处理方式。它不把示例当成性能测试，而是帮助你建立排查顺序。

先拆开响应变慢的时间段

服务端收到请求头，并不代表请求体已经全部到达。对于流式上传，r.Body.Read 可能等待网络中的下一段数据；如果客户端发送速度慢，服务端看到的就是“读取请求体后响应变慢”。

先把一次请求拆成四段：等待请求体到达、从 Request.Body 读取、业务处理、写出响应。只有后两段都很慢时，才值得继续看业务代码；如果第一段或第二段占大头，增加数据库连接池通常没有帮助。

搭建一个有上限的请求体处理器

小项目可以从一个只接受 1 MiB 文本的 Handler 开始。服务端请求的 Body 始终非空，没有正文时读取会立即得到 EOF；服务端负责关闭它，Handler 不需要重复关闭。

package main

import (
	"fmt"
	"io"
	"net/http"
	"time"
)

func summarize(w http.ResponseWriter, r *http.Request) {
	start := time.Now()

	// 限制单次输入，避免读取阶段无限等待或占用过多内存。
	r.Body = http.MaxBytesReader(w, r.Body, 1

这个例子有三个关键点。第一，MaxBytesReader 把输入边界放在读取入口；第二，读取失败时不再执行后续业务；第三，响应写出放在必要读取之后。示例中的日志只是定位接口，不能代替真正的指标系统。

处理 HTTP/1.x 连接复用边界

慢并不只发生在“读得慢”。如果 Handler 只读了一部分请求体就写响应，服务端还要面对剩余字节属于当前请求还是下一次请求的问题。Go 的 HTTP/1.x 服务端因此可能放弃复用连接；客户端下一次请求就会重新建连，表现为后续请求延迟升高。

对于明确要丢弃的剩余数据，应该根据业务边界决定是否继续消费；对于可能很大的输入，优先拒绝超限请求，而不是为了复用连接无条件读完。不要用一个“总是读取到 EOF”的习惯覆盖所有场景。

HTTP/2 允许某些场景下继续读请求体并写响应，但这不是把 Handler 写成并发读写的理由。官方文档也提醒，不同客户端对这种行为的支持并不一致；需要兼容性时，仍然优先在写响应前读完必要内容。

用日志确认到底慢在哪里

最小可用的验收方式，是让日志至少包含请求标识、读取耗时、业务耗时、响应状态和输入长度。不要只打印一个总耗时，否则无法区分客户端上传慢与服务端计算慢。

readStart := time.Now()
data, err := io.ReadAll(r.Body)
readCost := time.Since(readStart)
if err != nil {
	// 记录读取错误和耗时，保留客户端慢传或连接中断线索。
	log.Printf("read body failed cost=%s err=%v", readCost, err)
	http.Error(w, "bad request", http.StatusBadRequest)
	return
}

workStart := time.Now()
// 业务函数只接收已经读完且通过大小限制的数据。
result := buildSummary(data)
workCost := time.Since(workStart)
log.Printf("read=%s work=%s bytes=%d", readCost, workCost, len(data))

// 日志完成后再写响应，避免遗漏请求体读取阶段的信息。
w.WriteHeader(http.StatusOK)
_, _ = w.Write(result)

如果 read 长而 work 短，优先检查客户端上传速率、代理缓冲、请求体读取方式和超时策略；如果 work 长，才进入数据库、序列化或 CPU 计算排查。两者都短但总耗时长，则应继续看排队、连接建立或中间件。

常见误区与相关问题

• 误区一：看到响应慢就立刻加 Goroutine。若 Goroutine 仍在等待同一个 Request.Body，等待不会消失。
• 误区二：把 ContentLength 当成“已经读完”。它描述的是关联内容长度，不代表字节已经到达 Handler。
• 误区三：为了连接复用无限读取大请求体。大输入应有明确上限，超限后快速返回比无边界等待更安全。

请求体为空时为什么也能读取？ 服务端的 Request.Body 仍然存在，只是会立即返回 EOF。

Handler 要不要手动关闭服务端 Body？ 一般不需要，net/http 服务端会负责关闭；重点是按业务决定读取上限和响应时机。

最应该先看哪个耗时？ 先看从 Handler 开始到读取结束的耗时，再看业务计算耗时；总耗时只能告诉你慢，不能告诉你慢因。