BFF 和 API 网关的边界怎么划分

BFF 和 API 网关容易混在一起，是因为它们都站在流量入口。但两者的关注点完全不同：网关偏平台治理，BFF 偏前端交付。

先说结论

• API 网关负责统一入口、协议治理、安全控制和通用流量能力
• BFF 负责面向具体终端组织数据，减少前端拼装成本
• 只要某段逻辑开始明显依赖页面、端类型和交互节奏，它更应该放在 BFF，而不是网关

核心边界

API 网关该做什么

网关适合承接所有“所有请求都可能共用”的能力，比如认证鉴权、限流熔断、路由转发、灰度发布、日志追踪、Header 注入和统一安全策略。

这些能力的特点是规则稳定、复用度高、平台团队可以集中治理。

BFF 该做什么

BFF 更适合承接“某个客户端特有”的组装逻辑，比如 App 首页一次性聚合多个后端接口、H5 页面按展示顺序裁剪字段、为小程序做轻量返回结构。

它本质上不是通用基础设施，而是交付层。前端变化快，BFF 也会跟着更频繁迭代。

两者都不该做什么

无论是网关还是 BFF，都不应该承接重业务规则、核心事务和复杂状态机。那部分逻辑应该回到领域服务，否则入口层会越来越重，最后谁都不敢动。

实战里怎么划分

看这段逻辑是不是“所有端都通用”

如果所有客户端都需要，而且规则稳定，优先放网关；如果只服务某类终端，优先放 BFF。

看变更是不是跟着页面走

页面一改就要改的逻辑，不适合放网关。因为网关一旦承担太多终端适配逻辑，平台层会迅速业务化。

看团队边界怎么协作

平台团队维护网关更合适，业务或前端团队维护 BFF 更顺手。边界清晰后，发布节奏、测试责任和故障定位都会更清楚。

常见误区

把 BFF 当成另一个业务中台

BFF 只适合做轻编排和轻聚合，不适合沉淀复杂领域规则。

把网关做成万能入口层

认证、限流可以放网关，但商品推荐、订单拼装、页面字段裁剪这类逻辑不要塞进去。

一个系统只保留其中一个

稍有规模的系统往往两者都需要，只是职责要分清。网关统一流量入口，BFF 贴近终端表达。

一句话总结

网关解决“统一治理”，BFF 解决“终端适配”。谁更靠近平台，谁更靠近页面，这条线划清以后，架构会稳很多。