thinkphp需自建轻量熔断器，核心是失败次数+时间窗口+状态快照三要素；用带ttl的cache存状态与计数，半开态靠单次探测请求验证，仅对网络错误及5xx计数，恢复后须清空计数。
ThinkPHP接口调用失败后怎么自动暂停重试？
靠手动加计数器或全局状态变量很容易漏掉边界情况，也难复用。ThinkPHP本身不内置熔断器，得自己搭轻量级开关——核心是「记录失败次数 + 时间窗口 + 状态快照」三要素缺一不可。
常见错误现象：curl_exec超时或返回空，但代码仍继续发请求，下游服务雪崩；或者用了cache存失败次数，却没设过期时间，导致永久熔断。
- 用
Cache::get('api_circuit_breaker_status')读状态，必须搭配Cache::set('api_circuit_breaker_status', 'open', 60)设 60 秒超时，不能只存不删 - 失败计数建议存在
cache而非session，避免用户维度干扰，且要带前缀如'cb_api_v2_payment_failcount' - 每次调用前先查状态：
if (Cache::get('cb_api_v2_payment') === 'open') { throw new Exception('Circuit breaker open'); }
如何判断该从“熔断”切回“半开”状态？
半开不是定时器一到就自动切，而是得有主动探测机制：在熔断期结束后，允许**一个**试探性请求通过，成功则恢复，失败则重置熔断计时器。
使用场景：支付回调、短信网关、第三方登录授权等对稳定性敏感的出站调用。
- 不要用
time() % 60 === 0这类伪随机方式触发试探，容易误判；应严格按上次熔断开始时间 + 熔断时长来计算是否进入半开窗口 - 试探请求必须走同一套逻辑（含超时、重试、签名），否则测了等于没测
- 半开期间若
curl_error或HTTP状态码非200，立刻写回Cache::set('cb_api_v2_payment', 'open', 120)，延长熔断时间
为什么用Cache比用Config或Env更合适？
Config和Env是启动时加载的静态配置，无法动态反映运行时状态；而熔断本质是运行时决策，必须可读可写、带 TTL、跨进程可见。
性能影响：Redis 缓存比文件缓存快 5–10 倍，尤其在高并发下；若用File驱动，多个请求同时写同一个缓存文件可能引发锁竞争。
- 务必确认当前缓存驱动支持原子操作，比如
Redis::incr()比Cache::get() + Cache::set()更安全 - 避免用
Config::set()临时改配置来模拟开关——它不持久、不跨请求、不带过期，纯属误导 - 如果项目禁用 Redis，至少用
Memcached，别退化到File，否则并发下failcount会严重不准
连续失败多少次才该熔断？这个阈值怎么定？
没有通用数字。3 次太激进，10 次又太迟钝。得结合接口 SLA 和历史错误率来反推：比如该接口 P95 响应时间是 800ms，你设了 1s 超时，过去一小时失败率是 2%，那阈值就该设为「5 分钟内失败 6 次」（≈2% × 5×60）。
容易踩的坑：把所有异常都当熔断依据。比如401 Unauthorized是业务问题，不该触发熔断；而curl error 7（无法连接）或503 Service Unavailable才是基础设施层故障，才该计数。
- 只对网络层错误和 5xx 响应码做失败计数，跳过 4xx（除
429） - 每次失败后，用
Cache::inc('cb_api_v2_payment_failcount')自增，比get+set少一次IO - 阈值建议写死在配置里，如
config('circuit.breaker.max_failures')，别硬编码在逻辑里
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
