Golang使用bufio.Writer配合gzip压缩大文件出现unexpected EOF问题

问题根因 #

你遇到的unexpected EOF错误本质是bufio.Writer的缓冲残留数据未手动刷入底层存储，具体逻辑如下：

• bufio.Writer本身是带内存缓冲的IO封装，默认缓冲大小为4KB，只有当缓冲被写满、调用Flush()方法、调用Reset()方法时，缓冲内的数据才会被实际写入下层的io.Writer（比如你用到的os.File）。
• 压缩算法（gzip/zstd）的Close()方法仅会把压缩流的结束标记、校验和等收尾数据写入你传入的上层Writer，也就是你这里的bufio.Writer，这部分收尾数据体积很小，远达不到4KB的自动刷写阈值，会滞留在bufio.Writer的内存缓冲中。
• 你如果没有手动调用bufio.Writer的Flush()方法就直接关闭底层文件，这部分收尾数据会直接丢失，导致压缩包缺失结束标识，解压时读到文件末尾都没找到合法的结束标记，就会抛出unexpected EOF错误。
• 你观察到的337MB阈值刚好对应：当原始文件小于该值时，压缩后的总数据量刚好是4KB的整数倍，缓冲被自动刷空，收尾数据也会被连带写入底层文件，所以不会触发错误；当文件大于该阈值时，最后一批压缩数据加收尾数据没有填满缓冲，就会出现残留丢失。
• 直接传入无缓冲的io.Writer（比如直接传os.File实例）时，所有写入操作会直接落盘，没有缓冲滞留，所以流程正常。

修复方案 #

你可以任选以下一种方式解决问题：

1. 调整IO操作顺序：压缩完成后，先调用压缩Writer的Close()方法，再手动调用bufio.Writer的Flush()方法，最后关闭底层文件，操作顺序不可颠倒。
2. 结构体存储的io.Writer字段增加缓冲刷写逻辑，完成写入后通过类型断言判断是否实现了Flush接口，主动刷写残留数据：

// 写入完成后执行以下逻辑
if flusher, ok := yourWriterField.(interface{ Flush() error }); ok {
    if err := flusher.Flush(); err != nil {
        // 处理刷写错误
    }
}

3. 不需要额外性能优化的场景下，直接把无缓冲的文件实例传给压缩Writer，省去中间的bufio.Writer封装即可。

内容的提问来源于stack exchange，提问作者PotatoChips