Hyperf中@CircuitBreaker注解仅对RPC客户端接口方法生效，需联动service-governance、load-balancer和circuit-breaker三组件，且fallback类须无参构造、签名一致并由容器管理。
Hyperf 默认不带熔断能力，装了 hyperf/circuit-breaker 也不等于能自动熔断——它必须和服务治理、负载均衡、标准 RPC 客户端三者联动才起作用。
为什么 @CircuitBreaker 注解在 Controller 里完全无效
这个注解只对实现 ClientInterface 的 RPC 接口方法生效，不是给 HTTP 入口用的。比如你写在 UserController 的方法上，框架根本不会拦截、不会统计失败次数、也不会跳 fallback 类。
- 真正生效的位置是 Consumer 端定义的接口，例如：
UserServiceInterface::getUser() -
@CircuitBreaker必须配合hyperf/rpc-client或hyperf/guzzle标准客户端调用，不能用原生curl或file_get_contents - 常见报错
Call to undefined method ...::getFallback()，基本就是 fallback 类没注册、或注解加错了位置
熔断器启用前必须配齐的三个组件
缺一不可，否则配置再全也白搭：
-
hyperf/service-governance（如hyperf/service-governance-nacos）：用于感知下游服务实例是否健康，ephemeral建议设为true，否则 Nacos 不会主动剔除宕机节点 -
hyperf/load-balancer：熔断器依赖它提供的Node管理和故障计数能力，没它就无法区分「哪个实例挂了」 -
hyperf/circuit-breaker：仅提供状态机和存储逻辑，本身不触发任何行为，纯被动组件
配置文件 config/autoload/services.php 中需显式启用 enable => true，且 drivers 下必须有对应治理驱动。
circuit-breaker 配置项怎么设才不踩坑
默认值容易误导人，生产环境必须按实际调用链路调整：
-
failure_threshold：不是「任意 5 次失败」，而是「连续失败 5 次」，网络超时和业务异常要分开看；若混用限流异常（如RateLimitException），会误判服务不可用 -
sleep_duration（即sleep_window）：建议设为下游平均恢复时间（MTTR），太短会反复试探，太长影响可用性；跨中心部署建议 ≥30s -
storage：推荐用RedisStorage，避免单机内存状态丢失；别用默认的ArrayStorage，重启后熔断状态清零 -
stat_window：统计窗口期，默认 60 秒，若下游 RT 波动大（如跨 VPC 达 80ms），建议拉长到 120 秒，避免抖动误触发
fallback 类必须满足的硬性条件
它不是随便写个类就能当降级入口，框架有严格校验：
- 必须是独立类，不能是匿名类或闭包
- 构造函数必须无参，否则
make()会失败 - 方法签名要和原接口完全一致，包括返回类型（PHP 8+ 类型声明不能省）
- 类名需在注解中显式指定，例如：
@CircuitBreaker(fallback="App\Fallback\UserFallback::class")
最容易被忽略的是：fallback 类的生命周期由容器管理，但它的实例化发生在熔断打开后首次降级时——如果类里依赖了未初始化的组件（比如未注入的 LoggerInterface），会直接抛出异常，导致降级失败。
