必须用 ClientContext::set_deadline() 设置单次调用超时，传入绝对时间点如 std::chrono::system_clock::now() + std::chrono::seconds(5)；重试须依赖服务端支持与客户端启用 ServiceConfig，手动循环无效。
必须用 ClientContext::set_deadline() 设置单次调用超时；重试策略不能靠手动循环实现，得靠服务端支持 + 客户端启用 ServiceConfig 配置。
怎么给单次 gRPC 调用设超时（C++）
gRPC C++ 客户端不接受“超时秒数”这种裸参数，必须传入一个绝对时间点（std::chrono::system_clock::time_point）。常见错误是误用相对时间或忘记设置。
-
ClientContext::set_deadline()是唯一生效的超时入口，不是可选，是必填（尤其对长耗时接口） - 别写
context.set_deadline(std::chrono::seconds(5))—— 这会编译失败，类型不匹配 - 正确写法是：
context.set_deadline(std::chrono::system_clock::now() + std::chrono::seconds(5)) - 如果服务端在 deadline 前没返回，客户端会收到
Status.code() == StatusCode::DEADLINE_EXCEEDED，不是网络错误 - 注意：deadline 一过，底层 TCP 连接可能还在，但该 RPC 流已终止，不会自动重发
为什么手动 for 循环重试基本没用
自己写 for (int i = 0; i 看似简单，实际踩坑极多：
- 客户端 context 已 cancel 或 deadline 已过，后续调用直接返回
CANCELLED，retry 变成空转 - 非幂等操作（如
CreateOrder）重复调用可能产生脏数据，服务端没做幂等校验就炸了 - 没处理
UNAVAILABLE和RESOURCE_EXHAUSTED的语义差异：前者可重试，后者重试只会让雪崩更快 - 丢掉了 backoff 逻辑，连续重试可能打挂下游，而原生 retry 支持
InitialBackoff和BackoffMultiplier
真正可用的重试：ServiceConfig + 环境变量双触发
C++ gRPC 的重试功能默认关闭，必须显式启用，且依赖 JSON 格式的 ServiceConfig。光配代码不够，环境变量也得开。
立即学习“C++免费学习笔记（深入）”；
- 启动前必须设置：
setenv("GRPC_ENABLE_RETRY", "1", 1)（注意是字符串"1"，不是整数） - 构造 channel 时传入
ServiceConfig字符串，例如：
const char* service_config_json = R"({
"methodConfig": [{
"name": [{"service": "my.Service", "method": "DoWork"}],
"retryPolicy": {
"MaxAttempts": 4,
"InitialBackoff": "1s",
"MaxBackoff": "3s",
"BackoffMultiplier": 1.6,
"RetryableStatusCodes": ["UNAVAILABLE", "DEADLINE_EXCEEDED"]
}
}]
})";-
name必须严格匹配 proto 中的package.ServiceName/MethodName，大小写、点号、斜杠一个都不能错 -
RetryableStatusCodes只认服务端返回的状态码，客户端 context 超时产生的DEADLINE_EXCEEDED不触发重试 —— 这点极易被忽略
hedging（对冲）和 retry 别混用
两者互斥：同一 method config 里不能同时定义 retryPolicy 和 hedgingPolicy。对冲适合低延迟敏感、高可用要求场景，但代价是并发请求翻倍。
- 对冲只适用于幂等读操作，且服务端必须能容忍并行请求（比如缓存穿透防护要前置）
- 对冲的
HedgingDelay是从第一次请求发出后开始计时，不是从 context deadline 开始 - 一旦任一对冲请求成功，其余请求会被主动 cancel，但 cancel 操作本身有延迟，可能仍造成服务端资源浪费
- 如果你没在 proto 里声明所有方法为幂等（
idempotency_level = IDEMPOTENT），gRPC C++ 会静默禁用 hedging
真正难的不是写那几行 set_deadline 或 JSON 配置，而是判断哪些接口该加重试、哪些该加对冲、哪些干脆该降级 —— 这得看你的服务契约、错误码语义和下游 SLA，而不是看文档示例抄一遍。
