Go HTTP 服务器未读取请求体导致 TCP 连接被远端强制关闭，核心原因是未消费 r.Body，引发底层缓冲区填满、连接阻塞，最终被服务端（或中间代理）主动重置。

go http 服务器未读取请求体导致 tcp 连接被远端强制关闭，核心原因是未消费 `r.body`，引发底层缓冲区填满、连接阻塞，最终被服务端（或中间代理）主动重置。

在你提供的代码中，hello 处理函数调用了 r.ParseForm()，但该方法仅解析 application/x-www-form-urlencoded 或 multipart/form-data 类型的表单数据，而你的压测命令使用的是 -T application/octet-stream（原始二进制流），此时 ParseForm() 实际上不读取 r.Body 的任何字节——请求体仍完整滞留在连接缓冲区中，等待被显式读取。

当 Apache Bench（ab）持续发送 8MB 的 ESServer.exe 文件时，Go 的 net/http 服务器会尝试将数据暂存于内核 socket 接收缓冲区和 Go 的 conn.buf 中。一旦缓冲区耗尽且服务端未及时读取，操作系统或中间网络设备（如防火墙、负载均衡器）会判定连接异常，触发 An existing connection was forcibly closed by the remote host（Windows 错误码 730054），即连接被对端强制终止。

✅ 正确做法：无论是否需要业务逻辑处理请求体，都必须确保 r.Body 被完全读取或显式丢弃。

✅ 推荐修复方案（三选一，按场景优先级排序）

1. 显式丢弃请求体（适用于无需解析的纯转发/探测类接口）

func hello(w http.ResponseWriter, r *http.Request) {
    // 关键：必须消费整个 Body，避免连接挂起
    _, err := io.Copy(io.Discard, r.Body)
    if err != nil && err != io.EOF {
        http.Error(w, "Failed to read body", http.StatusInternalServerError)
        return
    }
    io.WriteString(w, "Hello world!")
}

⚠️ 注意：io.Discard 是高效零拷贝丢弃器，比 ioutil.Discard（已弃用）更现代；Go 1.16+ 应使用 io.Discard。

2. 限制上传大小 + 安全读取（推荐用于真实文件上传）

func uploadHandler(w http.ResponseWriter, r *http.Request) {
    // 设置合理上限（如 16MB）
    const maxUploadSize = 16 << 20 // 16 MiB
    r.Body = http.MaxBytesReader(w, r.Body, maxUploadSize)

    // 安全读取全部内容（或分块处理）
    buf := make([]byte, 4096)
    for {
        n, err := r.Body.Read(buf)
        if n > 0 {
            // 可选：写入磁盘、校验、转存等
        }
        if err == io.EOF {
            break
        }
        if err != nil {
            http.Error(w, "Upload failed", http.StatusBadRequest)
            return
        }
    }
    w.WriteHeader(http.StatusOK)
    io.WriteString(w, "Upload received")
}

3. 使用 ParseMultipartForm（仅适用于 multipart/form-data 表单上传）

若前端实际使用 <form enctype="multipart/form-data"> 提交，则应：

func multipartHandler(w http.ResponseWriter, r *http.Request) {
    // 解析前设置内存/磁盘阈值（防止 OOM）
    err := r.ParseMultipartForm(32 << 20) // 32MB 内存上限，超限自动写入临时磁盘
    if err != nil {
        http.Error(w, "Invalid form", http.StatusBadRequest)
        return
    }

    file, header, err := r.FormFile("file") // 假设字段名为 "file"
    if err != nil {
        http.Error(w, "No file provided", http.StatusBadRequest)
        return
    }
    defer file.Close()

    // 此处可保存 file 到磁盘或处理
    io.WriteString(w, "Received: "+header.Filename)
}

? 补充关键配置优化（针对大请求场景）

你已在 http.Server 中设置了 MaxHeaderBytes 和超时，但还需补充以下项以增强鲁棒性：

server := http.Server{
    Addr:           ":8000",
    MaxHeaderBytes: 30 << 20,              // 30MB（已设，合理）
    ReadTimeout:    30 * time.Second,     // 建议延长至 30s+，尤其上传大文件
    WriteTimeout:   30 * time.Second,
    IdleTimeout:    60 * time.Second,     // 防止长空闲连接被中间设备断开
    Handler:        &myHandler{},
}

? 特别提醒：若服务部署在 Nginx 后方，务必同步检查其配置：

client_max_body_size 16M;      # 必须 ≥ Go 层限制
proxy_read_timeout 60;
proxy_send_timeout 60;

? 总结

• ❌ 错误认知：“只要返回响应，Body 就可忽略” → 导致连接资源泄漏与远端重置
• ✅ 黄金法则：每个 HTTP 请求的 r.Body 必须被 Read、Copy、Close 或 Discard，不可放任不管
• ? 安全底线：始终结合 http.MaxBytesReader 限制上传体积，防范 DoS 攻击
• ? 全链路视角：客户端 → Go Server → 反向代理（Nginx）→ 网络设备，任一环节超限都会触发 connection reset

遵循以上实践，即可稳定支撑 GB 级别大文件上传，彻底规避 forcibly closed by the remote host 类错误。