先说一个核心判断：Composer本身不提供服务网格能力，也不内置熔断降级逻辑——它只是依赖管理工具。所谓“基于Composer构建服务网格”，本质是用Composer安装和组织那些真正实现熔断、降级、通信的PHP库，再通过代码集成形成网格行为。
composer require 装的是什么？不是熔断器，而是熔断器的载体
执行 composer require hyperf/circuit-breaker 或 composer require mix/micro-hystrix，装进去的并不是开箱即用的“服务网格”，而是一个可编程的熔断组件。它不会自动拦截所有HTTP请求，也不会自己发现服务实例或路由流量。
- Hyperf 的
hyperf/circuit-breaker依赖PsrSimpleCache接口，你得自己给它绑定一个Redis或者ArrayCache来实现状态持久化；缺了缓存驱动，isOpen()永远返回false - Mix Micro Hystrix 的
CircuitBreaker::do()必须显式包裹业务调用，不加这层包装，熔断逻辑根本不生效 - 所有这类库都不修改PHP的autoloader或请求生命周期——它们只在你调用的时候才起作用
为什么不能直接在 composer.json 里配“全局熔断”？
因为Composer压根不参与运行时控制。它的 autoload、scripts、repositories 都只在安装或更新阶段执行。想让每个Guzzle请求都自动走熔断，就得自己封装HTTP客户端，或者用AOP（比如 goaop/framework）织入逻辑——这一步，Composer只负责帮你装好GoAOP和熔断器，不会替你写一行拦截代码。
- 常见误操作：
"scripts": {"post-autoload-dump": "php bin/circuit-init.php"}——这个脚本只在dump-autoload时跑一次，它根本没法维护运行时状态 - 真正的状态（失败计数、时间窗口、半开探测）必须放在进程内（Swoole）或外部存储（Redis），并且每次请求都得触发更新
- 如果用FPM，每次请求都是新进程，除非借助Redis，否则计数器没法跨请求累积，熔断基本形同虚设
Hyperf + circuit-breaker 的最小可行集成要点
Hyperf是目前PHP生态里对服务网格支持最直接的框架，但即便如此，还是需要手动串联几个关键点，熔断才能“动起来”。看一个实操场景：
- 安装后必须发布配置：
php bin/hyperf.php vendor:publish hyperf/circuit-breaker，否则circuit_breaker.php配置文件不会自动生成 - 配置文件里的
default策略只对HyperfCircuitBreakerAnnotationCircuitBreaker注解生效；没加注解的方法，哪怕用了HttpClient，也不受控制 - 如果要对Guzzle实例统一加熔断，得继承
GuzzleHttpClient，在request()方法里调用CircuitBreaker::call()，并传入唯一$name标识下游服务 - 特别注意
sleepWindow的单位：Hyperf默认是毫秒（60000），而Mix Hystrix是秒（默认10）——混用时很容易误设成10毫秒，导致刚熔断就立刻进入半开状态
降级逻辑不是自动 fallback，而是你写的那个 _demotion 方法
像 clevephp/la-limiting 这类库，声明一个 index_demotion() 就能触发降级，看起来很像自动化的魔法。但它背后依赖的是运行时方法名反射加命名约定，既不是语言特性，也不兼容PSR-4自动加载规则。
- 如果控制器类用了trait引入方法，
_demotion后缀方法可能找不到——PHP不会自动从trait中匹配命名 - Hyperf的
@CircuitBreaker(fallback="fallbackMethod")要求fallbackMethod是同一个类中的public方法，且签名必须完全一致（包括参数类型和数量） - 最容易忽略的一点：fallback方法里不能再次调用同一个熔断器保护的下游服务，否则很可能陷入嵌套熔断或死循环
说到底，真正难的地方从来不是装哪个包，而是把状态存在哪里、谁来负责重置计数、半开探测怎么选请求、降级数据要不要做缓存——这些决策靠 composer install 解决不了，只能靠你在代码里写清楚。
