context.Context 到底怎么用？实战中如何控制链路超时？-Golang-PHP中文网

context.WithTimeout是链路超时控制的第一道防线，须在每次依赖调用前派生独立子ctx并defer cancel；rpcx需手动透传解析timeout元数据，http和database/sql则原生或部分支持；禁用WithValue传超时，超时嵌套时子ctx deadline应≤父ctx剩余时间。

context.WithTimeout 是最常用的链路超时入口

绝大多数 rpc 调用、http 请求、数据库查询的超时控制，都应该从 context.withtimeout 开始。它不是“可选装饰”，而是你主动声明“这个操作最多活多久”的第一道防线。

常见错误是只在最外层调用一次，然后把同一个 ctx 传给所有子函数——这看似省事，实则埋下隐患：一旦某个子操作（比如日志写入或异步通知）耗时过长，它会拖垮整个请求的 deadline，而你根本没打算让它参与主链路超时判断。

每次发起新依赖调用前，都应基于当前 ctx 派生一个带独立 timeout 的子 ctx，例如：ctx, cancel := context.WithTimeout(parentCtx, 2*time.Second)
务必 defer cancel()，否则 goroutine 泄漏风险极高（尤其在 error early return 场景下）
不要用 time.AfterFunc 或 time.Sleep 替代 WithTimeout，它们无法传递取消信号给下游协程

rpcx 和 net/http 中的超时传递机制完全不同

Go 标准库的 http.Client 会把 context.Context 里的 deadline 自动转为底层连接/读写的超时参数；但 rpcx 这类自定义协议框架，需要手动把 deadline 编码进请求元数据（metadata），再由服务端解析还原。

如果你在 rpcx 客户端用了 context.WithTimeout，但服务端没调用 share.FromContext(ctx) 提取 metadata 里的超时值，那服务端根本不知道该在几秒内返回——它只会按自己默认逻辑跑完，导致“客户端已超时退出，服务端还在忙”。

rpcx 服务端必须显式调用 share.FromContext(ctx) 并检查 md.Metadata()["timeout"] 字段
net/http 服务端天然支持，只要 handler 函数签名含 ctx context.Context 参数，且你在 http.Server 配置中启用了 BaseContext（Go 1.19+ 默认开启）
数据库驱动如 database/sql 仅对 QueryContext/ExecContext 等带 Context 的方法生效，普通 Query 不受控

WithValue 传超时值？别这么干

有人试图用 context.WithValue(ctx, "timeout", 5*time.Second) 手动塞超时时间，这是典型反模式。Context 的 Value 本意是传请求 ID、用户身份等不可变元数据，不是控制执行逻辑的开关。

这样做会导致两个问题：一是下游无法通过标准方式感知 deadline（ctx.Deadline() 返回 false），二是绕过了 Go runtime 对 timerCtx 的统一调度，可能让 goroutine 在超时后继续运行。

超时控制必须走 WithTimeout / WithDeadline 创建的 timerCtx 实例
WithValue 只适合传 traceID、userID、locale 等只读标识，且 key 类型推荐用私有未导出类型防冲突
如果真要透传自定义超时策略（比如“重试时放宽到8秒”），应该封装成独立结构体，通过 WithValue 传，但最终仍需转换为 WithTimeout 调用

超时嵌套时，子 ctx 的 deadline 一定比父 ctx 更早吗？

不一定。Go 的 context 实现不会强制校验父子 deadline 关系。你可以写出 ctx1 := context.WithTimeout(context.Background(), 10*time.Second)，再基于它创建 ctx2 := context.WithTimeout(ctx1, 30*time.Second)——此时 ctx2.Deadline() 返回的是 30 秒后，而非继承父级的 10 秒限制。

这在实际链路中非常危险：上游服务设了 10s 超时，下游却按 30s 去执行，结果上游早已断连，下游还在傻等。