Go Ants 怎样为任务 panic 设置处理函数

Ants v2 可以在创建池时传入 ants.WithPanicHandler(func(value any) { ... })，统一接收池内任务触发的 panic 值。处理函数通常记录日志、堆栈或异常事件；它不会把任务变成成功，也不会让 Submit 同步返回任务内部的 panic。

官方地址：https://github.com/panjf2000/ants

适用场景是多个后台任务共用一个协程池，需要一致的异常记录方式。下面采用“任务自行清理，池级回调兜底”的方案，并把等待任务结束与等待异常回调分开。示例为原创讲解代码，不展示实测输出。

先确定异常处理应该放在哪一层

对批处理或后台作业来说，先问两个问题：是否需要任务编号，是否需要把失败结果交回调用方。池级回调只拿到 panic 值，不会自动增加业务上下文；如果失败必须精确关联订单、文件或作业，就需要任务包装层记录标识，或让受控的 panic 值带上任务信息。

如果只是需要统一日志，池级回调足够直接；若需要可靠的失败交付，推荐额外设计带任务标识的结果协议。不要为了走回调而把正常业务错误都改写成 panic。

创建协程池时传入 WithPanicHandler

NewPool 接收可选配置，WithPanicHandler 将自定义函数保存为池的 PanicHandler。下面涉及的 任务函数、goWorker、PanicHandler、WithPanicHandler、NewPool 和 日志记录器，分别属于任务执行、池配置和异常记录三个职责。

具体接口见 Ants API 文档。本文围绕常规 Pool.Submit(func()) 讲解，不把其他类型池或不同版本的内部实现一概而论。

为任务结束和异常通知分别等待

下面的程序提交两个任务：一个用字符串触发演示性 panic，一个正常记录日志。WaitGroup 只负责任务函数退出，容量为一的通知通道负责确认这个示例中的一次异常回调已完成记录。项目需先在 go.mod 中声明 Ants v2，并固定选择的依赖版本。

package main

import (
    "fmt"
    "log"
    "runtime/debug"
    "sync"
    "time"

    "github.com/panjf2000/ants/v2"
)

func run() error {
    var tasks sync.WaitGroup
    // 本例只有一个预期 panic；通知不携带业务结果。
    panicRecorded := make(chan struct{}, 1)

    pool, err := ants.NewPool(2, ants.WithPanicHandler(func(value any) {
        // 在回调所在的 goroutine 中采集堆栈，避免异步采集丢失现场。
        log.Printf("池任务异常: type=%T value=%v\n%s",
            value, value, debug.Stack())
        // 不阻塞 worker；生产中应为丢弃事件设计独立指标。
        select {
        case panicRecorded 

这里 run 返回 nil 只表示演示的两个等待条件满足，不能解释为发生 panic 的任务业务成功。示例中的三秒是等待通知的时间上限，不是对正在运行任务的取消机制。项目若要用退出码表达失败，可在 run 返回、资源释放后由 main 决定进程退出方式。

任务 panic 展开堆栈时，任务自己的 defer tasks.Done() 会先执行，之后才到外层 worker 的恢复逻辑。因此 WaitGroup、tasks.Done、PanicHandler、panicRecorded、tasks.Wait、等待通知 需要分清职责：计数属于任务，通道属于异常通知，等待方分别依赖二者。

保留堆栈，同时控制回调开销

在官方 v2.12.1 的普通 worker 实现中，未设置自定义回调时会通过 Logger 输出 panic 和堆栈；设置后则调用自定义 PanicHandler。因此需要堆栈就应在自定义函数里明确记录，不能假设默认日志还会额外替你输出。参见 对应版本 worker.go。

debug.Stack() 返回当前 goroutine 的堆栈。若要异步上报，应在当前回调里取得堆栈字节和必要字段，再交给有界队列；在另一个 goroutine 中调用 Stack 会得到另一个现场。该行为见 标准库说明。

多个 worker 可能同时异常，回调访问的计数器、映射和输出目标都应支持并发。不要在回调中无上限重试远程 HTTP 请求，也不要等待只能由同一受限池完成的工作，否则异常记录本身可能成为阻塞点。上面 log.Printf 是便于阅读的同步示例，真实日志目标如果可能长期阻塞，应改用有界、可观测的输出安排。

回调自身也不能随意 panic。所引用 worker 实现没有在自定义回调外再套一层独立恢复；如果日志格式化、用户实现的 String 方法或上报代码再次触发 panic，就可能把异常传播出去。对于不可信的 panic 值，生产记录器要避免调用不受控格式化方法，并明确其自身的兜底策略。

把提交失败和业务失败分开处理

Submit 返回错误，表示提交没有按要求被接受；成功返回，只能说明提交这一层成功。任务实际执行是否完成、是否报错、是否 panic，需要业务自己的结果通道或记录。不要把 Submit 返回 nil 当作后台任务执行成功。

在上述版本中，worker 的外层 defer 恢复异常后该次 goroutine 会退出；这不意味着池永久不能接收后续任务，但更不意味着异常任务会从出错语句后继续。Ants 的处理函数没有自动重试语义。需要重试时，由业务系统判断幂等性、部分写入和补偿条件，再单独安排有限次数的重试。

任务里另开 goroutine，其 panic 也能接住吗？

不能依赖池级处理函数捕获子 goroutine 的 panic。恢复只对相应 goroutine 的堆栈展开生效。任务中新开的 goroutine 应在自己的入口安排异常和退出处理，或者避免把工作从池的任务生命周期中脱离。

为什么 Wait 已经返回，日志却还没记录完？

任务自己的 defer 可能先把计数减为零，池级回调仍在执行。要等待上报完成，就另设上报完成信号。上文通知只服务一个明确的演示异常；真实批量作业应按任务 ID 管理每个结果，不能用一个共享信号表示所有失败已处理。

必须在回调里调用 recover 吗？

回调参数已经是池的恢复逻辑获得的 panic 值，直接使用这个参数即可。先在创建池时配置兜底，再在任务里保证清理和结果交付，通常比在每个回调里重复猜测恢复位置更清楚。