熔断器状态机必须用sync/atomic原子操作管理state，禁用非原子读写；滑动窗口须“请求即更新”避免time.Tick失真；half-open需限流探测并发数并透传context。
熔断器状态机必须用原子操作控制
Go里用 sync/atomic 管理 state（closed/open/half-open）是硬性要求。直接读写结构体字段会导致竞态，尤其在高并发请求下，多个 goroutine 同时判断是否允许执行、同时触发状态跃迁，极易出现「本该打开却仍放行」或「刚半开又退回关闭」的逻辑错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
int32表示状态，atomic.LoadInt32读，atomic.CompareAndSwapInt32跃迁，避免中间态残留 - 不要用
switch state { case Closed: ... }后再做 CAS —— 这之间存在时间窗口，应先 CAS 尝试跃迁，成功后再执行对应分支逻辑 - 状态变更日志建议带上
atomic.LoadUint64(&counter)类似序列号，方便排查状态抖动
滑动窗口计数器不能依赖 time.Tick
用 time.Tick 驱动窗口滚动看似简洁，但实际会因 GC 暂停、系统负载高导致 tick 延迟甚至丢失，造成失败率统计失真。比如配置了 10 秒窗口，但某次 tick 卡了 3 秒，那这 3 秒内的请求全被漏计，熔断阈值就形同虚设。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 采用「请求即更新」模式：每次调用
RecordSuccess或RecordFailure时，先检查当前时间是否已跨出窗口左边界，动态剔除过期条目 - 底层用
[]struct{at time.Time; success bool}+ 双指针（head/tail），避免频繁 alloc；也可用环形 buffer 固定容量，牺牲精度换性能 - 若需毫秒级精度，务必用
time.Now().UnixNano()，别用UnixMilli()（Go 1.17+ 才有，旧版本不兼容）
半开状态必须限制并发探测请求数
进入 half-open 后，如果放任所有请求都去试探下游，等于没熔断。典型错误是只判断状态为 half-open 就直接执行业务函数，结果瞬间打垮刚恢复的服务。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 维护一个原子计数器
concurrentProbes，每次进入 half-open 分支前atomic.AddInt32(&c.concurrentProbes, 1)，成功后atomic.AddInt32减 1；超阈值（如 1~3）直接返回ErrCircuitOpen - 探测请求必须带超时，且超时时间应明显短于正常请求（例如正常 5s，探测设为 800ms），避免拖慢整体响应
- 失败的探测请求要计入滑动窗口，但成功的探测请求不计入成功率统计 —— 它只是「可用性快照」，不是真实业务流量
Context 传递与取消必须穿透整个熔断链路
熔断器本身不处理超时，但必须尊重上游传入的 context.Context。常见错误是封装了 Execute(func() error) 接口，却在内部另起 goroutine 执行函数，导致父 context 取消后子 goroutine 仍在跑，既浪费资源又可能引发数据竞争。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有执行入口统一为
Execute(ctx context.Context, fn func(context.Context) error) error，禁止接收无 context 的裸函数 - 在
closed状态下调用fn(ctx)，不额外启 goroutine；open和half-open状态下也必须将 ctx 透传给探测逻辑 - 若业务函数本身不支持 context（如 legacy DB driver），需在外层加
select { case 包裹，而非依赖函数内部超时
真正难的不是实现三个状态，而是让滑动窗口的边界对齐、半开探测的并发控制和 context 取消信号在任意时刻都能被正确响应 —— 这三处一旦松动，容错就变成幻觉。
