本文介绍使用 sync.waitgroup 协调异步写操作，确保所有 write 调用完成后再执行 close，避免因提前关闭导致数据丢失或程序异常终止。
本文介绍使用 sync.waitgroup 协调异步写操作，确保所有 write 调用完成后再执行 close，避免因提前关闭导致数据丢失或程序异常终止。
在构建云存储或归档工具（如 ZIP 打包器）时，常需实现自定义 io.Writer，将数据分块异步上传或加密写入。若 Writer 内部启动 goroutine 处理写入（例如缓冲后批量提交），直接调用 Close() 可能立即返回，而底层仍有未完成的 Write() 任务——尤其当最后几块数据（如 4×4096B）仍在排队时，手动 Close() 会跳过等待逻辑，造成静默截断或挂起风险。
核心解决方案：用 sync.WaitGroup 实现写入同步
WaitGroup 是 Go 标准库中专为“等待一组 goroutine 完成”设计的轻量同步原语。你应在 Writer 中集成它，而非依赖外部状态轮询（如检查 closed 标志）或误用 io.EOF（该错误仅表示读取结束，与写入完成无关）。
✅ 正确实践示例：
type AsyncWriter struct {
mu sync.RWMutex
wg sync.WaitGroup
closed bool
// 其他字段：buffer、uploader、mutex 等
}
func (w *AsyncWriter) Write(p []byte) (n int, err error) {
w.mu.RLock()
if w.closed {
w.mu.RUnlock()
return 0, errors.New("writer closed")
}
w.mu.RUnlock()
// 启动写入 goroutine（例如上传/落盘）
w.wg.Add(1)
go func(data []byte) {
defer w.wg.Done()
// 实际写入逻辑（注意：避免直接使用 p，需拷贝！）
buf := make([]byte, len(data))
copy(buf, data)
// upload(buf) 或 writeToFile(buf) ...
}(p)
return len(p), nil
}
func (w *AsyncWriter) Close() error {
w.mu.Lock()
if w.closed {
w.mu.Unlock()
return nil
}
w.closed = true
w.mu.Unlock()
// 关键：阻塞等待所有 Write goroutine 完成
w.wg.Wait()
return nil
}
⚠️ 注意事项：
-
切勿在 goroutine 中直接引用传入的
[]byte：Write的参数p可能被复用，必须显式拷贝（如示例中的make + copy），否则引发数据竞争或脏读。 -
defer Close()有效是因为它绑定到函数作用域末尾，但本质仍是调用同一Close()方法；问题中“defer有效而手动调用无效”，通常说明手动调用位置有误（如未等所有Write发起就调用了Close），或Close实现未正确wg.Wait()。 - 若需支持超时控制，可结合
context.WithTimeout和wg.Wait()的非阻塞轮询（但WaitGroup本身不支持超时，需额外 channel 配合）。 - 对于 ZIP 场景，建议在
Close()中追加校验（如计算并写入 ZIP 结束标记），确保归档完整性。
总结：WaitGroup 是解决异步 Writer 关闭竞态的最简洁、标准且零依赖方案。只要确保每次 Write 前 Add(1)、完成后 Done()，并在 Close 中调用 Wait()，即可 100% 保证所有写入完成后再释放资源——彻底规避“概率性失败”（如 1/4096 截断）问题。
