熔断器不会自动恢复是因为其设计要求显式探测下游状态，必须通过半开状态与探测请求闭环实现；gobreaker需配置timeout和readytotrip才能触发半开，且探测请求须隔离超时、正确反馈结果并保证并发安全。
熔断器为什么不会自动恢复？
Go 语言里用 gobreaker 或自建熔断器时，常见问题是：触发熔断后服务一直卡在 StateOpen，哪怕下游已恢复正常，调用仍持续失败。这不是 bug，而是设计使然——熔断器默认不“猜”下游是否恢复，必须显式设置恢复机制。
核心原因在于：熔断器的 onStateChange 回调只通知状态变更，不主动探测；ReadyToTrip 函数只决定“该不该熔断”，不管“该不该关闸”。自动恢复必须靠“半开 + 探测请求”闭环实现。
gobreaker 中启用半开状态与探测逻辑
gobreaker 默认支持半开（StateHalfOpen），但需配置 Timeout 和 ReadyToTrip 才能触发。关键点是：熔断超时后，下一次调用会进入半开，此时仅允许一个请求通过，其余直接拒绝或排队（取决于实现）。
-
Timeout：必须设为合理值（如30 * time.Second），这是从StateOpen切换到StateHalfOpen的等待时间 -
ReadyToTrip：建议用错误率+连续失败数双条件，例如“最近 10 次调用错误 ≥ 5 次”，避免偶发抖动误熔断 - 半开期间的单次探测请求必须有独立超时（短于主调用超时），否则会拖慢整个恢复流程
示例配置：
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service",
Timeout: 30 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 5 ||
float64(counts.TotalFailures)/float64(counts.TotalRequests) > 0.5
},
})
手动触发探测请求容易踩的坑
很多实现会在半开状态下“偷偷发一个健康检查请求”，但这极易出错：
- 探测请求和业务请求共用同一 client，若 client 本身带重试逻辑，一次探测可能变成多次调用，直接打穿半开窗口
- 没隔离上下文（
context.WithTimeout），探测卡住会阻塞后续所有请求 - 忽略探测结果处理：成功后要调用
cb.OnSuccess()，失败则必须调用cb.OnFailure()，否则状态机无法推进 - 并发场景下多个 goroutine 同时进入半开，可能同时发起探测，破坏“只放行一次”的语义
正确做法是：在 cb.Execute 失败且状态为 StateOpen 时，不额外发探测；等 Timeout 到，让 gobreaker 自动进半开，再由它调度唯一一次探测请求。
自定义熔断器中实现自动恢复的关键节点
如果不用 gobreaker，自己基于 sync/atomic 实现，必须在三个地方硬编码恢复逻辑：
- 状态切换定时器：用
time.AfterFunc在StateOpen启动后延时触发setState(StateHalfOpen) - 半开计数器：用原子变量记录“当前半开窗口内已放行请求数”，只允许 1 次，且需配合互斥锁防竞态
- 结果反馈路径：无论探测请求成功或失败，都必须同步更新内部计数器，并根据结果决定是回到
StateClosed还是重置回StateOpen
特别注意：StateHalfOpen 不是稳定态，它必须是瞬时的——要么 1 秒内成功并切闭合，要么失败立即回开。长时间停留在半开，说明探测逻辑没走通或没反馈。
真正难的不是写几行代码切状态，而是确保探测请求的语义干净、反馈及时、并发安全。线上环境里，一次探测失败可能被重试三次，这三次都得算进熔断统计，否则恢复就失效了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
