Go WaitGroup 为什么 Wait 返回后仍有写入

WaitGroup.Wait 返回，只说明对应计数已经归零，不意味着程序里所有 goroutine、结果消费者或缓冲输出都完成。最常见的原因是 Add 放进了新协程、Done 早于真正写入，或者等待的只有生产者而非最终写入者。

先判断你看到的是“共享内存还在变化”，还是“日志、文件内容稍后才可见”。前者要核对任务覆盖和同步边界，后者还可能涉及消费者或 Flush。用 Sleep 拉长等待只能改变出现概率，不能补上缺失的完成条件。官方文档入口：https://pkg.go.dev/sync#WaitGroup。

先确认 Wait 等的是哪一组任务

以批量生成报告行为例，实际工作可能包含生成文本、放进结果通道、消费者写入缓冲器三个职责。若 WaitGroup 只统计生成文本的函数，它返回时只能证明这些函数报告完成。未登记的异步写入者并不会被自动追踪。

先列出等待对象：同一个 WaitGroup 实例、登记的任务、每个任务对应的 Done，以及真正修改结果的位置。不要复制使用过的 WaitGroup，也不要让帮助函数拿到它的值副本；需要协作时传指针，并明确谁负责登记和结束。

比较三类看似相同的写入滞后

手动计数时，最值得先改的是把 Add 从协程函数里移到启动语句之前。当计数为零时，正数登记必须先于 Wait。另一个直接错误是函数开头立即 Done，随后继续写入；那等于提前宣布任务结束。

这些规则对应 Add 和 Done 的官方契约。如果代码内部又启动子协程，应把子工作也纳入约定；父函数退出不代表子工作完成。与其只调整一处 Done，更应该确认“任务”究竟覆盖哪段业务。

让计数覆盖实际的任务函数

若目标只是得到一组内存结果，可以不引入额外输出协程。下面的原创示例在启动前计数，各任务独占一个已分配的切片元素，Wait 返回后才由调用方读取、输出。

package main

import (
    "fmt"
    "strings"
    "sync"
)

// BuildLines 预先分配结果槽，每个任务只写自己的元素。
func BuildLines(names []string) []string {
    lines := make([]string, len(names))
    var wg sync.WaitGroup
    for i, name := range names {
        wg.Add(1) // 在启动任务前登记，避免 Wait 先观察到零。
        go func(index int, text string) {
            defer wg.Done() // 仅在此函数返回时报告完成。
            lines[index] = strings.ToUpper(text)
        }(i, name) // 显式传入值，不依赖循环变量捕获规则。
    }
    wg.Wait()
    return lines // 此后才读取任务写入的结果槽。
}

func main() {
    lines := BuildLines([]string{"alpha", "beta", "gamma"})
    for _, line := range lines {
        fmt.Println(line) // 主协程独占输出，不共享可变缓冲器。
    }
}

按代码语义，预期输出顺序是 ALPHA、BETA、GAMMA，虽然任务完成顺序不固定。这里给的是读者可核对的预期，没有声称已经在本机执行。结果切片不做并发 append，不改长度；每个任务也不读取其他任务的槽位，所以不需要拿 WaitGroup 当成互斥锁。

如果改成多个任务追加同一个切片、写同一个 map 或同时操作同一个非并发安全 Writer，WaitGroup 并不能串行化这些访问。应改为独立结果槽、互斥保护，或让单个消费者拥有可变容器。选择取决于是否需要保序、流式输出及内存占用。

结果队列需要另外等待写入者

对于流式结果，生产者与消费者是两组不同任务。生产者完成后关闭结果通道，消费者读完剩余内容后再报告自己的完成。下面是接入已有业务时的结构片段，不是独立程序，tasks、handle 由调用方提供。

// 片段假设 handle 同步完成写入；它不能内部启动未被等待的异步写入。
var producers sync.WaitGroup
var consumer sync.WaitGroup
results := make(chan string, 8)

consumer.Add(1)
go func() {
    defer consumer.Done()
    for item := range results {
        handle(item) // 实际项目还要传播写入失败，不能默默忽略。
    }
}()

for _, task := range tasks {
    producers.Add(1)
    go func(t string) {
        defer producers.Done()
        results 

结果通道带缓冲，因此发送成功更不能当成“已经写入”的凭证。关闭通道也不会让其中尚未消费的数据消失；必须继续等待处理者。handle 的错误需要额外通过错误通道或受同步保护的状态返回，真实系统还应明确失败后的停止与排空策略。

此结构适合需要单写入者的场景，代价是消费者可能成为瓶颈。若不需要流式输出，前面的结果槽方案更简单；不要为了看起来并发更多而把完成边界拆得不清楚。

缓冲刷新和持久化不是 Wait 的职责

假设消费者只是把文本写进 bufio.Writer，处理函数返回时数据可能还留在缓冲中。由拥有该 Writer 的一方在所有相关写入完成后执行 Flush，并传播错误。Flush 的职责是把缓冲字节交给底层 Writer，不是等待其他协程，也不保证磁盘持久化或远程服务已经确认。

不要在写入者仍工作时由主协程无同步地 Flush；也不要把文件关闭、远端确认和 Wait 混成一个“完成”标志。对于实际存储，应该按所用接口区分写入成功、提交完成和持久化保证，再把对应动作安排到明确的所有者中。

排查时应保留哪些完成条件

比起看日志行的先后，更有帮助的是标注任务批次、登记位置、写入调用完成位置和消费者结束位置。异步日志自身可能排队，所以日志显示顺序不能单独证明共享内存写入发生在 Wait 之后。

WaitGroup.Go 能自动解决所有遗漏吗？

Go 1.25 起提供 WaitGroup.Go，把登记、启动和函数返回后的完成绑定在一起。但回调又启动的未登记异步写入，仍不自动属于这组任务；空组时也要先启动受管理任务再 Wait，且回调不得 panic。最低版本较旧时可保留本文的 Add、defer Done 写法。

Wait 返回后读结果还要另加锁吗？

如果所有相关写入都在对应完成报告之前结束，且没有任何未等待的写入者，才有条件使用这一同步边界读取最终结果。它不允许工作期间无同步读写共享对象；还有下一批任务时，应重新约定批次生命周期，不能让新任务与上一轮结果读取随意重叠。

可以用等待一秒证明修复吗？

不能。延时只给调度更多机会，不证明任务已经结束。读者应针对空任务、多个任务、慢消费者、写入失败和子任务设计可控样例，检查每条完成条件；本文未运行这些测试，也没有以图片替代执行证据。

最终选择可以很朴素：内存批处理用独立结果槽，流式写入单独等待消费者，缓冲输出再由其所有者收尾。Wait 的计数边界必须与业务所说的“完成”一致。