超时错误是客户端 deadline 设置过短导致的“等不及了”，而非服务宕机；需合理设置 context.WithTimeout，结合 P99 耗时与链路开销（如 600ms 起步），每次 RPC 新建带 cancel 的 ctx，并确保服务端监听 ctx.Done()及时中断阻塞操作。
超时错误不是服务挂了，是“等不及了”
报 rpc error: code = DeadlineExceeded desc = context deadline exceeded，大概率不是服务崩了、网络断了，而是客户端设的 deadline 比服务端实际响应快——它还没来得及返回，上下文就已过期并被取消。Grafana 显示下游库存服务无异常，也印证这点：问题出在上游调用链路的控制逻辑，而非服务本身不可用。
检查客户端 context.WithTimeout 的设置是否合理
这是最常见也最容易忽略的一环。很多团队把超时时间写死成 1 * time.Second，但没结合真实 P99 耗时和链路开销评估：
- 用
ghz或hey在测试环境压测，观察GetOrderDetails的 P95/P99 响应时间（比如实测是 320ms） - 加上建连、TLS 握手、序列化/反序列化、网关转发等固定开销（通常额外 100–200ms）
- 最终 deadline 至少设为
P99 + 链路开销 + buffer（50–100ms），例如600ms起步 - 避免全局复用一个带 deadline 的
context，每次 RPC 必须新建：ctx, cancel := context.WithTimeout(ctx, 600*time.Millisecond)，且必须defer cancel()
确认服务端是否真正响应了 ctx.Done()
客户端超时后，gRPC 不会强制中断服务端 goroutine，只把 ctx.Done() channel 置为可读。如果业务代码没监听它，就会继续执行，白白占用资源：
- 检查
GetOrderDetails实现里是否有阻塞操作（如未传ctx的 DB 查询、HTTP 调用、大文件读取） - SQL 查询必须用支持 context 的驱动（如
database/sql+pgx/v5），并显式传入ctx：rows, err := db.QueryContext(ctx, sql, args...) - 调外部 HTTP 接口时，
http.Client必须用带ctx的方法：client.Do(req.WithContext(ctx)) - 任何
select语句都应包含case 分支
别只盯着代码，查连接层和中间件延迟
高并发下，DeadlineExceeded 很可能是连接池打满、TLS 握手排队、或网关限流导致的“伪超时”：
- 用
tcping -t $HOST $PORT验证基础连通性；再用grpcurl -plaintext -d '{}' $HOST:$PORT proto.Service/GetOrderDetails单次调用，排除 DNS/TLS 问题 - 检查 gRPC 客户端是否启用了
grpc.WithBlock()—— 高并发下若 DNS 解析慢或服务发现延迟，它会让所有 goroutine 卡在DialContext阶段，后续请求全因 context 过期失败 - 确认负载均衡器（如 Envoy）或 API 网关是否对单个连接设置了
max_requests_per_connection或idle_timeout，频繁重连会放大握手耗时 - 开启 gRPC 客户端日志：
GRPC_GO_LOG_SEVERITY_LEVEL=info GRPC_GO_LOG_VERBOSITY_LEVEL=3，重点看transport: loopyWriter.run returning. connection error类错误
真正难处理的不是超时本身，而是超时掩盖了底层资源瓶颈：连接池耗尽、慢查询未 cancel、TLS 握手排队……这些不会直接报错，但会让 deadline 变得极其脆弱。压测时务必同时采集客户端连接数、服务端 goroutine 数、数据库活跃连接数，否则调再久的 WithTimeout 参数也只是在给症状贴膏药。
