生产环境禁用boost::circuit_breaker，应选resilience-cpp或cpr::CircuitBreaker；手写需实现原子状态机、滑动时间窗口、半开探活三要素。
熔断器该用哪个库，boost::circuit_breaker 还是自己手写？
别用 boost::circuit_breaker —— 它只是个概念原型，没实现状态切换逻辑、超时重置、半开探测等关键行为，连 try_call 都要你自己补。生产环境直接上 resilience-cpp（Netflix 开源）或轻量级的 cpr::CircuitBreaker（配合 cpr HTTP 库），它们才真正支持 onFailure 回调、滑动窗口计数、自动半开状态跃迁。
手写也行，但必须包含三个硬逻辑：状态机（CLOSED/OPEN/HALF_OPEN）、失败计数+时间窗口（不能只看总次数）、半开状态下只允许一个请求探活。漏掉任意一条，熔断就形同虚设。
- 状态切换必须原子：用
std::atomic<state></state>或带锁的std::mutex，别用裸enum+ 普通变量 - 时间窗口建议用
std::chrono::steady_clock，别依赖system_clock（可能被 NTP 调整） - 半开探测失败后，得重置计数器并退回
OPEN，不是简单“再试一次”
std::future 和 std::promise 怎么套进降级逻辑里？
降级不是“捕获异常后返回默认值”，而是把主调用和降级逻辑包装成可互换的异步执行路径。核心是让 std::promise 的 set_value / set_exception 由熔断器统一调度，而不是由业务线程直接触发。
典型错误是：在 catch 块里直接 promise.set_value(fallback()) —— 这会导致降级函数在调用线程执行，阻塞主线程，且无法控制降级本身的超时。
立即学习“C++免费学习笔记（深入）”；
- 主调用走
std::async(std::launch::async, ...)，绑定超时等待 - 降级逻辑也封装为独立
std::async，但启动时机由熔断器状态决定（比如OPEN状态下跳过主调用，直奔降级） - 用
std::future::wait_for判断主调用是否超时，超时则主动cancel主任务（需配合std::jthread或中断点）
HTTP 调用降级时，curl_easy_setopt 哪些参数会干扰熔断判断？
CURLOPT_TIMEOUT_MS 和 CURLOPT_CONNECTTIMEOUT_MS 必须显式设置，否则默认 0（无限等待），熔断器永远等不到失败信号。更隐蔽的问题是 CURLOPT_FAILONERROR：它只对 HTTP 状态码 ≥400 生效，而网络超时、DNS 失败、连接拒绝这些底层错误根本不会触发它，导致 curl_easy_perform 返回 CURLE_OPERATION_TIMEDOUT 等错误码，必须手动映射到熔断器的 recordFailure()。
- 务必检查
curl_easy_perform返回值，不是只看 HTTP 状态码 - 禁用
CURLOPT_TCP_KEEPALIVE（除非你真需要长连接保活），它可能掩盖真实连接中断 - 不要依赖
CURLOPT_FOLLOWLOCATION自动重定向——重定向失败时错误码易混淆，降级逻辑难对齐
为什么降级函数里调用 std::this_thread::sleep_for 是危险操作？
它会卡死整个调用线程，如果降级本身也慢，或者并发高，线程池迅速耗尽，连熔断器自己的状态更新都会延迟。真正的降级必须是非阻塞或带硬超时的。
常见场景如：主服务超时，降级查本地缓存，结果缓存层恰好也在 GC 或磁盘抖动——sleep_for 会让这个抖动传导成全链路雪崩。
- 降级逻辑优先走内存结构（
std::unordered_map、LRU cache），避免任何 I/O - 必须访问外部资源时，用带超时的异步接口（如
redis-plus-plus的get_timeout） - 所有降级路径都应有 fallback 的 fallback（比如缓存查不到，就返回空对象或预设兜底值，不抛异常）
最常被忽略的一点：熔断器的统计窗口和降级超时必须错开。比如熔断窗口设 60 秒，降级超时却设 50 秒——那第 51 秒的请求会因“刚过窗口”误判为健康，实际降级还没返回。窗口和超时至少留 20% 缓冲。
