
Architecture
BFF: 聚合、横切与渲染如何分层
不少人把 BFF 理解成「多包一层 Node 做接口转发」。更贴切的看法是:面向站点页面的一条服务端流水线——在同一进程(或同一部署单元)内,先经过静态与模块(开发态与生产态形态不同),再执行全站共用的规则,随后进入具体页面完成数据聚合与首屏拼装,最后由渲染模板决定如何输出 HTML(含 SSR、流式、失败兜底等)。
2026年4月28日9 min

不少人把 BFF 理解成「多包一层 Node 做接口转发」。更贴切的看法是:面向站点页面的一条服务端流水线——在同一进程(或同一部署单元)内,先经过静态与模块(开发态与生产态形态不同),再执行全站共用的规则,随后进入具体页面完成数据聚合与首屏拼装,最后由渲染模板决定如何输出 HTML(含 SSR、流式、失败兜底等)。

在复杂业务场景里,页面渲染早就不是 SSR 和 CSR 的二选一,而是一个关于体验、稳定性与工程治理的系统设计问题。

不把商户差异当成零散条件分支处理,而是把它当成需要治理的对象。
在 MultipleSite 这套多站点页面平台里,真正稳定串起整条链路的,不是 React 组件本身,也不是某个后台页面,而是一份被多个子系统共同消费的协议。

很多团队都会经历一个看似顺理成章的阶段:先做一套 React 组件库,把按钮、轮播、卡片、导航、表单都沉淀下来,然后相信页面搭建问题会随着组件数量的增加自然被解决。
配置驱动值钱的从来不是"把代码写进 JSON",而是逼着你把散落在各个角落的定义重新收拢,建立起一套所有模块都认的页面模型。菜单、路由、权限、面包屑,不是四个独立的问题——它们是同一个问题的四种表现。
本文基于一个真实中后台项目的演进过程,聊聊这套结构是如何从老旧的单体系统一步步走过来的,主壳和子应用怎么协作,以及踩过哪些坑。