gRPC客户端超时必须显式传入context.WithTimeout生成的ctx，否则无效；服务端需主动检查ctx.Err()响应超时，且所有阻塞操作都须支持该ctx。
gRPC客户端调用必须显式传入context.WithTimeout生成的ctx
不传就等于没设超时。gRPC方法签名强制要求第一个参数是context.Context，但context.Background()本身无deadline，context.WithTimeout()返回的新ctx才携带超时信号。常见错误是只调用了context.WithTimeout()却没把它传给client.SomeMethod()——函数内部完全感知不到超时。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 每次gRPC调用前都得新建一个带超时的ctx，不能复用或漏传
-
defer cancel()必须写在调用前，否则goroutine泄漏风险极高 - 超时时间建议比服务端SLA长20%~50%，比如服务端承诺800ms，客户端设1.2s
- 别用
time.AfterFunc或select手动模拟超时，gRPC不会响应那些信号
服务端必须主动检查ctx.Err()才能响应超时
客户端传来的deadline不会自动中断服务端代码。gRPC服务端收到的ctx是序列化后重建的，它只提供Done()通道和Err()方法，但不会自动终止你的for循环、数据库查询或sleep。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 所有阻塞操作前都要加
select判断：case - 数据库操作必须用
db.QueryContext(ctx, ...)而非db.Query(...) - HTTP调用要传
req.WithContext(ctx)给http.Client.Do() - 绝对不要写
time.Sleep(3 * time.Second)，改用time.After配合ctx.Done()
grpc-timeout metadata是deadline跨进程传播的唯一标准路径
gRPC协议规定deadline通过grpc-timeout这个固定key透传，不是靠“把ctx原样发过去”。客户端拦截器自动注入，服务端拦截器自动解析并重建ctx。如果手动拼metadata.MD或用自定义header（如X-Deadline），deadline就断链了。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 客户端不用手动操作metadata，只要传对ctx，gRPC-go默认启用透传
- 服务端拦截器里必须调用
grpc.SendHeader()或grpc.SetHeader()触发deadline解析 -
grpc-timeout值格式严格：单位只能是h/m/s/ms/us/ns，比如"500ms"，空格或非法单位会导致静默丢弃 - gRPC-Go v1.60+对value校验更严，下游ctx.Err()为nil大概率是metadata格式错了
流式RPC的超时不能只靠初始ctx.WithTimeout
初始context超时控制的是整个RPC生命周期（从stream.Send()开始到stream.CloseSend()结束），不是单次Recv()或Send()的等待时间。如果服务端每条消息间隔1.8秒，客户端设了5秒总超时，第三条消息就会因累计超时被断开，而你根本没机会处理已收到的前两条。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 对每个
stream.Recv()单独套一层context.WithTimeout()，比如每次最多等2秒 - 更稳妥的做法是服务端分块发送 + 客户端按需续租，例如每10条发一次ack
- 避免用
stream.Context().Done()直接监听，它反映的是总超时，不是单次IO - 如果必须用长连接，建议服务端主动心跳，客户端用
time.AfterFunc重置超时计时器
真正容易被忽略的点是：超时计时从context.WithTimeout()调用那一刻就开始了，DNS解析、TLS握手、连接池排队全算在内。你以为给了3秒，结果握手花了2.3秒，留给业务逻辑只剩700毫秒——这不是bug，是设计使然。
