在 go 中实现带异步写入（如上传、压缩、加密）的自定义 writer 时，直接调用 close() 可能导致数据丢失——因后台 goroutine 尚未完成最后几批次 write。正确做法是用 sync.waitgroup 协调写入完成与关闭时机。
在 go 中实现带异步写入（如上传、压缩、加密）的自定义 writer 时，直接调用 close() 可能导致数据丢失——因后台 goroutine 尚未完成最后几批次 write。正确做法是用 sync.waitgroup 协调写入完成与关闭时机。
当你为云存储、归档（如 ZIP）或流式加密等场景实现自定义 io.Writer 时，常需将写入操作异步化（例如批量上传到对象存储）。此时 Write() 方法可能仅将数据推入缓冲区或工作队列，由后台 goroutine 持续消费并执行真实 I/O。若在主流程中立即调用 Close()，而未等待这些后台任务结束，就极易造成末尾数 KB 数据静默丢失——尤其在数据长度接近缓冲块边界（如 4096 字节）时，概率虽低但后果严重。
✅ 正确解法：使用 sync.WaitGroup 实现写入完成同步
核心思想是：每次启动一个写入 goroutine 时 wg.Add(1)，该 goroutine 结束前调用 wg.Done()；Close() 方法则阻塞等待 wg.Wait()，确保所有待处理写入彻底完成。
以下是一个精简可靠的实现示例：
type AsyncWriter struct {
mu sync.RWMutex
wg sync.WaitGroup
done chan struct{} // 可选：支持取消
// ... 其他字段（buffer, uploader, etc.）
}
func (w *AsyncWriter) Write(p []byte) (n int, err error) {
// 深拷贝或安全切片，避免 p 被后续 Write 覆盖
data := make([]byte, len(p))
copy(data, p)
w.wg.Add(1)
go func(d []byte) {
defer w.wg.Done()
// 执行实际异步操作：上传、压缩、写磁盘等
if err := w.uploadChunk(d); err != nil {
// 记录错误（不 panic！），可设 error 字段供 Close 返回
w.mu.Lock()
if w.err == nil {
w.err = err
}
w.mu.Unlock()
}
}(data)
return len(p), nil
}
func (w *AsyncWriter) Close() error {
// 等待所有已启动的写入 goroutine 完成
w.wg.Wait()
// 可选：执行最终 flush 或 cleanup（如上传尾部元数据）
if err := w.finalize(); err != nil {
return err
}
return w.err
}
⚠️ 关键注意事项：
-
永远不要在 Write 中直接启动无管控 goroutine：必须配对
Add(1)/Done()，否则WaitGroup会 panic。 -
避免数据竞争：传入 goroutine 的
[]byte必须深拷贝（如示例所示），否则原始切片可能被上层复用覆盖。 -
错误处理要收敛：将异步阶段的错误收集到结构体字段中，由
Close()统一返回，符合io.Closer接口约定。 -
defer Close()有效是因为它绑定在函数退出时执行，天然晚于所有Write()调用；而手动Close()过早调用则暴露竞态——WaitGroup正是为此而生。 - 如需支持上下文取消（如超时、中断），可结合
context.Context与done chan struct{}，在 goroutine 中 select 监听。
总结：sync.WaitGroup 是 Go 中协调“启动即忘”异步任务与资源清理的最轻量、最可靠原语。它不引入额外依赖，语义清晰，且与标准库接口（如 io.WriteCloser）完全兼容——只要你的 Write() 启动了 goroutine，Close() 就必须等待它们落地。
