必须由 context.Context 主动驱动超时控制，客户端用 WithTimeout 创建带 deadline 的上下文并传入 RPC；服务端需持续检查 ctx.Err() 并及时退出耗时操作，避免忽略取消信号。
在 Go 的 RPC 调用中，超时控制不能只靠客户端“等一会儿”，必须由 context.Context 主动驱动，配合服务端可中断的处理逻辑，才能真正实现可靠、可取消、可传递的超时管理。
使用 Context.WithTimeout 发起带超时的 RPC 请求
客户端调用前创建带 deadline 的 context，传入 RPC 方法（如 client.Call 或 gRPC 的 ctx 参数）。Go 标准库 net/rpc 本身不直接支持 context，但可通过封装或改用支持 context 的框架（如 gRPC、Kit 等）；若坚持用标准 rpc，需手动结合 channel + select 实现超时等待。
- gRPC 示例：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，后续所有 RPC 方法都传入该ctx - 标准
net/rpc可包装调用：启动 goroutine 执行Call，主 goroutine 用select等待结果或ctx.Done() - 超时触发后，
ctx.Err()为context.DeadlineExceeded，应清理资源并返回明确错误
服务端需响应 Context 取消信号
RPC 处理函数不能忽略传入的 context（尤其 gRPC 的 handler 中默认有 ctx），而要持续检查 ctx.Err() == nil，并在收到取消或超时时及时退出长耗时操作（如数据库查询、文件读写、循环计算）。
- 避免在 handler 中启动无 context 约束的 goroutine，否则超时后仍可能继续执行
- 下游依赖（如 DB 查询）尽量使用支持 context 的驱动（如
database/sql的QueryContext） - 自定义阻塞操作（如 sleep、channel wait）应替换为
select { case
Deadline 应逐跳传递，避免时间被层层叠加
在微服务链路中，每个服务的超时不应简单设为“上游 timeout - 固定缓冲”，而应基于 context deadline 倒推剩余时间。Go 的 context.WithDeadline 或 WithTimeout 会自动计算子 context 的截止时间。
立即学习“go语言免费学习笔记（深入）”；
- 服务 A 调用 B 时，直接将收到的
ctx传下去，B 内部再派生子 context（如加重试）也应基于该 deadline - 不要用
time.Now().Add(2 * time.Second)硬编码新 deadline，易因系统时钟漂移或延迟导致误判 - 可通过
ctx.Deadline()和ctx.Err()判断是否还有时间执行下一步
错误处理与可观测性建议
超时不是静默失败，需清晰区分“业务错误”、“网络错误”和“上下文取消”。日志和监控中应标记 context 相关错误，并记录实际耗时。
- gRPC 错误码优先用
codes.DeadlineExceeded，而非Internal或Unknown - 记录指标如
rpc_duration_seconds{status="deadline_exceeded"}，便于定位超时热点 - 对关键 RPC 可添加简易熔断（如连续超时 3 次暂停请求），防止雪崩
基本上就这些。超时控制本质是协作契约：客户端声明“我最多等多久”，服务端承诺“我尽力在截止前完成并响应”，Context 就是这个契约的载体。不复杂但容易忽略——尤其是服务端没检查 cancel 信号时，超时就只是客户端单方面放弃了。
