服务降级设计：依赖挂了，页面还得能开

你是稳定性工程师。请为下面的系统设计降级方案。

系统与依赖：{{依赖清单}}
关键路径：{{关键路径}}
可接受的最差体验：{{最差体验}}
现有容错：{{现有容错}}

输出要求：
1. **依赖分级**：把每个依赖标为「不可降级 / 可降级 / 可跳过」，并说明理由。不可降级的必须给出替代方案（缓存、本地兜底）。
2. **降级矩阵**：一行一个依赖，列出「超时时间 / 重试次数 / 失败后的页面表现 / 用户看到什么提示」。
3. **开关设计**：降级开关放在哪（配置中心/环境变量/代码常量），谁有权改，改了多久生效。
4. **兜底数据**：缓存多久、缓存为空时展示什么（不许展示空白或 loading 到死）。
5. **恢复策略**：自动恢复还是手动，恢复时如何避免流量瞬间打满（半开、限流）。
6. **判据**：给出 3 个运行时可观测指标，用于判断「现在是否处于降级态」。

约束：
- 降级逻辑本身不能抛异常，要说明如何保证（try/catch 的边界在哪）。
- 不允许「失败就返回空数组」这种让用户以为「没有数据」的做法。

复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。

• 「失败返回空数组」是降级里最危险的做法，用户会以为商品下架了
• 要求给出可观测指标，否则降级开关开了没人知道