真降级是基于状态的熔断决策，需Redis存储健康状态与失败计数、滑动窗口统计、异步判断失败率、客户端中间件拦截、Redis故障时保守兜底、按业务语义设计fallback并标注响应头。
服务降级不是加开关，而是有状态的熔断决策
PHP 本身没有原生熔断器，直接用 if ($flag) { return mock(); } 是伪降级——它无法感知下游故障、不自动恢复、不统计失败率。真降级必须结合状态存储（如 Redis）+ 失败计数 + 时间窗口，否则一出问题就得人工改代码上线。
- 用
Redis存储服务健康状态和最近 60 秒的失败次数，键建议用"svc:order:health"和"svc:order:failures:202405201430"这类带服务名和时间片的格式 - 每次调用下游前，先查
GET svc:order:health；若返回"down"，直接走本地缓存或默认值，跳过远程请求 - 调用失败时，用
INCR+EXPIRE维护滑动窗口：比如INCR svc:order:failures:202405201430并设 60 秒过期 - 每 10 秒起一个异步脚本（或由主请求触发），检查当前窗口失败率是否 > 50%，是则
SET svc:order:health "down"，并记录日志
用 Guzzle + 中间件实现请求级自动降级
别在业务逻辑里写一堆 if (isHealthy())，把降级判断下沉到 HTTP 客户端层更干净。Guzzle 支持中间件，可以拦截请求前检查状态、失败后触发 fallback。
- 写一个
DowngradeMiddleware类，在__invoke()中读Redis::get("svc:payment:health") - 若为
"down"，不发请求，直接构造Response返回预设的fallback_data（如空数组或兜底价格） - 若发请求后返回
5xx或超时，在onRejected回调里执行Redis::incr("svc:payment:failures:...") - 注意：不要在中间件里做重试，重试和降级语义冲突；降级一旦生效，就该跳过整个链路
Redis 故障时降级逻辑不能雪崩
依赖 Redis 做状态判断，但 Redis 挂了怎么办？这时候如果还死等 GET 返回，所有请求都会卡住或报错。必须有兜底策略。
- 用
Redis::get()前加try/catch，捕获RedisException或连接超时 - 兜底行为不是“忽略降级”，而是“保守降级”：当 Redis 不可用时，默认认为服务不健康，走 fallback，而不是强行调用下游
- 同时记录告警日志，比如
"redis_unavailable_fallback_activated"，方便后续定位是不是缓存层出了问题 - 避免用
file_get_contents("/tmp/health.flag")这类本地文件做兜底——多实例部署下状态不同步，反而引发一致性问题
降级≠返回空，要区分场景给合理 fallback
用户下单页的「支付方式」接口降级，返回空数组会让前端白屏；商品详情页的「推荐商品」接口降级，返回空反而更安全。fallback 设计必须贴业务语义。
立即学习“PHP免费学习笔记（深入）”；
- 核心链路（如库存扣减、订单创建）降级应抛异常或返回明确错误码（如
503 Service Unavailable），禁止静默 fallback - 非核心链路（如用户标签、营销弹窗）可返回预生成的静态数据，比如从
json_decode(file_get_contents(__DIR__.'/fallback/recommend.json')) - 对时效敏感的数据（如秒杀倒计时），fallback 必须带时间戳，前端据此判断是否接受旧数据，避免用过期信息误导用户
- 所有 fallback 数据建议加
X-Fallback: true响应头，便于监控识别哪些流量走了降级路径
真正难的不是写几行降级代码，而是定义清楚每个接口的 SLO、失败容忍度、fallback 合理性——这些没法靠工具自动解决，得和产品、前端、测试一起对齐。否则降级开着，用户却以为功能坏了。
