直接用 select 配合 time.after 就能实现超时退出，但必须把 channel 操作放在 case 中，否则无法达到超时控制效果。
直接用 select 配合 time.After 就能实现超时退出，但必须把 写进 <code>select 的 case 里，不能提前判断、不能复用返回的通道、也不能在超时后忽略未消费的发送。
为什么 select 本身不支持超时，得靠 time.After
select 是纯通道协调机制，没有内置时间语义。它只等通道就绪，不关心“等了多久”。time.After(d) 返回一个 ，这个通道会在 <code>d 后自动发送一次当前时间，然后关闭——本质上就是个“倒计时信号源”。把它和业务 channel 一起扔进 select，就自然形成了“等结果 or 等超时”的二选一逻辑。
- 错误写法：
if time.Now().After(deadline) { ... }—— 完全绕过 channel 语义，无法和 goroutine 协作 - 错误写法：
timeoutCh := time.After(d); select { case —— <code>timeoutCh只能被消费一次，第二次select就永远阻塞 - 正确姿势：每次需要超时控制，都写
case （简单场景）或复用一个 <code>time.Timer.C（高频/需手动控制）
time.After 和 time.NewTimer 怎么选
time.After 是语法糖，底层调用 time.NewTimer 并返回其 C 字段；区别在于生命周期管理。
-
time.After(2 * time.Second)：适合单次、轻量、无需干预的等待，比如等一个异步结果最多 2 秒 -
timer := time.NewTimer(2 * time.Second); defer timer.Stop()：适合需要提前取消的场景，比如收到结果后立刻停掉定时器，避免后续误触发 - 高频循环中别裸写
time.After：每调用一次就启一个 goroutine，容易积压 timer 对象，改用复用的timer.Reset() -
timer.Stop()必须紧跟defer，否则泄漏；Stop 成功后不能再读timer.C，否则可能 panic
超时分支里最容易漏掉的三件事
超时不是终点，而是清理起点。只打印 “timeout” 很可能埋下 goroutine 泄漏或 channel 阻塞的坑。
- 业务 channel 如果是无缓冲的，而发送方还在往里写，就会永久阻塞：解决办法是用带缓冲的 channel（如
make(chan string, 1)），或让发送方检查ctx.Done() - 超时后，后台 goroutine 还在跑，结果最终写入 channel 却没人收：应配合
context.Context让工作函数可中断，或显式关 channel - 超时分支里做了阻塞操作（比如再起一个
http.Get或锁竞争）：会卡住整个select，其他 case 永远得不到响应，只做日志、关资源、发信号这类轻量动作
什么时候该换 context.WithTimeout
当你需要超时信号能向下传递、被下游函数识别并响应时，context.WithTimeout 是更可靠的选择。
-
http.Client.Do、database/sql.QueryContext等标准库函数原生支持context.Context，传进去就能真正中断底层连接或查询 -
time.After只控制“等不等得到”，不控制“能不能停掉正在做的事”；context提供的是可传播的取消能力 - 必须
defer cancel()，否则 context 泄漏；且要确保所有子 goroutine 都接收并检查ctx.Done()，否则超时只是假象 - 不要自己
select { case 来模拟超时逻辑——这又退回到手写 <code>time.After，失去 context 的传播优势
最常被忽略的一点：超时控制的边界在哪。你用 time.After 控制了等待侧，但那个正在跑的 go func() { ch 本身不会因为超时就停下——它是否结束，取决于它自己有没有检查退出信号、有没有用对 channel 缓冲、有没有被上层 context 带着走。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
