time.afterfunc不能当重复定时器用，因其仅触发一次且无自动重试机制；循环调用会导致间隔漂移、goroutine堆积、panic丢失及无法取消等问题。
time.AfterFunc 为什么不能当“重复定时器”用
time.AfterFunc 只触发一次，它本质是 time.After + go f() 的快捷封装，不是 time.Ticker。如果你写成循环调用 time.AfterFunc 来模拟周期任务，容易因函数执行时间波动导致间隔漂移，甚至堆积 goroutine。
- 执行耗时 200ms，但你想每 500ms 执行一次 → 实际间隔变成 500ms + 200ms = 700ms，越滚越慢
- 函数 panic 或提前 return → 后续调用直接丢失，无任何错误反馈
- 没地方存
*time.Timer指针 → 想取消都找不到对象
如何安全地用 time.AfterFunc 做单次延迟任务
适合“发个通知”“清理临时文件”“超时回退”这类明确只跑一次的场景。关键是要拿到返回的 *time.Timer，方便后续控制。
timer := time.AfterFunc(3*time.Second, func() {
log.Println("3秒后执行，仅一次")
})
// 需要时可取消
timer.Stop()
// 注意：Stop 返回 true 表示还没触发，false 表示已执行或正在执行中
- 不要忽略
timer.Stop()的返回值 —— 如果返回false，说明函数可能正在运行，此时强行取消无效 - 函数体内避免阻塞操作，否则会拖慢整个 timer 系统（
time.AfterFunc共享 runtime 的 timer goroutine） - 如果任务需重试逻辑，得自己在外层加判断和重新调度，不能靠
AfterFunc自动重试
time.AfterFunc 和 time.NewTimer 选哪个
功能几乎等价，但 time.AfterFunc 少一个 timer.C 通道，没法 select 等待；而 time.NewTimer 更灵活，尤其适合需要和其它 channel 一起 select 的场景。
- 只关心“到点执行”，且不需中断/重置 → 用
time.AfterFunc更简洁 - 需要在多个 channel 中等待（比如同时等超时 + 网络响应）→ 必须用
time.NewTimer，然后select { case - 想复用同一个 timer（比如重置超时时间）→
timer.Reset(d)只对*time.Timer有效，AfterFunc没这能力
常见 panic：调用 Stop 后再访问 timer.C
一旦调用 timer.Stop()，timer.C 就不再发送值，但更危险的是：如果 timer 已触发，timer.C 会被关闭，此时再读会 panic：panic: send on closed channel。
- 永远不要在
AfterFunc回调里去Stop自己的 timer —— 它已经过期了，Stop 返回 false，且 C 已关闭 - 如果要用
timer.C，务必先确认 timer 是否还活跃，或改用select+default非阻塞读 -
AfterFunc不暴露C，所以这个坑只出现在你手动用NewTimer时 —— 但很多人混淆两者，误以为AfterFunc也能这么玩
time.AfterFunc 看似简单，但一旦脱离“纯延迟+单次”的边界，就很容易掉进 timer 生命周期管理的细节坑里。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
