根本原因是主goroutine提前退出导致程序终止，time.afterfunc启动的goroutine未被等待；需用select{}、time.sleep或sync.waitgroup保持主goroutine存活，且可通过返回的*timer调用stop()在触发前取消。
time.AfterFunc 为什么回调没执行？
根本原因通常是回调函数执行完后，主 goroutine 已经退出，整个程序提前终止了。time.AfterFunc 启动的是一个新 goroutine，但 Go 程序不会等待未显式管理的 goroutine 结束。你看到“没回调”，其实是程序早于回调触发就退出了。
- 常见错误写法：
time.AfterFunc(2*time.Second, func() { fmt.Println("done") })—— 没有阻塞主 goroutine，程序立刻结束 - 正确做法：用
select{}、time.Sleep或sync.WaitGroup保持主 goroutine 存活，直到预期回调完成 - 注意：
time.AfterFunc返回一个*Timer，它只触发一次，不能重复使用；若需周期性执行，请改用time.Ticker
如何取消或提前停止 time.AfterFunc 回调？
time.AfterFunc 返回的 *Timer 支持取消，但必须在回调触发前调用 Stop()，否则返回 false 且无效。
- 调用
t := time.AfterFunc(...)后，可随时执行t.Stop()尝试取消 -
Stop()返回bool：true 表示成功取消（回调尚未执行），false 表示已触发或正在执行中 - 取消后，该
*Timer不再有效，也不能再Reset()（它不是time.NewTimer()） - 如果需要“可重置 + 可取消”的延时逻辑，直接用
time.NewTimer()+select更可控
time.AfterFunc 和 time.NewTimer 选哪个？
二者底层都基于同一个定时器机制，但语义和控制粒度不同：time.AfterFunc 是一次性“发个任务”，time.NewTimer 是“拿个句柄自己管”。
- 简单场景（如延迟打印日志、触发一次清理）：用
time.AfterFunc更简洁 - 需要判断是否已触发、想主动关闭、或后续可能重设时间：必须用
time.NewTimer，因为AfterFunc不暴露通道，无法select监听 - 性能无差异，但
AfterFunc少一次timer.C的 channel receive 操作，代码更短 - 注意：
time.AfterFunc的回调函数 panic 不会影响主流程，但也不会被外层 recover —— 错误静默丢失，建议内部加recover
回调函数里访问外部变量要注意什么？
闭包捕获变量时，容易因变量生命周期或并发修改导致非预期行为，尤其是循环中创建多个 AfterFunc。
- 典型陷阱：
for i := 0; i —— 输出全是 <code>3，因为所有回调共享同一个i变量 - 修复方式：在循环内用局部变量绑定，例如
for i := 0; i - 若回调需修改外部状态（如更新 map），确保该操作是并发安全的 ——
map非并发安全，应加锁或改用sync.Map - 不要在回调里启动耗时同步操作（如 HTTP 请求未设 timeout），可能阻塞定时器 goroutine（虽不影响其他定时器，但影响该回调自身响应）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
