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 去执行，结果上游早已断连，下游还在傻等。
- 派生子
ctx时，timeout 值应 ≤ 父ctx剩余可用时间（可通过parentCtx.Deadline()计算） - 建议封装一个辅助函数，如
SubTimeout(parentCtx, 2*time.Second)，内部自动取 min - 在中间件或 SDK 层做防御性检查，日志告警“子 ctx deadline 晚于父 ctx”这类异常组合
WithTimeout，而是每个环节是否都尊重并向下传递了这个信号——从 HTTP client、RPC 框架、数据库驱动，到你自己写的 for 循环和 select case。漏掉任意一环，整条链就断在那儿了。 
