服务降级核心是可靠感知依赖不可用，而非简单if判断；需通过强制超时、异常捕获、预加载兜底数据及避免依赖故障源来实现。
服务降级不是加个 if 判断就完事
PHP 里做服务降级，核心不是“怎么返回默认值”，而是“怎么可靠地感知依赖已不可用”。硬写 if ($service->isHealthy() === false) 几乎没用——健康检查本身可能超时、失败，或根本没实现。真正要解决的是：当 curl_exec 卡住、Redis::get 报 Connection refused、mysqli_query 超过 200ms 还没返回时，你能否在用户感知前切到兜底逻辑。
用超时 + 异常捕获代替健康检查
PHP 没有原生熔断器，但你可以用最朴素的方式守住底线：强制超时 + 统一异常处理。关键不是避免报错，而是让错误发生得快、可预期、可拦截。
-
cURL必须设CURLOPT_TIMEOUT_MS（别只用CURLOPT_TIMEOUT），500ms 是多数 HTTP 依赖的合理上限 -
Redis客户端要开connect_timeout和read_timeout，例如 Predis 配置['scheme' => 'tcp', 'host' => 'x', 'port' => 6379, 'timeout' => 0.3, 'read_write_timeout' => 0.3] - 所有数据库操作包裹
try/catch，捕获PDOException、RedisException、RuntimeException（cURL 失败常抛这个） - 兜底数据不能从同一个故障源读——比如 Redis 挂了，别再试图从 Redis 读缓存的兜底值
兜底数据必须预加载或本地化
降级时再去查文件、读 $_ENV、甚至调另一个微服务，等于把单点故障扩散成雪崩。兜底值要么启动时载入内存，要么硬编码在代码里（适用于变化极低的场景，如「系统维护中」文案），要么存在本地 /tmp/fallback.json 这类不依赖网络的路径。
示例：HTTP 请求失败后返回预存结构
立即学习“PHP免费学习笔记（深入）”；
$fallback = [
'status' => 'degraded',
'data' => ['items' => []],
'meta' => ['updated_at' => '2024-01-01T00:00:00Z']
];
// 注意：不要在这里 fopen('/tmp/fallback.json') —— 文件 I/O 也可能失败
别忽略 PHP-FPM 的子进程生命周期影响
兜底数据如果存在静态变量里（static $fallbackCache = null），在 PHP-FPM 下每次请求都是干净的——你没法靠它跨请求缓存兜底结果。想复用兜底响应，得用 apcu_store() 或写临时文件，但要注意：apcu 在 opcache 启用且 apc.enable_cli=0 时，CLI 模式下不可用；而 FPM 子进程重启后，apcu 数据全丢。所以兜底逻辑里别假设「上次降级成功，这次肯定还有缓存」。
复杂点在于：降级开关本身也需要持久化。用 Redis 存开关？那 Redis 挂了你怎么知道该不该降级？真要可靠，只能靠部署侧配置文件 + 信号量文件（如 touch /tmp/service_x_degraded），PHP 只读不写。
