gRPC C++ 重试与熔断需手动实现，仅临时性错误（UNAVAILABLE、DEADLINE_EXCEEDED等）可重试，须解析error_details；熔断需按method+host维度滑动时间窗口统计，并原子更新状态，避免资源泄漏与上下文错乱。
gRPC C++ 重试策略必须手动实现，官方不支持自动重试
gRPC C++ 客户端默认关闭重试（retry_policy 不生效），连基础的 StatusCode::UNAVAILABLE 自动重试都没有。所谓“带熔断的重试”，得靠你自己组合 grpc::Status 检查、定时器、状态计数器和请求拦截——没有现成的 RetryInterceptor 或 CircuitBreakerChannel。
怎么判断该不该重试？只看 status.error_code() 不够
很多同学一上来就写 if (status.error_code() == grpc::StatusCode::UNAVAILABLE) 就重试，结果在服务端返回 INVALID_ARGUMENT 时也重试，把错误请求反复发过去。真正该重试的只有**临时性失败**：
-
grpc::StatusCode::UNAVAILABLE（连接断、服务未就绪）✅ -
grpc::StatusCode::DEADLINE_EXCEEDED（超时，可能网络抖动）✅ -
grpc::StatusCode::INTERNAL（仅当确定是服务端瞬时错误，比如线程池满）⚠️ 需结合日志或 header 判断 -
grpc::StatusCode::ABORTED（冲突类错误，如乐观锁失败）✅，但要确认是否幂等 -
grpc::StatusCode::UNKNOWN或grpc::StatusCode::CANCELLED❌ 不重试
注意：status.error_details() 里可能有自定义错误码（比如 JSON 字符串），这时光看 error_code() 会漏判，得解析 status.error_details()。
熔断器不能只看失败次数，得绑定时间窗口和半开逻辑
简单计数器（比如连续 5 次失败就熔断）在高并发下会误熔：不同请求混在一起统计，一个慢请求拖垮整个 channel。正确做法是用滑动时间窗口 + 独立状态机：
立即学习“C++免费学习笔记（深入）”；
- 用
std::chrono::steady_clock记录最近 60 秒内失败请求数，超过阈值（如 10 次）进入OPEN状态 -
OPEN状态持续 30 秒后自动转为HALF_OPEN，只放行 1 个试探请求 - 试探成功则恢复
CLOSED；失败则重置熔断计时器 - 熔断状态必须按
method_name + host:port维度隔离，不能全局共享——否则/UserService/Get熔了，/OrderService/Create也被拦住
别用 std::atomic_int 直接累加，它没时间衰减能力；推荐用 absl::Time + std::vector 存失败时间戳，或引入 prometheus-cpp 的直方图做滑动统计。
重试 + 熔断组合时最容易崩的是超时传递和上下文泄漏
常见崩溃点不是逻辑错，而是资源没清理：
- 每次重试都新建
grpc::ClientContext，但忘了调用context.set_deadline()—— 第二次重试沿用第一次的 deadline，导致本该重试的请求直接超时 - 在
HALF_OPEN状态下发起试探请求，用的是原始std::shared_ptr<:channel></:channel>，但熔断器内部可能已切换到降级 stub，结果请求发到了旧 channel 上 - 异步重试用
AsyncUnaryCall时，CompletionQueue被提前Shutdown()，回调里访问已析构的shared_ptr导致 UAF - 重试间隔用
std::this_thread::sleep_for()堵塞线程，卡死整个 IO 线程池（尤其用ThreadPool时）
真正稳的做法：所有重试调度走独立的 grpc::CompletionQueue + Timer，deadline 每次重试前重新计算，channel 获取通过封装好的 GetActiveChannel() 方法动态路由。
复杂点在于熔断状态变更和重试决策必须原子更新，std::atomic 支持不了复合状态，得用 std::mutex + std::condition_variable 或 folly::Synchronized。这点很多人一开始想绕过去，最后都在压测时 core dump。
