go-kit/circuitbreaker 默认不生效是因为必须手动调用 Execute 并传入 reqFn（返回 error 才计失败）、fallbackFn，且状态更新依赖此调用；不包裹请求逻辑则始终处于 StateClosed。
go-kit/circuitbreaker 为什么默认不生效
直接用 go-kit/circuitbreaker 包的 NewCircuitBreaker 构造器，但服务出错时熔断器始终不打开——问题大概率出在状态更新机制上。它本身不自动监控下游调用结果，必须手动调用 Execute 并传入成功/失败回调，否则状态永远卡在 StateClosed。
- 必须用
cb.Execute(ctx, reqFn, fallbackFn)包裹实际请求逻辑，不能只初始化后就丢着不管 -
reqFn返回error才会触发失败计数；返回nil或非错误值（比如空结构体）不会影响状态 - 默认失败阈值是 5 次，1 分钟窗口，但窗口时间由
clock参数控制；若没传自定义clock，它用的是系统时钟，测试时容易因时间跳变导致统计失效 - fallback 函数只在熔断开启后被调用，
reqFn在半开状态下仍会执行，失败则重置为关闭态
hystrix-go 的 panic 和 context 超时冲突
hystrix.Go 内部用 goroutine 启动请求，但它的超时处理和 context.Context 不兼容：即使你传了带 deadline 的 ctx，hystrix.Go 仍按自己配置的 Timeout 字段中断，且中断时会直接 panic，不是返回 error。
- 不要在
hystrix.Go外层再套ctx.Done()select 判断，panic 会绕过 defer 和 channel 关闭逻辑 - 如果必须用 context 控制生命周期，改用
hystrix.Do（同步阻塞版），它支持传入context.Context，并在超时时返回context.DeadlineExceeded -
hystrix.ConfigureCommand设置的Timeout单位是毫秒，而context.WithTimeout是纳秒级，数值对不上容易误判超时归属 - 命令名（command name）必须全局唯一，否则多个接口共用同一 name 会导致熔断统计串扰
自研简单熔断器的关键状态转移条件
不用第三方库时，核心是三个状态（Closed/Open/HalfOpen）之间的切换逻辑是否严格满足时间窗口、失败率、恢复探测要求。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Open→HalfOpen必须依赖定时器，不能靠首次请求触发；否则高并发下大量请求同时撞进半开态，压垮下游 - 失败率计算要用滑动窗口（如环形缓冲区），不是固定周期清零；否则凌晨低流量时段一次失败就触发熔断，白天流量上来又立刻打满
-
HalfOpen状态下只允许一个请求通过，其余全部快速失败（return error），否则起不到试探作用 - 所有状态读写必须加
sync.RWMutex，尤其GetState这类高频读操作，别为了省锁用原子变量模拟状态机——状态不止 true/false，还有时间戳和计数器
gobreaker 里 OnStateChange 回调的副作用风险
gobreaker 的 OnStateChange 是个纯通知回调，但它运行在状态变更的临界区里。如果在里面做 HTTP 上报、日志写盘或调用其他可能阻塞/失败的逻辑，会拖慢整个熔断器状态更新，甚至导致 goroutine 积压。
立即学习“go语言免费学习笔记（深入）”；
- 回调里禁止调用任何可能阻塞的函数，包括
http.Post、log.Printf（若 log 输出到文件且磁盘慢）、time.Sleep - 推荐只做内存标记（如原子写入一个
int64计数器）或发消息到预分配的无锁 channel，后续由单独 goroutine 消费 - 该回调接收旧状态和新状态两个参数，但注意：从
Closed→Open时，新状态已生效，此时再修改配置（比如动态调低失败阈值）不会影响本次熔断决策 - 如果用 Prometheus 暴露指标，别在回调里直接
counter.Inc()，应先写入本地统计变量，再由采集 goroutine 定期同步到指标对象
真正难的不是实现状态切换，而是让失败率统计不被突发流量污染，也不被长尾延迟扭曲。多数线上问题都出在窗口时间和采样精度没对齐业务 SLA。
