Go熔断器需显式配置失败阈值、窗口时间与半开探测间隔才能进入半开状态；默认不启用半开逻辑，须通过ReadyToTrip函数返回true触发open→half-open切换，且仅允许一个探测请求通过。
Go 熔断器怎么进入半开状态
熔断器不是自动进半开的，必须显式配置失败阈值、窗口时间和半开探测间隔。默认 circuitbreaker.NewCircuitBreaker()（如 github.com/sony/gobreaker）不会开启半开逻辑，得靠 ReadyToTrip + OnStateChange 配合定时器手动触发。
常见错误是只设了 MaxRequests: 1 和 Timeout: 60 * time.Second，却没配 ReadyToTrip 函数——结果永远卡在 open，根本等不到半开。
-
ReadyToTrip要返回 true 才能从 open 切到 half-open；典型写法是检查最近 N 次失败率是否超阈值 - 半开不是“自动轮询”，而是下一次请求进来时，熔断器发现状态是 open 且已过
Timeout，才允许一个请求通过 - 如果那个探测请求成功，状态切回 closed；失败则重置
Timeout，继续 open
半开状态下只放行一个请求的原理和风险
半开的本质是“试探性放行”，不是“限流式放行”。gobreaker 的 halfOpen 状态下，Allow() 方法内部只允许第一个请求通过，后续立刻返回 ErrTooManyRequests，直到该请求完成（无论成败）。
这带来两个关键约束：
立即学习“go语言免费学习笔记（深入）”；
- 探测请求必须有明确超时（比如用
context.WithTimeout），否则整个半开窗口被阻塞住，其他请求全卡死 - 不能把耗时长的调用（如未设 timeout 的 HTTP 请求）直接丢进半开流程，否则
Timeout值会被无效拉长 - 如果探测请求本身 panic 或未调用
MarkSuccess()/MarkFailure()，状态会卡在 half-open，后续请求全拒
如何安全地自定义半开探测行为
标准库和主流包（gobreaker / resilience-go）不提供“定期 ping 探测”的接口，因为熔断器设计上是响应式而非主动式。真要定期探活，得自己起 goroutine + timer，但必须绕过熔断器的 Allow() 控制，否则会干扰状态机。
推荐做法：单独维护一个 *http.Client 或健康检查专用 client，用独立指标判断下游是否恢复，再调用熔断器的 Reset() 强制切回 closed。
- 不要在 timer 里调
cb.Allow()—— 这会误触发半开流程，导致真实业务请求被拦截 - 可以监听
OnStateChange回调，当状态变 open 时启动探测 goroutine，每次探测后根据 HTTP status / latency 决定是否调cb.Reset() - 探测路径建议用轻量 endpoint（如
/health），避免和主业务共用连接池或重试逻辑
resilience-go 与 gobreaker 在半开实现上的关键差异
两者都遵循 Netflix Hystrix 半开语义，但 resilience-go 的 circuitbreaker.CBStateHalfOpen 更严格：它要求你显式调用 cb.HalfOpen() 才能进入，而 gobreaker 是被动触发。这意味着用 resilience-go 时，你几乎必须自己管理状态切换时机。
容易踩的坑：
- resilience-go 的
WithSamplingInterval不影响半开，只影响指标采样；别指望靠它“自动探测” - gobreaker 的
Timeout是时间窗口，resilience-go 的Timeout是状态保持时长，单位一致但语义略有偏移 - 两者对并发探测的处理一致：只允一个请求通过，但 resilience-go 在请求 panic 时会自动 fallback 到 open，gobreaker 需手动 recover
半开不是银弹，它依赖下游服务的真实响应行为。如果探测请求发出去了但对方 TCP 握手就超时、或者中间 LB 直接 503，那这个“成功”就是假阳性——最终还是得靠日志和 metric 交叉验证。
