time.AfterFunc 不会阻塞主线程，它异步执行回调并立即返回；需确保主 goroutine 持续运行以避免回调未执行；可通过返回的 *time.Timer 调用 Stop() 取消未触发任务。
time.AfterFunc 会阻塞主线程吗
不会。 time.AfterFunc 是异步执行的，它内部用 time.NewTimer 启动一个 goroutine 来调用回调函数，调用后立即返回，不影响当前 goroutine 的执行流。
常见错误是误以为它像 time.Sleep 那样同步等待——实际它只是“设个闹钟”，然后就继续往下跑。如果你在 main 函数里调用了 time.AfterFunc 就直接退出程序，回调很可能根本没机会执行（因为进程已结束）。
- 必须确保主 goroutine 持续运行，比如加
select{}或time.Sleep - 回调函数在独立 goroutine 中运行，不共享调用方的栈帧，注意闭包变量捕获是否安全
- 如果回调耗时较长，不会影响其他定时器，但会延迟下一个可能的调度（不过 Go 定时器本身不保证严格准时）
如何取消还没触发的 AfterFunc 任务
time.AfterFunc 返回的是 *time.Timer，可以直接调用其 Stop() 方法来取消未触发的任务。这是唯一可靠的方式；不能靠修改参数或全局状态“屏蔽”回调。
典型场景：用户操作触发延迟保存，但紧接着又做了新编辑，需要取消前一次延迟任务。
- 必须保存
time.AfterFunc的返回值，否则无法取消 -
Stop()返回bool：true 表示成功取消（任务尚未触发），false 表示已触发或已停止过 - 已触发的 timer 调用
Stop()无效，也不会 panic - 不需要手动调用
timer.Reset()或timer.Stop()后再复用——AfterFunc创建的 timer 是一次性使用的
和 time.After + select 比较，该选哪个
二者语义不同：time.AfterFunc 是“到点自动执行某个函数”，time.After 是“返回一个 channel，你得自己 select 或 等待”。选择取决于控制权在谁手里。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如果你只需要“延迟后做一件事”，且不关心中间是否被中断、不参与多路复用，AfterFunc 更简洁；如果延迟要和其他 channel（如网络读、信号）一起等待，或者需要响应取消信号，After + select 更合适。
-
time.AfterFunc(d, f)等价于启动一个 goroutine 执行time.Sleep(d); f()，但更轻量（复用 timer 机制） -
time.After(d)底层也用 timer，但每次调用都新建 channel，频繁使用有小开销 - 用
select可以配合case 实现上下文取消，<code>AfterFunc本身不接受 context - 不要在循环里反复调用
AfterFunc而不保存 timer 引用——会导致泄漏（timer 内部 goroutine 不会被回收）
回调函数里 panic 会影响主线程吗
会，但只影响那个执行回调的 goroutine，不会终止整个程序，除非你没 recover。Go 的 goroutine panic 是隔离的，但如果不处理，会打印堆栈并退出该 goroutine。
这容易被忽略：你可能以为延迟任务失败无关紧要，结果发现日志里一堆 “panic: xxx” 却没报警，甚至掩盖了真正的问题。
- 务必在回调函数内用
defer func() { if r := recover(); r != nil { log.Printf("afterfunc panic: %v", r) } }() - 不要依赖外部 defer —— 回调是新 goroutine，外层 defer 不生效
- 如果回调需重试逻辑，别在 panic 后直接再调
AfterFunc，容易无限创建 goroutine；应封装成带重试策略的独立函数 - 注意：recover 只能捕获当前 goroutine 的 panic，跨 goroutine 无效
实际写业务时，最常踩的坑不是语法，而是忘记 hold 住 main、忘记 stop 已废弃的 timer、以及让 panic 默默吞掉。这些地方一漏，延迟任务就变成“有时行有时不行”的玄学问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
