不会。time.AfterFunc在内部启动独立goroutine执行回调，调用后立即返回，主线程继续运行；但若主goroutine提前退出（如main函数结束），程序终止导致回调无法执行，需用select{}、time.Sleep或sync.WaitGroup保持主goroutine存活。
time.AfterFunc 会阻塞主线程吗？
不会。它在内部启动一个 goroutine 执行回调，调用后立即返回，主线程继续运行。
常见误解是把它当同步延时用，结果发现回调没执行——其实是因为主 goroutine 提前退出了（比如 main 函数结束），导致整个程序退出，后台 goroutine 来不及运行。
- 必须确保程序生命周期覆盖回调执行时间，例如在
main中加select{}或time.Sleep - 回调函数内 panic 不会崩溃主程序，但错误会被静默丢弃（可加
recover捕获） - 返回值是
*Timer，不是布尔或错误，无法判断是否成功注册
如何取消还没触发的 time.AfterFunc？
time.AfterFunc 本身不提供取消方法，但它返回的 *Timer 支持 Stop()。
关键点：调用 Stop() 仅在定时器未触发时有效；若已触发或正在执行回调，Stop() 返回 false，且回调仍会完成。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 务必保存返回的
*Timer，否则无法取消 -
Stop()不关闭通道，也不影响已发送到通道的值（这里不涉及通道） - 多次调用
Stop()安全，但无额外效果
t := time.AfterFunc(5*time.Second, func() { fmt.Println("done") })
// …… 条件满足时取消
if !t.Stop() {
fmt.Println("timer already fired or stopped")
}
和 time.NewTimer + select 配合使用有什么区别？
time.AfterFunc 是纯“触发即执行”模式，适合简单副作用（如打日志、发通知）；而 time.NewTimer + select 更适合需要等待、与其他 channel 协作或需响应中断的场景。
性能上差异极小，但语义和控制粒度不同：
-
AfterFunc回调不可中断，也不能等待其完成 -
NewTimer.C可参与select，支持超时、取消、多路复用 - 如果需要在回调执行后做后续操作（比如等回调结束再继续），
AfterFunc无法满足，得改用goroutine + channel封装
定时任务重复执行时别直接套用 AfterFunc
time.AfterFunc 只执行一次。想实现周期性任务（如每 10 秒拉一次配置），不能靠循环调用它来模拟 —— 这会导致 goroutine 泄漏（每次调用都新建 goroutine，旧的不会自动回收）。
正确做法是用 time.Ticker，或手动在回调里重新调度（需谨慎处理停止逻辑）：
- 用
time.Ticker最安全：创建一次，Stop()明确释放资源 - 若坚持用
AfterFunc实现重复，必须在回调里检查是否应继续，并重新调用AfterFunc，同时保存并管理所有活跃的*Timer - 忘记
Stop()已废弃的 timer，会导致内存泄漏和意外回调
真正容易被忽略的是：哪怕只跑一次的定时任务，只要程序长期运行，也要考虑是否可能被多次创建却未清理 —— *Timer 不是无成本的资源。
