Go 中超时控制唯一可靠入口是 context.WithTimeout 或 context.WithDeadline，必须透传至 HTTP/gRPC/DB 等底层调用，禁用手动计时器或内部新建 context。
Go 的 context.WithTimeout 是超时控制的唯一可靠入口
微服务调用中，不设超时等于放弃稳定性。Go 原生只应通过 context.WithTimeout 或 context.WithDeadline 注入超时信号，其他方式（如手动计时器 + select）无法穿透 HTTP 客户端、gRPC 连接、数据库驱动等底层封装。
关键点在于：超时必须从上层 context 一路透传到底层调用链。例如发起 HTTP 请求时，需把带超时的 ctx 传给 http.NewRequestWithContext；gRPC 调用则必须用 grpc.DialContext 和每个方法的 ctx 参数。
- 不要在函数内部新建
context.Background()后再套WithTimeout—— 这会切断父级取消信号 - HTTP 客户端默认不读取 context 超时，必须显式使用
http.NewRequestWithContext，否则client.Timeout仅作用于连接建立阶段，不覆盖请求体发送或响应读取 - gRPC 的
ctx超时优先级高于DialOptions中的KeepaliveParams，但不会中断已发出的流式响应，只影响后续新请求
重试不能靠裸循环，必须配合 context 和错误分类
无条件重试会放大雪崩风险，尤其面对 503、gRPC Unavailable 或网络闪断时。真正的重试逻辑必须满足三个前提：当前 context 尚未超时、错误属于可重试类型、重试次数未达上限。
典型误用是写 for i := 0; i —— 这完全忽略 context 取消，且 sleep 时间固定，可能在最后一次重试刚启动时 context 已过期。
