Go archive/tar 流式写入为什么会阻塞在 Close

Go 的 tar.Writer.Close() 看起来像一个普通收尾动作，但当输出端是 io.Pipe、HTTP 响应或上传流时，阻塞往往不是 tar 在“做很久的压缩”，而是下游没有继续读。io.Pipe 没有内部缓冲，写端必须等读端接住数据；Close 还要把当前归档的填充和尾部写出去，所以最后一步最容易把这个背压暴露出来。

先看清 Close 到底在等待什么

archive/tar 是面向流的归档格式。调用 WriteHeader 后，Header.Size 决定当前条目允许写入多少字节；写完条目再写下一个头，或者直接调用 Close，都会处理当前块的填充。最终的 Close 还要写归档尾部。

因此有两类现象容易混在一起：如果数据量超过 Header.Size，通常很快得到 archive/tar: write too long；如果目标实现了同步背压，Close 可能卡在向目标写最后几个块。后者要先查读端，而不是盲目给 Close 外面再套一层 goroutine。

io.Pipe 为什么会把问题集中暴露在末尾

io.Pipe 的每次写入都要等一个或多个读操作把这批数据完整消费，没有内部缓冲。归档正文较大时，写端可能已经多次等待过，只是读端恰好跟得上；到了 Close，填充和尾部仍要经过同一条管道。如果消费方提前返回、只读了一个文件，写端就会在最后一次写入处停住，看起来像是 Close 阻塞。

排查时沿链路问三个问题：谁持有 PipeReader，它是否持续读取到 EOF，读取失败时是否关闭了另一端。只要读端没有完整消费，写端就不具备“自行完成”的条件。

三种输出目标怎么选

如果业务不要求实时输出，先选文件或缓冲区能显著降低排查成本；只有确定下游会持续消费时，才把 io.Pipe 放进主链路。

让生产者负责 tar，消费者负责读到 EOF

安全的基本结构是：写端 goroutine 创建 tar.Writer，完成每个条目的 WriteHeader 和 Write 后关闭 PipeWriter；消费方从 PipeReader 持续 io.Copy 到最终目标。消费方出错时调用 CloseWithError，让生产者从后续写入中拿到原因。

func streamTar(ctx context.Context, dst io.Writer) error {
    pr, pw := io.Pipe()
    done := make(chan error, 1)

    go func() {
        tw := tar.NewWriter(pw)
        hdr := &tar.Header{Name: "readme.txt", Mode: 0600, Size: int64(len("hello"))}
        // 先写头，再写足 Header.Size 指定的正文，避免 Close 才暴露未写完。
        if err := tw.WriteHeader(hdr); err != nil {
            _ = pw.CloseWithError(err)
            done 

这段结构的关键不在于“把 Close 放到 goroutine 里”，而在于让读端有独立的消费者，并且在客户端断开、上传失败或上下文取消时让两端同时收到错误。真实项目中还要根据目标 io.Writer 是否可重试，决定失败后是否保留临时文件。

常见问题

只调用 tar.Writer.Close 还会阻塞吗？

会。只要底层目标写入本身会等待读端或网络消费，Close 写出的填充和尾部同样受目标约束。

把 io.Pipe 换成 bytes.Buffer 就一定正确吗？

它能消除同步读写等待，但不能修复 Header.Size 错误、写入过多或没有检查 Close 返回值的问题。

为什么消费方只读一个条目时写端不退出？

tar 是连续流，写端还在写后续条目和尾部；读端提前结束后必须关闭管道并把错误传回，否则生产者没有结束信号。

判断这类问题时，先把 Close 看成“继续向下游写收尾数据”，再检查读端是否持续到 EOF。小归档选 bytes.Buffer，大归档可先落盘；只有实时传输链路具备明确的消费者、取消和错误传播时，io.Pipe 才是合适选择。