熔断器状态切换不生效，主因是exceptionsAllowedBeforeBreaking与时间窗口不匹配，且异常未被策略捕获——如只捕获HttpRequestException却抛出TaskCanceledException；需用Handle()兜底或精准匹配异常类型，并确保异步调用配ExecuteAsync。
熔断器状态切换不生效？检查 exceptionsAllowedBeforeBreaking 和时间窗口是否匹配
常见现象是熔断器始终处于 Closed 状态，即使连续抛出异常也不触发 Open。根本原因常是策略没绑定到真实失败路径——比如只捕获 HttpRequestException，但实际抛出的是 TaskCanceledException（超时）或 InvalidOperationException（JSON反序列化失败）。
实操建议：
- 用
Handle<exception>()</exception>兜底，上线后再按需收紧；若必须精准，用HandleResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)捕获 HTTP 业务错误 -
exceptionsAllowedBeforeBreaking是“连续失败次数”，不是“单位时间失败率”。它依赖内部计数器重置逻辑，默认按调用顺序累加，不自动按时间滑动。若想基于滑动窗口统计错误率，得换用AdvancedCircuitBreaker或自行封装 - 测试时别用
.Result或.Wait()，它们可能掩盖异步异常类型，导致熔断器收不到预期异常
为什么 BrokenCircuitException 没被捕获？确认执行方式与策略类型一致
典型错误：在 async 方法里调用 Execute（同步执行），但服务调用本身是异步的，结果异常被吞掉或抛到线程池，BrokenCircuitException 根本不会冒泡上来。
实操建议：
- 异步调用必须配
ExecuteAsync+async/await，例如：circuitBreakerPolicy.ExecuteAsync(async () => await _httpClient.GetAsync(url)) - 不要混用同步和异步策略：用
Policy.Handle<T>().CircuitBreakerAsync(...)创建异步策略，否则ExecuteAsync会报编译错误 -
BrokenCircuitException只在熔断器处于Open状态时、且策略尝试执行时才抛出。如果策略没被真正调用（比如被上层条件提前 return），它就不会出现
半开状态（Half-Open）下请求仍失败？重点看 durationOfBreak 和探测逻辑
熔断器从 Open 切到 Half-Open 后，第一个请求成功了，但后续请求又失败——这说明恢复判断太激进。Polly 默认只允许一个请求试探，成功即闭合，失败则重置计时器并回到 Open。
实操建议：
-
durationOfBreak设得太短（如TimeSpan.FromSeconds(5)）会导致频繁试探，尤其在网络抖动时容易反复开闭。生产环境建议从 30 秒起步，再根据服务平均恢复时间调整 - 半开状态不支持“批量试探”，Polly 的
Half-Open是单请求探针机制。如需更柔性恢复（比如放行 3 个请求，2 个成功才闭合），得用AdvancedCircuitBreaker并自定义onHalfOpen回调 - 确保探测请求本身轻量：不要在半开时调用带 DB 查询或复杂计算的接口，否则一次慢请求就直接打回
Open
多个 API 调用共用一个熔断器？隔离粒度不足引发误熔断
把所有 HTTP 调用塞进同一个 CircuitBreakerPolicy 实例，结果 A 接口故障导致 B 接口也被熔断——这是最隐蔽的雪崩诱因。
实操建议：
- 每个下游服务、甚至每个关键 endpoint 都应有独立熔断器实例，命名体现用途，例如：
_userApiCircuit、_paymentTimeoutCircuit - 避免在
Singleton服务中复用策略对象。正确做法：注册为Scoped或用工厂模式按需创建，防止跨请求状态污染 - 如果用
HttpClientFactory，可在AddHttpClient时用ConfigurePrimaryHttpMessageHandler绑定专属熔断器，比手动 new 更安全
Policy.Handle，而是让熔断器在复杂调用流中，只在该断的时候断，且断得干净、恢复得稳当。 
