后端 BFF 层怎么做接口聚合与数据裁剪

结论：BFF（Backend for Frontend，为前端定制的后端聚合层）的核心职责只有两件事——把一次页面渲染需要的 N 个下游接口并发聚合成 1 个响应，并按调用方（App / PC / 小程序）裁剪出刚好够用的字段。聚合的关键是「并发发起 + 独立超时 + 部分失败可降级」，裁剪的关键是「字段白名单 + DTO 显式转换」，而不是把下游返回的原始 JSON 直接透传。

BFF 的接口聚合怎么做才不拖慢响应？

结论：聚合层必须并发调用下游，任何串行 await 都会把响应时间变成下游耗时之和。假设一个详情页需要用户、订单、商品、优惠券 4 个服务的数据，每个 P99 是 150ms，串行最坏 600ms，并发最坏只取决于最慢的那个。落地做法：

1. 用并发原语一次性发起：Node.js 用 Promise.allSettled，Java 用 CompletableFuture.allOf，Go 用 errgroup.Group + context.WithTimeout。
2. 每个下游单独设超时，建议值 200ms；整个 BFF 接口的总超时设 500ms，超过就返回已拿到的部分数据。
3. 用信号量限制单实例并发度（如 8~32），避免下游抖动时把 BFF 线程池打满。
4. 对同一请求内重复出现的实体做 Request 级缓存（Request Scope Cache），消除 N+1 调用；跨请求的短 TTL 缓存设 1~3 秒即可，太长会读到脏数据。

Promise.all 和 Promise.allSettled 的区别是前者有一个失败就整体 reject，聚合场景应该用 allSettled，这样才能做降级。

一个下游挂了，整个接口要报 500 吗？

结论：不要。BFF 应该返回 200 + 业务错误字段，让前端决定哪块 UI 降级。推荐响应体形如：

{
  "data": { "user": {...}, "order": null },
  "errors": [{ "service": "order", "code": "TIMEOUT", "retryable": true }]
}

这样商品和用户信息照常渲染，只有订单模块显示「加载失败，点击重试」。只有核心依赖（比如登录态校验）失败时才返回 401/500。同时打点记录每个下游的错误率和耗时，方便定位是哪一段拖慢了首屏。

数据裁剪应该在哪一层做？

结论：在 BFF 做，且必须用「显式 DTO 转换」，禁止直接返回下游原始对象。下游服务通常按最全场景设计字段，一个商品对象可能有 40 个字段，而列表页只需要 8 个：id、标题、主图、价格、销量、标签、店铺名、是否包邮。透传的后果是 payload 膨胀、内部字段（成本价、风控标记、内部状态码）泄露。

具体做法：

• 字段白名单：为每个端、每个页面定义一个输出 Schema，只声明允许出现的字段，新增字段必须显式加进去。
• 按端拆分：App 列表接口只回 8 个字段，PC 详情页回 20 个，小程序再单独一套；不要用一个接口靠 ?full=true 硬撑。
• 格式归一：金额由「分」转「元」并统一两位小数，时间统一为 ISO 8601 字符串，枚举转成前端可直接映射的字符串。
• 脱敏与去空：手机号中间四位打码，内部 id 用 HashID 替换自增主键，null 字段要么填默认值要么直接删除，减少前端判空逻辑。

哪些逻辑不该写进 BFF？

结论：BFF 只做「编排 + 裁剪 + 适配」，不写业务规则。判断标准很简单：如果这段逻辑改了会影响多个端的数据正确性，它属于下游领域服务；如果只影响某个端的展示形态，它属于 BFF。常见越界：在 BFF 算优惠券叠加、算库存扣减、改订单状态——一旦越界，就会和下游产生双份实现，后续改规则必然漏改一处。BFF 允许写的是：字段改名、单位换算、多接口结果拼装、分页参数适配、默认值填充。

怎么验证聚合和裁剪做对了？

结论：用「接口字段数 + payload 体积 + P99 耗时」三个指标验收。上线前对比裁剪前后：字段数从 40 降到 12、单次响应体积从 380KB 降到 90KB、首屏 P99 从 620ms 降到 230ms，是这类改造的典型收益区间。压测时重点造两种场景：一个下游超时 200ms 以上、一个下游返回 500，确认接口仍能返回 200 且 errors 数组正确。

整套逻辑收束成一句话：聚合靠并发和独立超时把耗时压到最慢下游的水平，裁剪靠白名单 DTO 把字段压到页面真正需要的数量，失败靠弹性降级保住可用性，而业务规则始终留在下游服务里。