context.WithTimeout 是唯一推荐的超时起点，因 time.After 不传播取消信号、不释放 timer 资源，且无法透传至下游阻塞点；必须将 ctx 传到底层操作如 http.Request.WithContext、db.QueryContext 和 conn.SetReadDeadline。
context.WithTimeout 是唯一推荐的起点，不是“可选方案”，而是 Go 生态中所有标准库和主流框架（http.Client、database/sql、grpc）唯一真正支持的超时传递机制。裸用 time.After 或 select + 定时器，在绝大多数真实服务中等于埋雷。
为什么不能只用 time.After 包裹 goroutine？
它不传播取消信号，也不释放底层资源：
-
time.After(5 * time.Second)会创建一个不可回收的timer，即使select早已从另一个分支返回，这个 timer 仍会跑满 5 秒，持续占用 runtime 计时器资源 - goroutine 本身不会因
time.After触发而自动退出——你只是“收到了超时通知”，但业务逻辑可能还在往数据库写、还在读 socket、还在解析大 JSON - 没有上下文透传，下游调用（比如
db.QueryContext()）完全收不到超时指令，照样卡死
context.WithTimeout 必须传到底层阻塞点
只在入口创建 ctx，却不把它塞进实际耗时操作里，等于没设：
- HTTP 请求必须用
req = req.WithContext(ctx)再传给http.DefaultClient.Do(req)；光设http.Client.Timeout只能兜底，且无法 per-request 动态控制 - 数据库查询必须用
db.QueryContext(ctx, sql)，而非db.Query(sql) - 自定义 I/O 操作（如
conn.Read()）需配合conn.SetReadDeadline()，且 deadline 时间要基于ctx.Deadline()计算，不能硬编码 - 纯计算型循环（如解析、校验、加密）必须在关键节点插入
select { case ，否则 ctx 形同虚设
goroutine 启动时就该绑定 ctx，而不是等它自己“感知”
常见反模式是：先 go f()，再在 f 里临时建 ctx——此时超时计时已晚于任务启动，中间调度延迟全算进超时时间里：
立即学习“go语言免费学习笔记（深入）”；
- 正确姿势是：
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)→go f(ctx)→ 函数内所有阻塞调用都接收并使用该ctx - 务必
defer cancel()，否则 timer 和内部 channel 会缓慢泄漏（高频请求下几小时就可观） - 如果函数内要起子 goroutine，必须把
ctx显式传进去，不能靠闭包捕获外层变量——Go 编译器不保证闭包变量的内存可见性及时序
非阻塞轮询场景容易漏掉 default 分支
比如重试逻辑或状态监听，若只写 select { case ，会永久阻塞，错过超时：
- 必须加
default实现非阻塞检查：if ctx.Err() != nil { return ctx.Err() } - 或改用
select { case ，但注意 <code>time.After高频调用开销大，建议复用time.Ticker - 别依赖
ctx.Done()阻塞等待——它只适合“等结果或等超时”，不适合“每 100ms 查一次+随时响应取消”
真正的难点不在“怎么写超时”，而在“超时信号是否真能抵达每一处阻塞点”。哪怕只漏掉一个 db.Query() 没换成 QueryContext()，或一次 conn.Read() 前忘了重设 SetReadDeadline()，整个链路就失去保护。
