time.After 在 select 中未接收会导致 goroutine 泄漏；其内部启动的 goroutine 因 channel 无人接收而永不退出，典型错误是 select 分支未走到或 channel 被丢弃。
time.After 在 select 中可能造成 goroutine 泄漏
time.After 内部会启动一个独立的 goroutine 来发送超时信号到返回的 chan time.Time。如果这个 channel 没有被接收（比如 select 分支没走到、或 channel 被丢弃），goroutine 就不会退出，导致泄漏。
典型错误写法：
func badExample() {
select {
case <-doSomething():
case <-time.After(5 * time.Second):
// 超时逻辑
}
// 如果 doSomething() 很快返回，time.After 的 goroutine 仍在运行
}正确做法是：用 time.NewTimer 替代，并在不需要时显式 Stop()：
- 只在确定要等待时才创建 timer
- 一旦
select退出且未从 timer.C 读取，立即调用timer.Stop() - 如果已从
timer.C读取，Stop()返回false，安全忽略
time.After 不可重用，也不支持重置
time.After 每次调用都新建一个不可重用的 channel；它没有状态、不能 Reset、也不能 Stop。这和 time.Timer 有本质区别。
立即学习“go语言免费学习笔记（深入）”；
常见误用场景：
- 循环中反复调用
time.After实现“每隔 N 秒执行” → 应改用time.Ticker - 想对同一个超时逻辑多次复用 “一个
time.After” → 不可能，每次都要新调用 - 试图用
close()或其他方式“取消”time.After返回的 channel → 无效且 panic
例如，以下代码逻辑错误：
timeout := time.After(10 * time.Second)
for i := 0; i < 5; i++ {
select {
case <-workChan:
case <-timeout: // 第二次循环时 timeout 已关闭，永远阻塞或 panic
}
}time.After 的精度受系统定时器和 GOMAXPROCS 影响
time.After 的底层依赖 runtime.timer，其唤醒精度不是绝对精确。在高负载或 GOMAXPROCS 设置过低的场景下，实际触发时间可能明显延迟。
影响因素包括：
- Go runtime 的 timer heap 调度开销（尤其大量 timer 同时存在时）
- 当前 P（processor）是否正忙于执行其他 goroutine，导致 timer 到期后无法及时被调度
- Linux 上
CLOCK_MONOTONIC的底层实现，一般误差在毫秒级，但极端情况可达数十毫秒
若业务要求严格亚毫秒级响应（如高频交易），不应依赖 time.After 做关键路径控制，而应结合 runtime.nanotime() + 自旋或外部事件驱动。
与 context.WithTimeout 混用时容易重复超时控制
当函数同时接受 context.Context 并内部又调用 time.After，很可能造成两套超时逻辑叠加，行为难以预测。
例如：
func riskyFunc(ctx context.Context) {
select {
case <-ctx.Done():
return
case <-time.After(3 * time.Second): // 即使 ctx 还没超时，这里也会触发
// 执行兜底逻辑
}
}问题在于：ctx 和 time.After 是两个独立的超时源。更合理的方式是统一使用 context：
- 用
context.WithTimeout(ctx, 3*time.Second)替代time.After - 把所有 channel 等待统一收口到
ctx.Done()或派生 context 的Done() - 避免在已有 context 控制流里再引入另一套基于
time.After的超时
真正需要“固定延迟”而非“相对上下文超时”的场景才考虑 time.After，否则优先走 context。
最常被忽略的一点：很多人以为 time.After 是轻量级函数调用，其实它背后藏着一个必须被消费掉的 goroutine —— 只要 channel 没被接收，那个 goroutine 就永远活着。别把它当成 sleep 的语法糖用。
