BFF 层的缓存边界应该画在哪里
· 阅读需 2 分钟
2021 年很多团队开始把 BFF 当成前后端之间的稳定缓冲层，但一旦请求量上来，BFF 很快就会遇到一个现实问题: 要不要在这一层加缓存。
我觉得真正难的不是“加不加 Redis”，而是先想清楚缓存边界。边界没想清楚，BFF 反而会同时承担聚合、缓存、兜底和状态拼装，最后越来越重。
先判断缓存的对象是不是聚合结果
如果某个页面要同时请求用户信息、订单摘要和推荐内容，BFF 直接缓存聚合后的响应，能明显减少前端多次命中后端的成本。
但前提是这个聚合结果本身足够稳定。如果聚合里夹着强实时数据，比如余额或库存，整包缓存就会带来明显一致性问题。
细粒度数据更适合在下游缓存
我更倾向于把“纯资源型、复用面广”的缓存留在下游服务或数据访问层，比如商品详情、地区列表、配置表这类内容。
BFF 更适合缓存那些明显围绕页面形态组织过的结果，因为这些内容本来就是为了前端消费而存在的。
不要让缓存策略跟页面逻辑缠死
一个常见问题是，BFF 为了兼容页面细节，在缓存 key 里拼入大量展示层参数。短期看似灵活，长期会带来:
- key 数量爆炸
- 命中率很低
- 页面改版就要重写缓存逻辑
更稳的方式是先把聚合接口抽成少数稳定场景，再考虑缓存它们。
失效策略比存储介质更重要
很多人一提缓存，第一反应是选 Redis 还是内存。但在 BFF 层，失效策略通常比介质更关键。因为你真正要回答的问题是:
- 什么时候主动删
- 什么时候允许短暂过期
- 出现异常时返回旧值还是直接失败
这些问题不先想清楚，缓存命中率再高也可能把错误结果稳定地放大出去。
小结
BFF 缓存最怕的不是没加，而是边界含糊。把可缓存的聚合结果和必须实时透传的数据先拆开，BFF 才能既减压，又不把一致性风险一起吞进去。