BFF 降级与回退策略检查清单

做 BFF 的时候，最容易被忽视的一点是: 你聚合得越多，单个接口的失败面就越大。一个页面接口背后挂了三四个服务，任何一个超时都可能把整页拖慢。

所以我在 2021 年越来越习惯先问一句: 这个聚合接口里，哪些数据失败了还能降级，哪些数据必须强依赖。

先区分核心数据和装饰性数据

不是每个依赖都值得“陪葬”。比如:

• 用户身份和权限信息通常属于核心数据
• 推荐内容、营销卡片、活动角标往往可以降级

只有先把这两类数据分开，BFF 才能设计出有意义的回退策略。

降级不只是返回空

很多团队提降级，第一反应就是“失败了返回空数组”。这当然是一种办法，但不一定总是最好的。更实用的思路往往包括:

• 返回上一次成功缓存
• 用更便宜的兜底接口替代
• 只返回核心模块，其余模块明确标记不可用

这样前端可以给出更真实的页面反馈，而不是默默吞掉问题。

超时策略要按依赖重要性区分

如果所有下游依赖都用同一个超时设置，结果通常是要么过于保守，要么过于激进。更稳的办法是:

• 核心链路给出相对明确的等待预算
• 非核心依赖更快超时，优先走降级

这样聚合接口整体的响应时间会更可控。

降级结果也要进监控

有些系统表面上“没报错”，其实一直在静默降级。用户看到的是少了几个模块，团队却可能半天后才发现。

所以 BFF 的降级命中率、回退次数和缓存兜底次数，最好都进入监控面板。否则你只是把失败从报错改成了不可见。

小结

BFF 的降级策略，本质上是在回答“部分失败时还能不能提供一个可用页面”。把核心依赖、非核心依赖和兜底路径先梳理出来，聚合层才算真正具备上线价值。