Go HTTP 并发读写导致输入流损坏原因及解决办法

在 Go 的 HTTP 处理器中，**过早向 `http.ResponseWriter` 写入响应会干扰未完成的请求体读取（尤其是 gzip 压缩流）**，根本原因在于底层 TCP 连接复用、HTTP 协议单向性及 Go 标准库对 `Request.Body` 的一次性消费约束；同时，通道未关闭引发 goroutine 永久阻塞，加剧了竞态表现。

你遇到的问题看似是“写响应破坏了读输入”，实则是两个独立但耦合的底层机制共同作用的结果：

? 问题本质解析

1. HTTP 协议非全双工，ResponseWriter 写入会触发底层连接刷新
   Go 的 http.ResponseWriter 在首次调用 Write() 或 WriteHeader() 时，会隐式发送响应头并开始向客户端推送数据。若此时 req.Body（即 multipart 数据流）尚未完全读取完毕，标准库可能因内部缓冲、连接状态同步或 net/http 对 io.ReadCloser 的严格契约而出现行为异常——尤其对 gzip.Reader 这类依赖精确字节流边界的解压器，微小的读取中断或提前 flush 都会导致解压器内部状态错乱，表现为 scanner.Scan() 返回截断/损坏的行（如 \t 分隔符丢失、行首 # 被吞掉），最终触发 len(toks) != 10 的 panic。

2. inputChan 未关闭 → range 永不退出 → donechan <- true 永不执行 → 主 goroutine 死锁
   你的第二个 goroutine 使用 for line := range inputChan 循环，该语法仅在 inputChan 被显式 close() 后才退出。而生产者 goroutine 中虽有 for scanner.Scan() { ... }，但缺少 close(inputChan)，导致 inputChan 持续处于“可接收”状态。结果：消费者 goroutine 卡在 range 的阻塞读上，donechan <- true 永远不执行，主协程 <-donechan 永久挂起——整个 handler 无法返回，http.Server 可能超时关闭连接，进一步扰乱流式读取。

✅ 关键纠正：不是“写响应直接损坏 gzip 流”，而是“未正确结束读取流程 + 提前写响应”共同暴露了 Go HTTP 处理模型对请求体消费的强顺序性要求。

✅ 正确实现：严格遵循“先读完，再写响应”原则

func handler(w http.ResponseWriter, req *http.Request) {
    // 1. 安全获取 multipart part（添加错误检查）
    multiReader, err := req.MultipartReader()
    if err != nil {
        http.Error(w, "invalid multipart: "+err.Error(), http.StatusBadRequest)
        return
    }
    part, err := multiReader.NextPart()
    if err != nil {
        http.Error(w, "no part found: "+err.Error(), http.StatusBadRequest)
        return
    }

    // 2. 包装 gzip reader（必须 defer 关闭！）
    gzipReader, err := gzip.NewReader(part)
    if err != nil {
        http.Error(w, "invalid gzip: "+err.Error(), http.StatusBadRequest)
        return
    }
    defer gzipReader.Close() // ⚠️ 必须关闭，否则资源泄漏且可能影响后续读取

    scanner := bufio.NewScanner(gzipReader)
    inputChan := make(chan string, 1000)
    doneChan := make(chan struct{}) // 使用 struct{} 更轻量

    // 3. 生产者：读取并关闭通道
    go func() {
        defer close(inputChan) // ✅ 关键修复：确保 range 一定能退出
        for scanner.Scan() {
            inputChan <- scanner.Text()
        }
        // 检查 scanner.Err() 是否为 io.EOF 或其他错误
        if err := scanner.Err(); err != nil {
            log.Printf("scanner error: %v", err)
        }
    }()

    // 4. 消费者：验证并处理
    go func() {
        for line := range inputChan {
            if len(line) == 0 || line[0] == '#' {
                continue // 跳过空行和注释
            }
            toks := strings.Split(line, "\t")
            if len(toks) != 10 {
                http.Error(w, "invalid line format: expected 10 tab-separated fields", http.StatusBadRequest)
                return
            }
            // 处理有效行...
        }
        doneChan <- struct{}{}
    }()

    // 5. ✅ 严格禁止在读取完成前写响应！等待处理结束
    <-doneChan

    // 6. 此时才安全写响应
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")
    fmt.Fprintln(w, "Processing completed successfully!")
}

? 关键注意事项

• 永远不要并发写 ResponseWriter：http.ResponseWriter 不是线程安全的，多个 goroutine 同时调用 Write() 可能导致 panic 或响应混乱。所有输出必须由主 goroutine（即 handler 函数本身）在读取完成后统一执行。
• gzip.Reader 必须 Close()：它持有底层 io.Reader，不关闭可能导致 part 的底层连接状态异常，影响 MultipartReader 的后续部分读取（即使当前只读一个 part）。
• 使用 scanner.Err() 检查读取错误：scanner.Scan() 只报告成功，需显式检查 scanner.Err() 获取 I/O 错误（如网络中断、解压失败）。
• 避免 panic 在 HTTP handler 中：应转换为 http.Error() 并返回合适状态码，防止服务崩溃。

? 总结

Go 的 HTTP 处理器强制要求：请求体必须被完整、顺序、无干扰地消费完毕后，才能开始生成响应。任何试图“边读边写”的设计（尤其涉及压缩流、分块传输等敏感场景）都会违反这一契约。修复的核心是两点：① 保证输入通道正确关闭以终结消费者循环；② 将所有 ResponseWriter 操作严格置于读取逻辑之后。这不仅是最佳实践，更是 Go net/http 包的设计前提。