当前位置：首页 > 文章列表 > Golang > Go教程 > Go 怎么边生成数据边上传而不落地临时文件

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

来源：17golang原创 2026-09-06 02:18:27 0浏览收藏

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

要点速览

io.Pipe 没有内部缓冲，写入会等待读取端消费，不等于把所有数据放进内存。
生成协程成功要调用 Close，失败要调用 CloseWithError，否则上传端可能一直等。
请求失败后还要关闭 PipeReader，让被网络错误卡住的写入及时退出。

先判断为什么要用 io.Pipe

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

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

边界	应该由谁负责	常见误区
数据生成	编码器和业务循环	把整批记录先收集成大切片
字节传输	`io.Pipe` 与 HTTP Body	把 Pipe 当成有容量的队列
失败通知	`CloseWithError`、请求上下文	只关闭成功分支，错误分支让 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 的写入不是“先缓存再发送”，所以服务端或网络变慢时，生成端会自然受到背压。

Go io.Pipe 将 JSON 编码器、PipeWriter、PipeReader 与 HTTP 请求体连接的静态关系图 — 图1：生成器、io.Pipe 和 HTTP 请求体之间的静态连接；Pipe 没有额外的整批缓存层。

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

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

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

Go io.Pipe 的成功关闭、生成错误和 HTTP 取消三条边界关系图 — 图2：成功 EOF、生成错误和请求取消分别从哪条边界返回，帮助定位上传卡住的问题。

上传完成后检查哪些边界

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

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