Go 怎么边生成数据边上传而不落地临时文件

数据量一大，先把结果组装成 []byte 或临时文件再上传，内存峰值和磁盘占用都会跟着上去。Go 里更合适的做法是用 io.Pipe：生成端写入 PipeWriter，HTTP 请求把 PipeReader 当作请求体，数据就能边生成边发送。

先判断为什么要用 io.Pipe

io.Pipe 适合“一个组件持续产生字节，另一个组件持续消费字节”的场景，例如导出 JSON Lines、压缩归档、生成 CSV 后直接提交接口。它连接的是两个 io.Writer 与 io.Reader 约定，不负责协议重试、断点续传或服务端鉴权。

它的关键特征是同步、无内部缓冲。写端写入的数据会直接交给读端；读端没有继续读取时，写端会阻塞。这样能控制内存，但也意味着必须让读写两边同时开始，不能在同一个 goroutine 里先把大量数据写完再调用上传。

用 io.Pipe 把生成端和上传端接起来

下面的例子把记录编码为 JSON Lines，并通过 PUT 请求发送到一个抽象的上传地址。示例没有创建临时文件，也没有把全部记录放进内存；服务端返回非 2xx 时，调用方会得到明确错误。

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"io"
	"net/http"
)

type Record struct {
	ID    int    `json:"id"`
	Value string `json:"value"`
}

func upload(ctx context.Context, client *http.Client, uploadURL string, records []Record) error {
	r, w := io.Pipe()
	request, err := http.NewRequestWithContext(ctx, http.MethodPut, uploadURL, r)
	if err != nil {
		return err
	}
	request.Header.Set("Content-Type", "application/x-ndjson")

	producerDone := make(chan error, 1)
	go func() {
		encoder := json.NewEncoder(w)
		for _, record := range records {
			// Encode 会逐条写入 PipeWriter，不建立整批字节缓冲。
			if err := encoder.Encode(record); err != nil {
				_ = w.CloseWithError(err) // 让 HTTP 读取端收到生成错误。
				producerDone = http.StatusMultipleChoices {
		return fmt.Errorf("upload failed: server returned %s", response.Status)
	}
	return nil
}

这里的配对关系很重要：client.Do 启动读取请求体，生产协程才会持续向前。io.Pipe 的写入不是“先缓存再发送”，所以服务端或网络变慢时，生成端会自然受到背压。

关闭顺序决定错误能不能传回来

成功路径必须让 PipeWriter.Close 产生 EOF，否则 HTTP 客户端不知道请求体什么时候结束。生成失败不能只写日志，要用 CloseWithError 把错误交给读取端；请求失败后再关闭 PipeReader，避免生产协程长期卡在下一次写入。

实际项目还应给请求绑定超时或取消信号。比如上游查询被取消时，让编码循环尽快停止；如果需要重试，通常应重新创建一对 Pipe 和新的请求，不能复用已经关闭的读写端。

上传完成后检查哪些边界

第一，数据是否真的允许流式传输。如果接口要求准确的 Content-Length，需要先知道长度，或者改用支持分块/分片上传的协议；不能因为用了 Pipe 就假设所有服务端都接受未知长度。第二，响应状态码是服务端结果，不要只判断 client.Do 是否返回错误。第三，生产错误和网络错误要保留原始原因，方便区分编码失败、请求取消和远端拒绝。

如果生成逻辑来自数据库游标、压缩器或 CSV 编码器，资源关闭也要放在生产协程的错误路径中。最小检查清单是：请求有上下文、生产协程有完成信号、成功关闭写端、失败调用 CloseWithError、请求失败关闭读端、响应体被关闭。

相关问题

io.Pipe 会不会把数据全部放进内存？

不会。它是无内部缓冲的同步管道；但编码器和 HTTP 栈仍可能有少量自己的缓冲，不能把它理解成零内存方案。

为什么只调用 Close 不调用 CloseWithError？

Close 表示正常结束，读取端通常看到 EOF；生成失败时应使用 CloseWithError，否则失败可能被误判成完整上传。

上传失败后还能重试同一个 Pipe 吗？

不建议。读写端可能已经关闭或携带错误，重试时重新创建 Pipe、请求和生成过程更安全；数据源也要能重新读取。