Go archive/tar 怎么边生成边通过 io.Pipe 上传

可以直接把 tar.Writer 写入 io.PipeWriter，再把配对的 io.PipeReader 作为 HTTP 请求体。这样归档数据生成一段就上传一段，不需要先落盘，也不会把完整 tar 包留在内存。关键是：写 tar 必须放到独立 goroutine，并用 CloseWithError 把生成失败传给上传端。

• io.Pipe 没有内部缓冲，上传速度会自然限制打包速度。
• 先关闭 tar.Writer 写完尾部，再关闭 PipeWriter。
• 服务端若强制要求 Content-Length，纯流式方案通常不适用。

为什么不能在同一个 goroutine 里写

io.Pipe 的写操作会等待读取端消费数据。若先在当前 goroutine 中把 tar 全部写完，再发起 HTTP 请求，第一批写入就可能阻塞，因为请求体还没人读取。正确结构是让归档生产者与 HTTP 客户端并行工作，但两者只处理同一篇上传任务。

最小可用的流式上传写法

type Entry struct {
    Name string
    Data []byte
}

func writeTar(pw *io.PipeWriter, entries []Entry) (err error) {
    defer func() { _ = pw.CloseWithError(err) }() // 把最终结果传给请求体读取端

    tw := tar.NewWriter(pw)
    for _, entry := range entries {
        hdr := &tar.Header{
            Name: entry.Name,
            Mode: 0o644,
            Size: int64(len(entry.Data)),
        }
        if err = tw.WriteHeader(hdr); err != nil {
            return err // 头部失败时停止生成
        }
        if _, err = tw.Write(entry.Data); err != nil {
            return err // 请求取消时通常会从这里收到管道错误
        }
    }
    return tw.Close() // 写入 tar 尾部后，defer 再关闭 PipeWriter
}

func uploadTar(ctx context.Context, url string, entries []Entry) error {
    pr, pw := io.Pipe()
    errCh := make(chan error, 1)
    go func() {
        errCh = 300 {
        return fmt.Errorf("上传失败: %s", resp.Status)
    }
    return nil
}

把 Entry.Data 换成文件时，应在每个条目写完后及时关闭文件，并保证写入字节数与 Header.Size 一致，否则 tar.Writer.Close 会报告当前文件未完整写入。

错误和关闭状态怎么对应

生产者失败时，PipeWriter.CloseWithError(err) 会让读取请求体的一侧看到相同错误。反过来，HTTP 请求创建失败、上下文取消或传输失败时，关闭 PipeReader 能解除生产者的阻塞写入。只调用普通 Close 会把生产失败变成 EOF，容易让调用方误判为正常结束。

使用前先确认三个边界

常见问题

io.Pipe 会不会一直占用大量内存？

不会缓存完整归档。它直接匹配读写，慢速上传会让写入阻塞形成背压；内存主要来自单次写入缓冲和业务自己的文件读取缓冲。

为什么上传失败后 goroutine 不退出？

通常是读取端没有关闭，生产者仍阻塞在 PipeWriter.Write。所有提前返回路径都应关闭 PipeReader，并让生产者收到错误。