题干与适用场景
批处理器需要并发处理一组对象，主 goroutine 等待全部任务结束，并在任一任务失败或取消时停止继续派发。请使用 Go 1.25 的 sync.WaitGroup.Go 设计生命周期，说明它与 Add、Done、Wait 的关系、panic 约束、错误传播和取消边界。题目适合后端、基础设施和并发库岗位，核心考察并发任务生命周期，因此归为 coding。
面试官考察点
第一，能否把“启动任务”和“计数”绑定，避免 Add 放在错误位置造成 Wait 竞态。
第二，能否理解 WaitGroup.Go 的契约：传入函数不得 panic，任务返回后计数自动递减；它不提供错误值或取消传播。
第三，能否设计有界并发、停止派发和结果收集，避免 goroutine 泄漏、数据竞争与无限排队。
第四，能否判断何时换用 errgroup.WithContext，而不是把 WaitGroup 当作完整的任务编排器。
第五，能否用测试覆盖成功、取消、panic 防护和 Wait 竞态，并说明 Go 版本与 CI 约束。
回答前需要澄清的问题
- 目标编译器是否固定为 Go 1.25 或更高版本？
- 并发上限是多少，输入是否可能无限流入？
- 首个错误是否应取消其余任务，还是收集全部错误？
- 任务函数是否允许 panic，若不允许由哪一层恢复并转为错误？
- 结果是否需要保持输入顺序，错误是否需要带对象标识？
- 下游调用是否支持 context 取消和幂等重试？
30 秒回答框架
“我用 WaitGroup.Go 把每次启动与计数绑定，用信号量限制并发；任务入口检查 context，把结果和错误写入受保护的收集器。WaitGroup.Go 只负责等待，不负责错误或取消，所以首个错误需要显式取消派生 context；如果需要标准化的首错传播，我会使用 errgroup.WithContext。任务入口必须捕获并转换允许的 panic，测试覆盖取消、并发上限、等待收敛和错误竞态。”
分步骤深入解答
第一步：锁定 API 契约
Go 1.25 在 sync.WaitGroup 增加 Go(f func())。它启动 f 并在函数返回时执行等价的 Done；官方契约要求 f 不应 panic。项目应在 go.mod、CI 镜像和本地工具链中固定版本，避免旧编译器无法识别该方法。
第二步：把并发上限放在任务入口
使用带容量的信号量在调用 Go 前或任务入口获取许可。若在派发循环中阻塞，应同时监听 context，避免取消后仍继续等待许可。
var wg sync.WaitGroup
sem := make(chan struct{}, 8)
for _, item := range items {
if err := ctx.Err(); err != nil { break }
sem <- struct{}{}
item := item
wg.Go(func() {
defer func() { <-sem }()
if ctx.Err() != nil { return }
process(item)
})
}
wg.Wait()第三步：设计错误与取消通道
WaitGroup 不保存错误，也不会取消兄弟任务。派生 context.WithCancel，任务首次写入错误时调用取消；错误收集器使用 channel 或 mutex，读取必须在 Wait 返回后完成，避免并发读写。
第四步：处理 panic 边界
若业务允许把 panic 视为失败，任务入口可用 defer + recover 将其转换为带堆栈的错误，再触发取消。若 panic 表示程序不变量损坏，则不应静默恢复；要在设计中明确记录、监控和进程退出策略。
第五步：避免派发与等待竞态
不要让一个 goroutine 在另一个 goroutine 仍可能调用 Go 时直接 Wait，除非建立明确的生命周期协议。批处理器应由单一派发者决定何时停止新增任务，再调用 Wait；动态递归任务必须说明何时允许嵌套 Go。
第六步：比较 errgroup
errgroup.WithContext 提供首个非 nil 错误、派生取消和可选并发上限，更适合“一个失败就停止”的请求聚合。WaitGroup.Go 更适合只需等待、错误策略自定义或任务生命周期由其他组件管理的场景。
第七步：验证关键不变量
测试应检查每个启动任务最终都会完成计数递减；取消后不再派发新任务；错误只触发一次取消；并发峰值不超过上限；Wait 返回后结果集合不再变化。使用 go test -race 捕获结果收集器的数据竞争。
高质量示范回答
“我先固定 Go 1.25。派发者在 context 未取消时取得信号量，然后调用 wg.Go；任务入口负责释放信号量、检查取消和执行处理。WaitGroup 只提供生命周期等待，不会传播错误，因此我用派生 context、带对象标识的错误 channel 和一次性取消来实现首错策略。允许恢复 panic 时把它转换成错误并保留堆栈；不允许恢复时让进程级策略接管。所有新任务停止派发后再 Wait，等待结束再汇总结果，并配合 go test -race 验证。若需求是首错取消和并发限制，我会优先 errgroup.WithContext。”
常见错误
- 把
WaitGroup.Go当错误组 → 错误不会自动传播 → 显式收集错误或使用 errgroup。 - 取消后仍阻塞在信号量 → 派发器无法退出 → 用
select同时监听 context。 - 任务函数直接 panic → 违反 API 契约并可能中止进程 → 明确恢复转换或让进程策略接管。
- 多个 goroutine 同时修改 slice → 产生数据竞争 → 用 channel、mutex 或任务结束后串行汇总。
- 派发者尚未结束就 Wait → 动态新增任务与等待交错 → 建立停止派发协议。
- 只测最终数量 → 取消和并发峰值错误被掩盖 → 逐项断言不变量并跑 race detector。
- 忽略 Go 版本 → 本地可编译、CI 失败 → 锁定 go.mod、镜像与工具链。
- 用 WaitGroup 代替所有编排 → 重试、超时和首错策略分散且难审计 → 按需求选择 errgroup 或专用调度器。
追问及应对
追问一：Go 能否传入会 panic 的函数？
官方文档要求函数不得 panic。若系统把 panic 视为可恢复业务失败，应在入口统一 recover 并转换错误；否则保留 panic 语义并交给进程级恢复与告警策略。
追问二：如何保证取消后不再启动任务？
派发前检查 ctx.Err()，获取信号量时使用可取消的 select，任务入口再次检查 context。已经启动的任务仍需依赖下游 API 响应取消。
追问三：什么时候 errgroup 更合适？
需要首个错误、兄弟取消和统一等待时优先 errgroup.WithContext；只想等待独立任务或需要自定义错误聚合时可用 WaitGroup.Go。
追问四：可以在等待期间继续调用 Go 吗？
只有在明确生命周期协议且计数不会从零重新变为正数的情况下才安全。常规批处理应先停止派发，再调用 Wait，避免零计数与新增任务交错。
追问五：如何实现结果有序？
为每个输入分配索引，任务只写入对应槽位或发送带索引的结果；等待结束后按索引汇总。不要让多个任务通过 append 共享 slice。
追问六：如何测试 panic 恢复？
注入一个会 panic 的任务，断言恢复层生成带对象标识的错误、触发取消且其他任务最终收敛；另测不恢复路径，确认监控和进程策略符合约定。