context.withtimeout传不进底层i/o操作最常见的情况是未将ctx透传至http.newrequestwithcontext、db.querycontext等支持context的api，或自定义goroutine中未select监听ctx.done()，导致超时后i/o仍阻塞、资源泄漏。
context.WithTimeout 传不进底层 I/O 操作
最常见的情况是：调用 context.WithTimeout 创建了带超时的 ctx，但下游的 HTTP 请求、数据库查询或自定义 goroutine 里根本没用它——比如还用 http.NewRequest 而不是 http.NewRequestWithContext，或者在 database/sql 中没把 ctx 传给 QueryContext / ExecContext。
后果是：超时时间到了，ctx.Done() 确实关闭了，但你的 I/O 调用完全不响应它，协程照常阻塞，资源继续占用。
- HTTP 客户端必须用
http.NewRequestWithContext(ctx, ...)，再交给http.Client.Do - 数据库操作必须用
db.QueryContext(ctx, ...)，不能用db.Query(...) - 自定义 long-running goroutine 必须在循环中
select监听ctx.Done()，不能只在开头检查一次 - 第三方库（如 Redis 客户端）要确认是否支持 context；不支持的需手动加超时兜底逻辑
cancel() 忘记 defer 调用导致 timer 泄漏
context.WithTimeout 内部依赖 time.Timer 实现定时取消。如果创建后没调用 cancel()，哪怕超时已触发，这个 timer 也不会被 GC 回收，长期运行的服务会累积大量 goroutine 和 timer 对象。
典型错误写法：ctx, _ := context.WithTimeout(...) —— 直接丢弃 cancel 函数。
- 必须写成
ctx, cancel := context.WithTimeout(...)，且紧跟着defer cancel() - 即使你确定 ctx 一定会超时（比如设了 100ms），也要 defer cancel；因为超时前若提前退出（如业务逻辑快速返回），不 cancel 就浪费 timer
- 在中间件或封装函数里传递 ctx 时，cancel 的调用责任必须明确归属——谁创建，谁 defer
HTTP Client Timeout 和 context 超时混用冲突
很多人以为设了 http.Client.Timeout 就不用 context，其实二者控制层级不同，甚至可能互相干扰：
-
http.Client.Timeout只约束单次请求的总耗时（DNS + 连接 + 写 + 读），且发生在 transport 层，无法中断中间件或重试逻辑 -
context.WithTimeout控制的是整个业务流程，比如“查缓存 → 查 DB → 调远程服务”，可提前终止任意阶段 - 若
http.Client自己设置了Timeout，它会在内部新建一个子 context，可能覆盖你传入的 deadline - 推荐做法：禁用
http.Client.Timeout（设为 0），全由外层 context 控制；同时单独配置http.Transport的ResponseHeaderTimeout等字段防卡死
微服务链路中 context 跨进程丢失 deadline
在 gRPC 或 HTTP 微服务调用中，context 的 deadline 不会自动跨网络传递。上游设了 500ms 超时，下游服务拿到的 ctx 默认是 background，没有 deadline，导致超时无法级联。
必须显式序列化 deadline 并透传：
- HTTP 场景：用
X-Request-Deadline或X-Timeout-Ms头携带截止时间戳（UnixMilli），下游解析后用context.WithDeadline重建 ctx - gRPC 场景：用
grpc-middleware的chain.UnaryServerInterceptor自动提取grpc.WaitForReady和 deadline 元数据 - 永远不要依赖
context.WithValue传 deadline——它不参与 cancel 传播，且无法跨进程 - 调试时打印
ctx.Deadline()和ctx.Err()，确认下游是否真正继承了超时约束
真正难的不是写对那几行 WithTimeout，而是确保每个 I/O 调用都响应它、每个 goroutine 都监听它、每个服务节点都传递它——漏掉任意一环，超时就变成摆设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
