真实面经题目 · 原创解析
Go 中主协程如何等待其他协程执行完再继续？这道腾讯牛客题的关键是围绕“Go WaitGroup 等待 goroutine”讲清概念、机制、取舍和边界。Go 中主 goroutine 等待其他 goroutine 最常用 sync.WaitGroup：启动前 Add 任务数，每个 goroutine defer Done，主 goroutine 调 Wait 阻塞直到计数归零。需要错误传播和取消时用 errgroup.WithContext 更合适。
可以这样回答：Go 中主 goroutine 等待其他 goroutine 最常用 sync.WaitGroup：启动前 Add 任务数，每个 goroutine defer Done，主 goroutine 调 Wait 阻塞直到计数归零。需要错误传播和取消时用 errgroup.WithContext 更合适。 WaitGroup 内部维护计数器和等待者；Done 等价于 Add(-1)。Add 必须在启动 goroutine 前完成，避免 Wait 先看到计数为 0 返回；Done 用 defer 能覆盖提前 return。 WaitGroup 只负责等待，不传结果也不传错误；channel 适合传数据或完成信号；errgroup 适合错误返回和 context 取消。 不要混入 Linux 进程排查模板。Go 并发验证应关注 goroutine 泄漏、race detector、超时、panic、context 取消和 errgroup。 验证时重点看：看 race detector、goroutine profile、pprof、超时测试、Wait 是否卡住、错误传播和 context 取消。
这题必须围绕“Go WaitGroup 等待 goroutine”本身回答，不能套相邻大类模板。先给定义或目标，再展开机制、边界、取舍和验证抓手。回答时要主动点出题面关键词对应的对象、输入输出和约束条件，避免把具体问题讲成宽泛复习提纲。 本题对应“Go WaitGroup 等待 goroutine”，核心前提是：Go 中主 goroutine 等待其他 goroutine 最常用 sync.WaitGroup：启动前 Add 任务数，每个 goroutine defer Done，主 goroutine 调 Wait 阻塞直到计数归零。需要错误传播和取消时用 errgroup.WithContext 更合适。
WaitGroup 内部维护计数器和等待者；Done 等价于 Add(-1)。Add 必须在启动 goroutine 前完成，避免 Wait 先看到计数为 0 返回；Done 用 defer 能覆盖提前 return。 关键证据要落到goroutine 状态、调度行为、同步计数、阻塞 profile，这样才能说明机制为什么能支撑题目结论。如果继续展开，要对应到 goroutine 生命周期、GMP 调度、channel 或 WaitGroup 语义、context 取消和 pprof/race detector 证据。
WaitGroup 只负责等待，不传结果也不传错误；channel 适合传数据或完成信号；errgroup 适合错误返回和 context 取消。 因此要结合 goroutine 数、阻塞点、context 生命周期、race detector 和 pprof 判断并发设计是否可靠。 这些取舍决定了方案在不同输入规模、延迟、内存、并发、泛化或一致性要求下是否仍然成立。
不要混入 Linux 进程排查模板。Go 并发验证应关注 goroutine 泄漏、race detector、超时、panic、context 取消和 errgroup。 排查时优先看 goroutine dump、block profile、race detector、超时路径、channel 阻塞和 WaitGroup 计数。 需要特别关注极端输入、数据分布变化、资源不足、并发竞争或观测口径错误带来的退化。修复时要先确认 goroutine 是否泄漏、是否有 channel 阻塞、是否缺少取消路径，再处理共享状态和错误传播。
验证时结合 race detector、pprof、goroutine dump、阻塞 profile、context 超时、WaitGroup 计数和 channel 关闭路径。能把并发原语和运行时现象对应起来，答案才不是只背 API。 针对本题，最有价值的验证信号是：看 race detector、goroutine profile、pprof、超时测试、Wait 是否卡住、错误传播和 context 取消。把验证抓手说出来，可以让答案从知识点延伸到Go 并发正确性、等待语义和运行时排查。
Go 中主 goroutine 等待其他 goroutine 最常用 sync.WaitGroup：启动前 Add 任务数，每个 goroutine defer Done，主 goroutine 调 Wait 阻塞直到计数归零。需要错误传播和取消时用 errgroup.WithContext 更合适。 面试官继续追问时，应该沿着这条机制展开：WaitGroup 内部维护计数器和等待者；Done 等价于 Add(-1)。Add 必须在启动 goroutine 前完成，避免 Wait 先看到计数为 0 返回；Done 用 defer 能覆盖提前 return。
优先给出能观察或推导的证据：看 race detector、goroutine profile、pprof、超时测试、Wait 是否卡住、错误传播和 context 取消。 同时补充失败边界：不要混入 Linux 进程排查模板。Go 并发验证应关注 goroutine 泄漏、race detector、超时、panic、context 取消和 errgroup。
应该围绕“Go WaitGroup 等待 goroutine”补适用前提、失败场景和验证证据。先说明哪些条件下这个机制成立，再说明哪些输入规模、并发状态、数据分布或资源限制会让答案需要调整。
看它能否把“Go WaitGroup 等待 goroutine”的机制链路、关键取舍和可观测信号连起来。回答时应落到具体状态变化、数据路径、复杂度、指标或排查工具，而不是只复述定义。
WaitGroup 适合只等待一组 goroutine 完成，channel 适合传递数据或完成信号，errgroup 适合等待同时传播错误和 context 取消。选择时先看是否需要结果、错误和取消语义。
