Go语言延迟执行函数，用time.AfterFunc还是带Sleep的goroutine更好？

结论 #

绝大多数场景优先选time.AfterFunc，仅在极少量特定场景可以用goroutine搭配time.Sleep的实现。

两者核心差异对比 #

• 资源消耗差距明显
  单个goroutine虽然轻量，但如果需要创建大量延迟任务，每个sleep的goroutine都要占用独立栈内存（初始2KB，可动态扩容）和调度开销。而time.AfterFunc复用Go runtime内部的全局计时器堆，所有定时任务统一由sysmon线程管理，不会为每个延迟任务单独创建goroutine，高并发场景下资源占用低一个数量级。
  比如同时创建10万个延迟1分钟的任务，sleep方案需要创建10万个goroutine，内存直接上涨几十MB，而time.AfterFunc仅需要存储计时器节点的少量内存，开销差距极大。

• 取消成本天差地别
  time.AfterFunc调用后会返回*time.Timer实例，任务未触发前只要调用Stop()方法返回true，待执行函数就永远不会运行，取消逻辑一行代码就能搞定。而goroutine加sleep的方案要实现取消，必须自己额外封装context.Context或者信号通道，写起来繁琐还容易出问题导致goroutine泄漏。
  取消示例：

  timer := time.AfterFunc(3*time.Second, func() {
    // 执行延迟逻辑
  })
  // 不需要执行时直接取消
  timer.Stop()
  

• 执行精度有差距
  独立的sleep goroutine遇到runtime调度繁忙时，即便sleep到点，也可能需要排队等待调度，延迟误差更大。而runtime计时器堆的任务触发优先级更高，到点后执行的误差更小。

什么时候可以用goroutine+sleep的方案 #

只有同时满足以下所有条件的时候可以选sleep方案：

1. 延迟任务数量极少，不会出现批量创建的情况
2. 不需要中途取消任务
3. 延迟逻辑本身有大量阻塞操作，不需要和其他定时任务共享执行上下文

另外要注意一个坑：time.AfterFunc默认是在计时器的调度goroutine里同步执行函数的，如果你的逻辑有阻塞操作，会拖慢其他计时器任务的执行，这种情况可以在time.AfterFunc的回调里再开goroutine跑业务逻辑，比直接开goroutine等sleep的方案还是更划算。

补充提醒：很多人写sleep方案的时候容易忘记加退出逻辑，短生命周期的服务里批量创建这种任务很容易导致goroutine泄漏，内存持续上涨排查起来很麻烦。

内容的提问来源于stack exchange，提问作者help_seeker