Go worker pool 停机时任务为什么会丢？关闭顺序、WaitGroup 和排空策略

之前一次常规发布操作后，我们发现异步生成缩略图的最终数量比入队的总数少了几条。检查日志没有出现panic，所有worker进程也都正常退出了。后来把整个停机阶段的执行时序拉出来复盘，根因很明确：进程收到退出信号后，第一时间就取消了worker的工作上下文，还留在channel里没被取走的剩余任务直接没人处理，就直接丢了。

故障不是worker跑太慢，是关闭顺序搞反了

这类问题特别容易出现在「收到停机信号就直接cancel全部context」的通用封装逻辑里。普通HTTP请求确实可以尽可能快地终止，但是后台异步任务完全没必要和HTTP请求在同一个时间点被强制停止。把那次发布后的全流程按时间顺序梳理清楚，根因一眼就能看明白。

这时候别着急往池子里加更多worker。就算把并发数拉得再高，关闭流程先把所有消费者都撤走，剩下留在队列里的任务照样没人处理。排障的第一个判断标准很简单：每一类后台任务在停机阶段，到底要「立刻终止」还是「尽可能处理完所有已入队任务」，两种逻辑的关闭路径完全不能混在一起写。

先定义三类任务的退出规则

不是所有后台任务都值得花时间等全部处理完。先把不同属性的任务划分清楚，代码里才不会出现同一个context同时塞了多个互相冲突的终止目标。

这里聊的worker池专门针对第二类任务做处理。它能保证的边界是：任务已经进入当前进程的输入流之后，只要停机宽限时间没到，worker会一直把队列里的剩余任务全部取完处理。它没办法保证机器掉电、容器被系统强制杀死，或者部署平台根本不给预留宽限时间的场景下任务不会丢失。

由唯一发送方关闭输入channel，让worker自然把队列跑空

channel的关闭操作权限，本来就应该完全属于发送方。最稳妥的实现结构，就是让调度协程独占写入 jobs 的权限，在上游的所有输入都结束之后，直接关闭 jobs；worker端只需要负责从 jobs 读取任务，直到range循环自然结束就可以。

package main

import (
    "context"
    "sync"
)

type Job struct {
    ID string
}

func handle(job Job) {
    // 处理一个已接收任务
}

func drain(input 

这个示例里，input 的持有者，要等确定「不会再有新任务进来」之后，再执行关闭操作。调度协程确认 input 的输入全部结束之后，才会关闭 jobs。这样所有worker都不会提前退出，最后由 workers.Wait() 来确认所有worker都已经正常返回。

WaitGroup不负责终止流程，也不会帮你保存任务

WaitGroup 的作用非常单一：计数归零时，阻塞的 Wait 操作才会返回。它本身不会主动通知worker要停止，更不可能替你把channel里还没被取走的数据存下来。官方文档也明确提过，正向的 Add 调用和 Wait 的先后顺序必须完全正确；如果把 Add(1) 的调用放到刚启动的goroutine内部，很可能出现主协程还没等任务登记就直接退出，导致等待逻辑漏掉部分任务的问题。

新版本的Go标准库提供了 WaitGroup.Go 来同时做任务登记和启动，不过它有最低版本要求，而且传入的任务函数内部不能出现panic。如果要兼容旧版本，或者需要显式在worker内部做panic恢复逻辑，用 Add 搭配 defer Done 的传统写法，逻辑反而更清晰可控。

正确的停机流程要让等待关系逐层收敛

合理的停机逻辑，根本不是「发一个cancel信号广播给所有协程」，而是从入口层往下游逐步收敛：先拦住新的请求不让进来，再终止上游输入流，再等待当前正在处理的任务跑完，最后才退出整个进程。后面排查问题的时候，每一层的状态都可观测，出问题很容易定位。

1. 把服务的就绪检查摘除，或者直接关闭任务提交入口，阻止新的任务继续写入队列。
2. 由输入流的持有者关闭上游channel，明确标识「不会再有新的任务进来」。
3. 调度协程把手里所有已收到的任务全部转发完之后，关闭jobs队列，worker就会自动按range逻辑把剩余任务全部消费完。
4. 主协程阻塞等待WaitGroup；如果等到约定的宽限时间还没跑完，就记录下当前没处理完的任务总数，按照预设的业务策略直接退出，剩下的任务交给持久化逻辑做后续恢复。

如果单个worker里的任务存在长时间阻塞卡住的可能性，给每个单独的任务设置自己的执行超时时间，而不是在T1那个时间点直接把整个排空流程强制取消。这样很容易区分「单个任务超时卡住」和「整个队列主动终止」两种场景，打出来的日志也更容易排查问题。

上线前先补全这四项观测指标

• 入队总数、开始处理数、处理完成数、处理失败数：四个指标的差值一眼就能看出队列有没有积压，或者任务是不是中途丢了。
• 停机触发时间、排空流程结束时间：用来判断你预设的宽限时间是不是足够覆盖正常排空的耗时。
• 队列实时长度、当前活跃worker数：确认worker是正在处理任务、正在阻塞等新任务，还是已经提前被唤醒退出了。
• 未完成任务的业务ID：如果任务已经提前持久化，下次服务启动之后就能直接拉取这批ID继续处理。

这次故障修复之后，发布流程里最核心的变化不是调整了worker的数量，而是整个关闭顺序可以明确校验：先确认输入入口已经关、jobs队列已经关、所有worker都已经正常退出之后，主协程才会结束运行。对于只依赖内存的任务池来说，这就是它能做到的最清晰的边界了。

相关问题

可以让worker自己来关闭jobs队列吗？

不推荐这么做。worker属于接收方，它根本没办法判断是不是还有其他发送方准备往队列里投递任务。由唯一的发送方来关闭channel，职责边界最清晰，也完全避免了往已经关闭的channel里写数据导致panic的问题。

停机的时候用context cancel能不能完全替代关闭channel？

不能完全替代。cancel更适合用来快速终止那些不需要完整跑完的任务；关闭channel是用来标识输入完全结束，专门用来让worker把所有已经入队的任务全部处理完。两种逻辑可以同时存在，但是它们的设计目标完全不一样。

宽限时间到了队列还没跑完怎么办？

先把没处理完的任务总数、当前队列长度都记录下来。如果任务支持重试而且已经提前持久化了，直接退出之后下次启动再恢复处理就行；如果所有任务都只存在进程内存里，宽限时间到了之后还是有可能丢任务，这时候就得重新评估这个场景是不是真的需要接入持久化队列来保障可靠性了。

WaitGroup.Go能不能完全替代传统的Add和Done写法？

它能减少日常写代码时任务登记遗漏的常见问题，但是必须符合你的项目要求的最低Go版本，而且传入的任务函数不能出现panic。涉及到版本兼容，或者需要在worker内部写显式panic恢复逻辑的场景，传统的Add搭配Done的写法反而更灵活。