用 context.WithTimeout 控制 goroutine 超时需全链路传递 ctx 并响应 Done()，避免泄漏；time.After 勿滥用在循环中，应改用可重置的 timer；channel 超时必须 select + context。
用 context.WithTimeout 控制 goroutine 生命周期
超时不是“等一会儿再杀”，而是让整个操作链主动感知截止时间并提前退出。最直接的方式是通过 context.WithTimeout 创建带截止时间的 ctx，然后在所有可能阻塞的地方（如 HTTP 请求、channel 读写、数据库查询）传入该上下文。
常见错误是只在顶层加 timeout，但子 goroutine 没有接收或响应 ctx.Done() —— 这会导致 goroutine 泄漏。
- 必须在每个可能阻塞的调用中显式传入
ctx，例如http.NewRequestWithContext(ctx, ...)、db.QueryContext(ctx, ...) - 自己写的阻塞逻辑（比如轮询、sleep 等）需配合
select监听ctx.Done()，不能只靠外部中断 - 注意
context.WithTimeout返回的cancel函数要被调用（通常用defer cancel()），否则底层定时器不会释放
避免 time.After 在循环中滥用导致内存泄漏
time.After 内部会启动一个 goroutine 和一个 timer，如果在高频循环里反复调用（比如每毫秒一次），timer 不会被复用，旧的 timer 会在超时前一直占着资源，最终拖垮程序。
正确做法是用 time.NewTimer 或 time.AfterFunc 配合重置逻辑，尤其在需要重复超时控制的场景（如重试机制）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 循环中要用
timer.Reset(d)替代新建time.After(d) -
timer.Stop()必须调用，否则即使已触发，timer 对象仍可能被 runtime 缓存，影响 GC - 如果只是单次等待，
time.After没问题；但凡涉及多次、条件性、可取消的等待，优先选context+select
channel 超时读写必须用 select + default 或 context
直接对 channel 执行 val := 是永久阻塞的，没有内置超时。很多人误以为加个 <code>time.Sleep 就能“模拟超时”，其实只是错失了时机，且无法真正中断等待。
唯一安全的方式是用 select 配合 case 和 <code>case （简单场景）或更推荐的 <code>case （可取消、可组合）。
- 不要用
time.After做长周期超时（比如 5 分钟），它会 hold 住 timer 至少到超时点，影响调度精度 - 若 channel 可能永远不写入，又不想阻塞主流程，
select中必须有default分支（非阻塞尝试）或超时分支，否则行为不可控 - 多个 channel 协作时，把超时统一交给 context，比混用多个
time.After更易维护和取消
HTTP 客户端超时必须分层设置，不能只靠 context
仅给 http.Client.Do 传 context 只能控制“请求发起后到响应返回前”的总耗时，但无法约束 DNS 解析、连接建立、TLS 握手这些前置阶段——它们可能卡在系统调用里，绕过 context。
真正健壮的 HTTP 超时需要三层配合：
-
http.Client.Timeout：整体最大耗时（含阻塞在队列中的时间） -
http.Client.Transport中设置.DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout等细粒度字段 - 业务层再用
context.WithTimeout包一层，用于 cancel 整个调用链（比如用户已放弃等待）
漏掉任何一层，都可能出现“明明设了 3 秒超时，结果卡了 30 秒才返回”的情况。
