断路器需用状态机实现，包含closed、open、half_open三状态及严格转换规则；须用枚举定义状态、字典映射事件与目标状态、统一transition入口、显式处理超时与并发锁，避免if-else硬编码和timer不可靠问题。
状态机必须显式定义所有转换，不能靠 if-else 堆出来
断路器不是“开了关了”两个状态的事，closed、open、half_open 之间有严格触发条件和超时约束。用一堆 if state == 'closed': ... elif ... 写，很快就会漏掉重试失败后该回 open 还是回 closed 的分支，更别说并发下状态竞态。
实操建议：
- 用枚举类
CircuitState固定三个状态值，禁止字符串硬编码 - 每个状态的「可接受事件」和「目标状态」写成字典映射，比如
{CircuitState.CLOSED: {'failure': CircuitState.OPEN, 'success': CircuitState.CLOSED}} - 状态变更必须走统一入口
transition(event)，里面做原子更新 + 超时检查（比如open状态要记录opened_at时间）
half_open 状态不自动降级，得靠定时器或首次调用触发
很多人以为设了 reset_timeout=60，断路器就会在 60 秒后“自动”切到 half_open——不会。Python 没有后台线程帮你守着这个时间点。等超时、切状态、允许一次试探调用，这三步得你明确安排。
常见错误现象：open 状态卡死，永远等不来 half_open，下游服务明明恢复了也持续熔断。
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 不要依赖“时间到了就变”，改为「首次请求进入
open状态时记录opened_at，每次调用call()前先检查是否超时，超时则转half_open」 - 或者用
threading.Timer启一个延迟任务，但注意：Timer 不可靠（进程退出、GIL 阻塞都可能让它失效），生产环境慎用 -
half_open下第一次调用成功，才切回closed；失败则立刻回open并重置计时
并发调用下状态读写必须加锁，但锁粒度不能太大
多个线程/协程同时调用 call()，可能同时读到 open 状态、同时判断超时、同时执行 transition('timeout_expired')，结果重复进 half_open，甚至覆盖彼此的状态变更。
性能影响明显：如果整个 call() 流程都用一把大锁，吞吐直接腰斩，尤其 closed 状态本该无阻塞。
实操建议：
- 只对「状态变更相关代码块」加锁，比如
if self._state == OPEN and now > self._opened_at + self.reset_timeout:这段判断 + 切换动作必须原子 - 读状态（如判断是否允许执行）可以不加锁，但要用
self._state这种易变属性，别缓存到局部变量里反复用 - 避免用
threading.RLock，普通threading.Lock足够，且更易发现死锁
reset_timeout 和 failure_threshold 参数意义完全不同，别混用
failure_threshold=5 是指连续失败 5 次才熔断，而 reset_timeout=60 是指熔断后至少等 60 秒才允许试探。这两个数单位不同、触发时机不同、甚至可以动态调整——但新手常把它们当同一类“阈值”去调。
容易踩的坑：
- 设
failure_threshold=1以为“一错就断”，结果网络抖动导致频繁误熔断 - 设
reset_timeout=1以为“快速恢复”，实际让half_open变成高频探测，压垮刚恢复的服务 - 没考虑成功率衰减：比如失败率从 10% 爬升到 90%，光看连续失败次数会滞后响应
真实场景中，failure_threshold 更适合配合滑动窗口（如最近 20 次失败率 > 50% 就开），而 reset_timeout 应按下游服务恢复预期时间设，比如数据库主从切换要 30 秒，那就设 45 秒留余量。
状态机里最麻烦的从来不是画那三个圆圈，而是想清楚每个箭头背后的时间、计数、并发和退化逻辑。少一个条件，线上就多一分不可控。
