context deadline exceeded错误主因是API与RPC层超时配置不匹配且未启用重试：需在API的yaml中设Timeout≥RPC层Timeout（如10000≥8000），RPC配置块显式设Timeout（默认2秒易超时），并手动封装fx.DoWithTimeout实现针对网络错误和Unavailable等状态码的2次指数退避重试。
你在Go-Zero项目中调用下游RPC服务时，接口频繁返回context deadline exceeded错误，前端等待十几秒才收到失败响应，用户体验断层，链路监控里超时毛刺持续上扬——这说明API层既没设对超时边界，也没配好重试策略。
设置API层HTTP请求超时时间
打开API服务的.yaml配置文件，在Log同级位置添加Timeout字段。
该值单位为毫秒，代表从HTTP请求进入API服务到返回响应的总耗时上限，超时后直接由go-zero框架返回504 Gateway Timeout，不进入业务逻辑。
【Timeout必须大于等于下游RPC调用的超时时间】，否则API层自己先超时，RPC根本没机会执行完。
例如：若RPC层配置了Timeout: 8000（8秒），则此处至少设为Timeout: 10000（10秒）。
配置API调用RPC的超时时间
在MsmRpcConf（或其他对应RPC服务配置块）内，设置Timeout字段。
这个值会被go-zero的TimeoutInterceptor拦截器读取，并作为RPC调用上下文的父context超时基准——它会覆盖你在代码里用context.WithTimeout手动创建的子context超时时间。
若不显式配置，go-zero默认使用2秒，极易触发DeadlineExceeded错误。
方法一：静态配置（推荐）
在rpc服务配置的Endpoints同级写：Timeout: 8000。
方法二：动态透传（慎用）
在API逻辑层调用RPC前，用ctx, cancel := context.WithTimeout(r.ctx, 8*time.Second)构造新context，再传入RPC客户端。但注意：该方式仅在未配置Timeout字段时生效；一旦yml中已设，拦截器会强制以yml值为准，你的WithTimeout将被忽略。
启用智能重试机制
第一步：确认RPC客户端已启用重试拦截器
检查rpcx.NewClient或zrpc.MustNewClient初始化时是否传入zrpc.RpcClientOpt{Retry: true}；若未传，默认不重试。
第二步：在API逻辑层调用RPC时包裹fx.DoWithTimeout
这不是可选动作——go-zero原生RPC客户端不自动重试，必须手动封装。
第三步：编写带错误过滤的重试逻辑
只对网络类错误（如net.OpError、url.Error且Timeout()为true）和gRPC状态码codes.Unavailable、codes.ResourceExhausted重试；codes.DeadlineExceeded和codes.InvalidArgument绝不重试。
第四步：控制重试次数与间隔
建议最多2次重试，首次延迟100ms，第二次延迟300ms，避免雪崩式放大流量。不要用time.Sleep硬等，应使用fx.DoWithTimeout内置的指数退避支持。
