Kratos中HTTP和gRPC超时必须显式配置：HTTP需传入带Timeout的自定义http.Client；gRPC每次调用须用context.WithTimeout构造新ctx，二者均无默认超时机制。
偶发性超时不是配置没设，而是某一层的“默认不生效”或“生命周期错配”在捣鬼。Kratos 本身不自动注入超时，所有 outbound 调用都依赖你显式控制 context 或 client 实例——漏掉任意一环，就可能在流量高峰时突然卡住。
HTTP 客户端超时必须显式传入自定义 http.Client
Kratos 的 kratos.NewHTTPClient() 默认用的是封装过的 http.DefaultClient，而后者没有设置 Timeout 字段，等同于永不超时。你以为在 server 端配了 ReadTimeout 就能兜底？那是 inbound 请求接收超时，和你调第三方服务完全无关。
- 必须新建
&http.Client{Timeout: 5 * time.Second}，再传给kratos.NewHTTPClient()的client选项 - 如果用了自定义
http.Transport（比如加了代理、TLS 配置），Timeout仍要放在http.Client层，不能只设transport.DialContext的连接超时 - 别复用全局
http.DefaultClient：它没设Timeout，也没设MaxIdleConnsPerHost，高并发下容易堆积空闲连接或新建过多 TCP 连接
gRPC 调用每次都要带 context.WithTimeout
Kratos 的 gRPC client 没有“客户端级默认超时”机制。grpc.WithTimeout 是旧版已废弃的 Dial 选项，现在无效；client.NewClient() 包装后也不会自动注入 timeout。
- 必须在每次调用前构造带超时的 ctx：
ctx, cancel := context.WithTimeout(ctx, 3*time.Second)，然后立刻 defercancel() - 不能在 service 初始化时 new 一个
grpc.ClientConn就完事——复用 conn 没问题，但每次xxxClient.MethodName(ctx, req)的ctx必须是新鲜的、带超时的 - 如果用了中间件统一 wrap ctx，注意中间件的 ctx 生命周期和实际 RPC 调用不一致，不可靠
别信 middleware 统一加 HTTP 超时的方案
有人想在 HTTP middleware 里用 context.WithTimeout 给所有 outbound 请求兜底，这行不通。Kratos 的 HTTP client 调用不强制走 middleware 注入的 ctx，且 client 内部可能直接用 context.Background() 发起请求。
- middleware 的 ctx 是为 inbound 请求准备的，outbound 调用链路不继承它
- 真正生效的只有两种方式：显式传自定义
http.Client，或在业务代码里手动构造带 timeout 的 ctx 并传给 client 方法（如client.Post(ctx, ...)） - 如果你用的是 Kratos 的
httpx工具类，确认它底层是否透传了你传入的 ctx——很多封装会悄悄 fallback 到context.Background()
最常被忽略的点：超时不是“设了就生效”，而是“在正确位置、用正确方式、对正确对象设”。Kratos 的 client 封装越深，越容易让人误以为它替你管了超时——其实它只管结构，不管语义。每次调用前检查 ctx 是否带 timeout、client 是否有 Timeout 字段、transport 是否干扰了 deadline，比加监控更早发现问题。
