Go定时任务的结果回调需用channel+goroutine显式收发，而非函数传参；time.AfterFunc不支持结果返回、错误传播、上下文控制与复用goroutine；应采用Ticker+带缓冲channel+worker模式实现可控调度。
Go 里定时任务的“结果回调”不是靠函数传参实现的，而是靠 channel + goroutine 显式收发结构化结果；直接往定时器里塞回调函数，基本等于放弃错误传播、超时控制和上下文管理。
time.AfterFunc 不适合带结果的回调
time.AfterFunc 只能执行无返回值的 func()，它不提供任何机制来获取执行结果或错误。一旦里面 panic，日志里只有一行 goroutine 退出，没堆栈、没上下文、没法重试。
- 它没有返回 channel，你无法用
select等待结果 - 它不接收
context.Context，无法响应取消或超时 - 它不能复用已有 goroutine 池，每次都是新 goroutine，易失控
用 time.Ticker + channel 封装带结果的定时任务
真正可控的做法是：启动一个长期运行的 goroutine 监听 ticker.C，每次触发时构造任务结构体、发到带缓冲的 channel，再由另一组 worker 处理并回传结果。
示例关键点：
立即学习“go语言免费学习笔记（深入）”；
- 定义结果结构：
type TaskResult { Data string; Err error; Timestamp time.Time } - channel 必须带缓冲：
results := make(chan TaskResult, 16)，否则 worker 阻塞会拖垮 ticker - ticker goroutine 中不直接执行业务逻辑，只做“投递”：
results - 主流程用
select接收结果，配合ctx.Done()防止死等
HTTP handler 中定时触发异步回调？别这么干
有人想在接口里调用 time.AfterFunc(5 * time.Second, callback) 来“延迟通知”，这非常危险——callback 执行时，http.Request 的 r.Body 早已关闭，context.WithTimeout(r.Context(), ...) 也已过期，且该 goroutine 在进程重启时必然丢失。
- 正确路径只有两条：要么用 Redis Stream 做持久化延迟队列（如
XADD ... DELAY 5000），要么用外部调度器（如 cron + HTTP 调用） - 如果真要“定时查状态后回调”，必须把查询动作写入 DB/Redis，并由独立的后台 worker 定期扫描执行
- 所有回调目标（如 webhook URL）必须提前存好，不能依赖请求上下文临时拼接
channel 回传结果时最常漏掉的三件事
用 channel 实现结果回调，90% 的坑都出在收发两端不同步：
- 发送端忘了
close(ch)，接收方range ch永远等不到结束 - 接收端没用
select包一层，导致阻塞在<-ch上，整个 goroutine 卡死 - channel 缓冲设为 0 且发送频率高，第一个没被及时读走，后续所有发送都永久阻塞（goroutine 泄漏）
真正稳定的做法是：每个任务配独立带缓冲 channel（如 make(chan TaskResult, 1)），发送后立刻 close(ch)，接收方用 select { case r := <-ch: ... case <-time.After(30*time.Second): ... } 控制等待边界。
