直接用select配合time.after可实现超时退出，但必须将channel操作置于case中，不可提前判断、不可复用通道、不可忽略超时后未消费的发送；否则会导致goroutine卡死或泄漏。
直接用 select + time.After 能实现超时，但写错一行就卡死、泄漏、逻辑错乱——这不是语法问题，是通道语义和资源生命周期没对齐。
为什么time.After放进select里会卡住goroutine
典型错误是把业务发送和超时混在同一个 select 里，却不处理“超时后业务通道还堵着”的情况：
ch := make(chan int)
select {
case ch <p>一旦走超时分支，<code>ch 就彻底卡住。因为 <code>ch</code> 是无缓冲的，又没人在另一端收，这个 goroutine 就再也动不了了。</code></p>
- 根本原因：超时只是“放弃等待”，不是“取消发送”
- 解决方向：要么让发送不阻塞（加缓冲或用
select带default尝试），要么把发送逻辑挪到 goroutine 里，主流程只管等结果 - 更稳妥的做法是封装成函数，用 goroutine 启动，主流程只监听结果或超时通道
time.NewTimer比time.After更可控的三个理由
time.After 看似简洁，但它是“一次性定时器 + 单次通道”，没法重置、没法停止、没法复用。真实场景中，你大概率需要这些能力：
-
time.After每调用一次就新建一个timer对象，如果在循环里高频调用（比如每秒几十次），会导致定时器堆积，GC 不及时就内存泄漏 -
time.NewTimer创建后可以显式Stop()，避免资源滞留；还能Reset()重用，适合重试逻辑 - 超时后你想立刻中断正在跑的操作？
time.NewTimer配合context.Context才能真正协同，单靠time.After只能控制“等多久”，不能影响“正在做什么”
正确姿势：
timer := time.NewTimer(3 * time.Second)
defer timer.Stop() // 必须 defer，否则每次调用都泄漏一个 timer
<p>select {
case result := </p><h3>
<code>default</code>不是超时，别把它当<code>time.After</code>用</h3><p>有人写成这样：</p><pre class="brush:php;toolbar:false;">select {
case msg := <p><code>default</code> 的含义是“所有 case 都不可执行时立即走这里”，它不启动任何计时器，也不等待——相当于轮询试探，不是超时控制。</p>
- 误用
default当超时，在高并发下可能瞬间触发大量空转，CPU 拉满 -
default适合做快速探测：比如检查 channel 是否有数据可读，但不希望阻塞 - 真要超时，必须依赖一个能随时间推移自动就绪的通道，比如
time.After或timer.C
什么时候该用context.WithTimeout而不是手写select
context.WithTimeout 不是银弹，但它解决了手写 select 容易漏掉的关键点：生命周期统一管理。
- 它把“超时时间”“取消信号”“传播能力”打包进一个
ctx，下游支持 context 的函数（如http.Client.Do、sql.DB.QueryContext）能自动响应 - 手动写
select很容易忘记defer timer.Stop()，或提前 return 时漏掉cancel()，导致 goroutine 和 timer 泄漏 - 但 context 不能替代所有
select场景：比如你要等两个自定义 channel + 一个超时，且其中某个 channel 的发送方你完全无法修改，那只能自己用select控制等待边界
典型安全写法：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>select {
case result := </p><p>最常被忽略的一点：超时分支里不能做任何阻塞操作。哪怕只是想记个日志，如果 <code>log.Println</code> 底层用了锁或网络输出，也可能卡住整个 <code>select</code>，导致其他通道永远得不到响应。</p>golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
