kratos http客户端超时需显式配置http.client的timeout字段，不可依赖服务端配置或defaultclient；推荐新建带timeout的client并传入kratos.newhttpclient()。
超时设置在 Kratos 的 HTTP 客户端里怎么配
Kratos 默认用 http.Client 发起请求，但它的 transport 和 timeout 不是全局生效的——你得在每个 http.Client 实例上单独设。直接改 kratos.NewHTTPClient() 返回的 client 不行，它内部封装了默认配置，必须显式传入自定义 client。
常见错误是以为在 server/http.go 里配了 server 超时（比如 ReadTimeout），就等于 client 请求也超时了。其实那是服务端接收请求的超时，和 outbound 请求完全无关。
- 用
http.DefaultClient是危险的：它没有设置Timeout，可能无限 hang 住 - 推荐方式：新建
&http.Client{Timeout: 5 * time.Second}，再传给kratos.NewHTTPClient()的client选项 - 如果用了
transport（比如加了代理、TLS 配置），记得把Timeout放在client层，而不是只设transport.DialContext的连接超时
gRPC 客户端的超时怎么控制
Kratos 的 gRPC client 默认不带超时，每次调用都得手动传 context.WithTimeout。没传的话，底层会用 context.Background()，等同于永不超时。
容易踩的坑是：在 service 层统一 new 一个 grpc.ClientConn 就完事，后续所有 RPC 都复用它，但没在每个 ctx 上加 timeout。结果某个后端接口卡死，整个调用链就堵住。
- 必须在每次
xxxClient.MethodName(ctx, req)前构造带超时的ctx，例如ctx, cancel := context.WithTimeout(ctx, 3*time.Second) - 别在
client初始化时设全局 timeout —— gRPC 没这个机制，grpc.WithTimeout是旧版已废弃的 Dial 选项，现在无效 - 如果用 Kratos 的
client.NewClient()包装了 gRPC client，它不会自动注入 timeout，仍需业务层自己处理
中间件里统一加 HTTP 超时靠谱吗
有人想在 middleware 里用 context.WithTimeout 给所有 outbound HTTP 请求兜底，这不可靠。因为 Kratos 的 HTTP client 调用不强制走 context，且中间件的 ctx 生命周期和 client 请求生命周期不一致。
更实际的做法是：把超时逻辑下沉到 client factory 层，比如封装一个 NewUserClient(timeout time.Duration) 函数，内部创建带 timeout 的 http.Client 并注册进 DI 容器。
- 避免在 handler 或 middleware 中临时 patch context timeout，容易漏掉或覆盖
- 如果项目里有多个外部 HTTP 依赖（用户服务、订单服务等），建议按依赖维度分别配置 timeout，而不是一刀切
- 注意：Kratos 的
httpx工具包里Do方法接受context.Context，但它只影响请求发起阶段，不替代http.Client.Timeout对整个请求周期（DNS、connect、tls、read）的控制
超时时间设多少才合理
没有通用值。5 秒对多数 API 过长，对文件上传又太短。关键要看下游服务 SLA、网络 RTT、是否重试、以及失败后 fallback 策略。
尤其要注意 Kratos 默认开启的重试（比如 retry.Interceptor），如果单次 timeout 设 3 秒、重试 3 次，实际最长可能卡 9 秒 —— 这会拖垮上游的 P99 延迟。
- 建议首次 timeout 设为下游 P95 延迟 × 1.5，再根据压测调整
- 对强依赖服务（如鉴权），timeout 应更激进（1~2 秒），配合快速失败和降级
- 务必在日志里打上
timeout和err，否则超时错误和网络错误混在一起，排查时根本分不清是慢还是断
超时不是设个数字就完事，它和重试、熔断、监控指标强耦合。Kratos 本身不提供 timeout 自动传播或继承机制，每层都得自己想清楚边界在哪里。
