time.after 只是发送信号而非终止协程，它返回的通道在超时后仅写入一个时间值，不会中断 goroutine 或使函数自动返回。
time.After 只是发信号，不是杀协程
time.After 返回一个 chan time.Time，它只在指定时间后往通道里塞一个当前时间值——仅此而已。它不会中断任何正在运行的 goroutine，也不会让调用它的函数“自动返回”。很多人以为写了 select { case 就等于“1 秒后强制停掉任务”，结果发现后台 goroutine 还在疯狂跑、内存没释放、日志还在打，这就是典型误解。
- 超时只是“不再等结果”，不是“终止执行”
- 若任务本身不检查上下文（比如没传
ctx、没调ctx.Done()），它会一直跑到结束 - 真正要取消任务，得靠
context.WithTimeout配合主动轮询ctx.Done()
别在循环里反复调 time.After
写成 for range tasks { select { case 是高频错误。每次迭代都新建一个 timer，等于每次重置 1 秒倒计时——哪怕某个任务已经跑了 5 秒，只要它恰好卡在某次 select 的“窗口期”内完成，就不会触发超时。
-
time.After每次调用都会启动新 goroutine 和新 timer，有开销 - 正确做法：把
timeout := time.After(1*time.Second)提到循环外，复用同一个通道 - 这样超时起点固定，整个循环共享同一截止时刻
什么时候该换 context.WithTimeout
当你需要：任务中途可被外部取消、超时能向下游传播（比如 HTTP 请求 → 数据库查询 → 第三方 API）、或任务内部有多个阻塞点（sleep / channel receive / http.Do），就别硬扛 time.After 了。
-
context.WithTimeout返回的ctx能被http.Client、database/sql、time.Sleep等原生支持 - 必须显式把
ctx传进去，并在关键位置加select { case 或 <code>if err := ctx.Err(); err != nil { return err } - 记得
defer cancel()，否则可能泄漏 timer 和 goroutine
time.After 的替代选择：什么场景用哪个
简单等待信号？time.After 足够轻量。但想控制生命周期、支持取消、或者高频调用（比如每毫秒 tick 一次），就得换别的。
- 要复用定时器 → 用
time.NewTimer+t.Stop()，比反复 newtime.After更省资源 - 要周期性触发 → 用
time.Ticker，别用time.After拼循环 - 要延时执行函数且可取消 → 用
time.AfterFunc，但它和 goroutine 无绑定，cancel 后函数仍可能执行 - 要完整超时+取消语义 → 坚定用
context.WithTimeout，这是 Go 官方推荐路径
最常被忽略的一点：超时控制不是加个 time.After 就完事；它是个协作机制——上游设限，下游配合检查，中间链路全部透传 ctx。漏掉任意一环，超时就只剩“假装有效”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
