Go语言defer调用gzip.Close()未写入压缩文件脚本报Unexpected end of data问题

问题根源 #

你的问题核心是defer执行时机与完成信号发送顺序不匹配：

1. gzip.Writer的Close()方法除了释放资源外，还负责将gzip格式的校验和、原始数据长度等footer信息写入底层文件，缺少这部分信息的压缩文件会被解压工具判定为不完整，抛出Unexpected end of data错误。
2. defer语句的执行时机是所属函数即将返回前，如果你将cw.Close()放在defer中，正常流程的执行顺序为：
   • 循环处理完所有待压缩数据
   • 执行done <- 1向控制协程发送任务完成信号
   • 函数准备返回，按后进先出规则执行defer链：先关闭cw写入footer，再关闭底层文件f
3. 如果控制协程收到done信号后立刻执行进程退出操作（如主函数结束、调用os.Exit），操作系统会强制终止所有运行中的协程，worker协程的defer代码根本没有机会执行，导致cw未正常关闭、footer未写入文件。
4. 你主动在done <-1之前调用cw.Close()的写法，是先把footer完整写入文件再发送完成信号，即使控制协程收到信号后立刻退出，也不会影响已写入的文件内容，所以不会报错。

你疑惑的defer后进先出规则本身没有问题：你先注册文件关闭的defer、再注册gzip writer关闭的defer，执行时确实会先关gzip writer再关文件，这个顺序是正确的，问题出在信号发送和defer执行的先后关系。

解决方案 #

如果想保留defer来保证异常场景下的资源释放，可以用以下兼容方案：

cw := gzip.NewWriter(f)
// 保留defer，保证发生异常提前退出时也能关闭资源
defer closeWriter("compression stream", cw)
cw.Name = now + ".csv"

// 中间数据处理逻辑省略

// 循环结束后主动调用一次Close，提前写入footer
closeWriter("compression writer", cw)
// 确认所有数据写入完成后再发送完成信号
done <- 1

gzip.Writer重复调用Close()是安全的，不会产生报错，这种写法既可以覆盖异常场景的资源释放，也能保证正常流程下先写完全部数据再发送完成信号。

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