time.After 返回的 channel 必须用 select + case 安全读取，因其为单次触发通道，仅发送一次值，直接多次读取会导致永久阻塞。
time.After 返回的 channel 怎么安全读取
直接从 time.After 返回的 chan time.Time 里读取，必须配合 select 或明确知道只读一次，否则会永久阻塞。它本质是单次触发的通道，底层只发送一次值，读完就空了，再读就会卡住。
- 正确姿势是用
select+case ，适用于超时控制或单次延后执行 - 如果写成
val := 单独一行，在 goroutine 中没问题；但放在主流程里且后续还有逻辑，容易让程序停在这儿不动 -
time.After不可重用——每次调用都新建一个 channel，别试图缓存它反复读
需要重复定时执行，为什么不能只靠 time.After
time.After 只发一次，想每 5 秒打印日志，写成循环里反复调用 time.After(5 * time.Second) 看似可行，但会产生大量泄漏的 timer 和 channel，Go runtime 不会自动回收已过期但未被读取的 time.After 实例。
- 真正该用的是
time.Ticker：它内部复用 timer，ticker.C是持续发送时间点的 channel - 必须记得在不用时调用
ticker.Stop()，否则 goroutine 和 timer 会一直活着，引发内存泄漏 - 若只是“延迟一次后做某事”，用
time.After没问题；但“每隔多久做一次”，time.After就是错的选择
select 中混用 time.After 和其他 channel 容易漏掉超时判断
常见错误是在 select 里把 time.After 放在 default 分支后面，或者没处理好非阻塞读场景，导致超时逻辑根本不会触发。
- 超时分支必须显式写成
case ，不能塞进变量再引用（比如 <code>timeoutCh := time.After(...)再case ），否则每次 select 都新建一个 timer - 如果其他 channel 可能立即就绪（比如带缓冲的 channel 或刚写入过），
select会优先选它，time.After就永远等不到执行机会 - 调试时可加日志验证：在 timeout case 里打日志，运行看是否真走到——很多“超时不生效”其实是逻辑被其他 case 吃掉了
time.After 在测试中怎么避免阻塞等待
单元测试里直接用 time.After(2 * time.Second) 会让测试跑得极慢，而且不可靠——CI 环境负载高时可能超时失败。
立即学习“go语言免费学习笔记（深入）”；
- 推荐把定时逻辑抽成函数参数，传入
func() ，测试时传 <code>func() 或用 <code>make(chan time.Time, 1)手动触发 - 不要用
time.Sleep去“等 timer 触发”，这既慢又难控制精度；真正的解耦是让时间源可替换 - 标准库
testing.T提供testutil类工具不多，但time.Now和time.After都属于需要 mock 的边界依赖——哪怕只是用闭包包装，也比硬编码强
实际写业务时，最常踩的坑不是语法错，而是把 time.After 当成 setTimeout 用，却忘了它背后是 channel + timer 的组合，而 Go 的 channel 语义和 JS 的回调完全不同。timer 是否停止、channel 是否被消费、goroutine 是否泄漏，这些细节在压测或长期运行后才会暴露。
