高并发下「降级」的边界到底怎么画：空态、旧数据还是部分砍？

【背景】 社区这阵子聊限流、熔断、超时、并发模型都很热闹，但我发现「降级」这个词大家挂在嘴边，真要画边界时却最含糊。上个月我帮一个支付聚合接口做容量评审，QPS 6000，核心依赖两个下游：风控（P99 平时 40ms，抖动能到 800ms）和营销券计算（P99 稳定但偶发 1.5s）。预案里写的是「下游超时则降级」，可到底降成什么样？评审会吵了 40 分钟没结论。我把它拆开看，分歧根本不在「要不要降」，而在三个更具体的问题上。

【三种典型分歧】 1）触发信号选哪个。有人盯 RT（P99 超阈值就降），有人盯错误率（5xx/超时占比），有人盯下游饱和度（CPU / 队列 / 连接池水位）。我用过的教训是——RT 阈值最容易被「正常抖动」打穿，错误率最迟钝（等它涨上来往往已经雪崩一半），饱和度最准但最难拿到（下游不暴露指标就只能瞎猜）。 2）降成什么。空态/兜底文案（最安全但伤体验）、返回缓存旧数据（体验好但有脏数据风险）、部分降级只砍非核心字段（逻辑最复杂）。我见过因为「返回旧券金额」被用户投诉资损的，也见过「全降级成空」直接掉转化的。 3）谁来决策、多久恢复。硬编码阈值（简单但僵）、自适应（Concurrent Limiter / 半开探测，灵活但难预测）、人工一键（兜底但慢）。恢复策略更是重灾区——熔断容易，「什么时候敢放回来」几乎没人算过账。

【我的倾向与理由】 如果只让我给一条默认策略，我会选：触发用「下游饱和度 + RT 分位数」双信号（单 RT 不可靠、纯错误率太迟），降级优先「部分降级 + 缓存兜底」而不是「一刀切空态」，恢复走半开探测且恢复窗口要按下游实际 RT 动态放大。理由：降级的本质不是「少干活」，而是「在下游过载时，用可接受的体验损失换整体不雪崩」——它是个体验 / 资损 / 可用性的三角权衡，不是一个开关。

【想听大家怎么选】 特别想听三种场景下的真实取舍：① 强一致性场景（支付/库存）你宁可让用户等还是宁可拒单/降级？② 弱一致但高转化场景（营销/推荐）你的兜底旧数据敢放多久？③ 下游不暴露饱和度指标时，你们实际拿什么当触发信号？欢迎贴你们的阈值、恢复窗口和踩过的坑。