time.afterfunc 不会阻塞主线程，它启动独立 goroutine 执行回调后立即返回；但若 main 未等待可能提前退出，且不支持取消和 select，传参需用闭包并注意变量捕获安全。
time.AfterFunc 会阻塞主线程吗
不会。它在内部启动一个独立的 goroutine 来执行回调函数，调用后立即返回，主线程继续运行。
常见误解是把它和 time.Sleep 混淆——后者才真正暂停当前 goroutine。而 time.AfterFunc 更像“设个闹钟然后转身就走”。
- 如果你在
main()函数里调用它但没做任何等待（比如没加select{}或time.Sleep），程序可能直接退出，导致回调根本没机会执行 - 它不返回 timer 对象，无法手动停止；如果需要取消，请改用
time.NewTimer+Stop() - 回调函数里发生 panic 不会影响其他 goroutine，但也不会被自动捕获，建议自行 recover
延迟执行时如何传参给回调函数
time.AfterFunc 的第二个参数只接受 func() 类型，不能直接传参。必须用闭包捕获外部变量。
注意变量生命周期：如果在循环中反复调用，别直接闭包引用循环变量（如 for i := range xs 中的 i），否则所有回调可能看到同一个最终值。
- 安全写法是声明局部变量并赋值：
for _, v := range data { val := v; time.AfterFunc(d, func() { fmt.Println(val) }) } - 避免在回调里修改仍在使用的外部变量，尤其涉及 map、slice 等引用类型时，可能引发竞态
- 如果参数较大或需深拷贝，应在闭包内完成复制，而非依赖外部作用域的原始值
time.AfterFunc 和 time.NewTimer().C 配合 select 使用的区别
当你需要「延迟执行」+「同时监听其他 channel」时，time.AfterFunc 就不够用了——它不提供 channel 接口，无法参与 select。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
此时应改用 time.NewTimer 或更轻量的 time.After：
-
time.After(d)返回，适合一次性延迟通知，不可重用 -
time.NewTimer(d)返回可Stop()、可Reset()的 timer，适合动态调整延迟场景 -
time.AfterFunc更适合“只管扔出去，不管后续”的简单定时任务，比如日志上报、资源清理等
示例：想延迟 2 秒执行，但中途收到 cancel 信号就放弃 —— 必须用 select + time.After，AfterFunc 做不到。
为什么有时回调没执行？几个关键排查点
最常被忽略的是程序生命周期短于延迟时间，尤其是测试代码或 CLI 工具中。
- 检查是否在
main()结束前没留出足够时间，比如忘了time.Sleep(3 * time.Second)或sync.WaitGroup - 确认没有在回调中 panic 且未 recover，导致 goroutine 静默退出（可通过
recover()+ 日志验证） - Go 1.21+ 中，如果程序以
os.Exit强制终止，正在运行的AfterFuncgoroutine 会被立即杀死，不会等回调结束 - 不要在
init()或包加载阶段调用AfterFunc，此时 runtime 可能尚未准备好调度器
延迟执行不是“保证一定运行”，而是“尽最大努力在时间点之后调度”，它的可靠性高度依赖你对程序生命周期的控制。
