Go net/http服务端读取请求体超时的超时器组织方式

Go 服务端读取请求体不能只依赖一个全局 ReadTimeout。更稳妥的组织方式是：服务器用 ReadHeaderTimeout 限制请求头；需要读取请求体的处理器再用 http.ResponseController.SetReadDeadline 设置该接口的读取截止时间，并用 http.MaxBytesReader 同时限制体积。

官方文档：https://pkg.go.dev/net/http

ReadTimeout 覆盖整个请求读取过程，无法让不同处理器决定各自可接受的请求体时长。上传、JSON 接口和无请求体接口通常应采用不同的策略。

先把三类超时分开

ReadHeaderTimeout 只约束请求头，读取完头部后连接的读取截止时间会被重置，处理器可以自行判断请求体多慢才算超时。ReadTimeout 则从连接读取开始覆盖整个请求，包括请求体，适合统一上限明确的服务，但不适合大小差异很大的接口。

在处理器里设置请求体截止时间

ResponseController 可以在处理器内设置整个请求的读取截止时间。超过时间后，对 Request.Body 的继续读取会返回错误；若截止时间尚未触发，完成读取后可用零值时间清除。官方文档同时说明，已经超过的截止时间不能靠再次设置来延长。

func withBodyDeadline(next http.Handler, d time.Duration) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        controller := http.NewResponseController(w)
        if err := controller.SetReadDeadline(time.Now().Add(d)); err != nil {
            // 包装器不支持截止时间时直接失败，避免无上限读取
            http.Error(w, "request deadline unavailable", http.StatusInternalServerError)
            return
        }
        defer func() {
            // 未发生超时时清除截止时间，避免影响后续连接状态
            _ = controller.SetReadDeadline(time.Time{})
        }()
        next.ServeHTTP(w, r)
    })
}

传给 NewResponseController 的应是原始 ResponseWriter，或者包装器要实现 Unwrap。如果中间件把它替换成不支持展开的类型，SetReadDeadline 会返回不支持错误，不能忽略。

时间限制要与体积限制配套

只限制时间仍可能让高速客户端在短时间内发送超大内容。MaxBytesReader 专门限制传入请求体，超过上限会返回 *http.MaxBytesError，并在可能时通知服务端关闭连接。把它放在 JSON 解码或文件保存之前，避免业务层先消耗过多内存或磁盘。

func decodeJSON(w http.ResponseWriter, r *http.Request) {
    const maxBody = 1 

超时后不要尝试继续读取

读取截止时间一旦超过，后续 Body 读取仍会报错，重新设置未来时间也不能把这次请求救回来。处理器应停止解析、返回合适错误并结束请求，不要为了“读完剩余数据”进入循环。连接能否复用由协议与服务端状态共同决定，业务代码不应把一次超时请求继续交给下游。

• 公开服务至少配置 ReadHeaderTimeout、WriteTimeout 和 IdleTimeout。
• 按接口体量选择请求体截止时间，不把上传接口和小 JSON 接口设成同一个值。
• 时间上限与字节上限同时启用，避免慢速和高速大包两类资源消耗。
• 记录超时、超限和格式错误的分类指标，但不要在日志中输出请求体敏感内容。

常见问题

已经设置 ReadTimeout，还需要处理器截止时间吗？如果所有接口都能接受相同的总读取上限，可以只用 ReadTimeout；接口差异明显时，处理器级策略更灵活。

context 超时能代替网络读取截止时间吗？不能直接等价。请求上下文适合取消下游工作，底层 Body 读取是否被截止应由连接读取期限控制。