grpc客户端调用超时必须通过context.withtimeout显式传入每次调用，grpc.dial的timeout参数仅作用于连接建立阶段；服务端需检查ctx.err()及时退出；流式rpc需对整个生命周期统一使用同一ctx。
gRPC客户端调用怎么加超时？用context.WithTimeout就行
gRPC本身不内置超时逻辑，所有超时必须靠context传递。直接在发起client.SomeMethod()前包一层context.WithTimeout，是最常用也最可靠的做法。
常见错误是只给context.Background()加WithTimeout但没传给调用函数——必须把新生成的ctx作为第一个参数显式传进去，否则完全无效。
- 超时时间建议设为略大于服务端预期处理时长（比如服务端SLA是800ms，客户端设1s）
- 不要用
time.AfterFunc或select手动控制，gRPC不会感知那些信号 - 如果调用链涉及多个gRPC跳转（比如A→B→C），每个跳转都得单独设超时，父context超时不会自动透传到下游
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel() resp, err := client.DoSomething(ctx, req)
为什么grpc.Dial里的timeout参数不管用？
grpc.Dial的grpc.WithTimeout（已废弃）或grpc.WithConnectParams里配的超时，只影响连接建立阶段（TCP握手 + TLS协商 + gRPC协议升级），不是业务调用超时。一旦连接成功，它就彻底失效了。
很多同学看到连接很快、调用却卡死几十秒，就是误以为这个参数能控制client.Call()行为。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 新版gRPC Go（v1.27+）已移除
grpc.WithTimeout，用grpc.WithTransportCredentials等替代 - 真正要控业务超时，只能靠每次调用时传入带deadline的
context - 连接超时建议设短些（比如3~5秒），避免阻塞初始化；业务超时则按接口SLA单独设
服务端怎么响应超时？status.Code(err) == codes.DeadlineExceeded
客户端超时后，err会是*status.Error类型，且status.Code()返回codes.DeadlineExceeded。服务端自己不主动“触发”这个状态——它是客户端断开连接后，gRPC底层自动填充的。
这意味着：服务端代码里不需要写if ctx.Err() == context.DeadlineExceeded来特殊处理；但如果你在服务端做了耗时操作（比如数据库查询），应该主动检查ctx.Err() != nil并提前退出，避免浪费资源。
- 服务端检查
ctx.Err()比依赖status.Code更及时，尤其在流式RPC中 - 注意
ctx.Err()可能是context.Canceled（用户取消）或context.DeadlineExceeded（超时），语义不同 - 别在服务端用
time.Sleep模拟超时测试——真实超时是连接中断，不是延迟返回
流式RPC（Streaming）超时怎么设？
Unary调用超时设一次就够了，但Streaming（比如client.StreamSomething()）需要更小心：超时要覆盖整个流生命周期，包括Send、Recv、CloseAndRecv等每一步。
最容易踩的坑是只给StreamSomething()传超时context，但后续stream.Recv()没再传——这时候Recv()会一直阻塞，直到连接被服务端或网络中断。
- 推荐做法：用同一个
ctx贯穿整个流对象创建和所有I/O操作 - 如果需要不同阶段不同超时（比如发送快、接收慢），得用
context.WithTimeout套嵌，但务必注意cancel顺序 - 流式场景下，服务端主动
Send失败或客户端Recv返回io.EOF，不代表超时；只有context.DeadlineExceeded才表示真超时
ctx，漏一次就等于没设。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
