文章

把面向页面的 BFF 看成一条服务端流水线。请求先经过静态与模块层，再进入全站中间件，命中具体页面后做数据聚合，最后由渲染模板决定如何输出 HTML、流或 CSR fallback。

这篇文章记录的是我们在 BFF 页面系统里做的一次插件化改造：页面只声明一个 `config.toml`，剩下的页面发现、模板匹配、虚拟入口生成、路由挂载和开发时重载，都交给 Vite 插件完成。

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

这个项目最核心的价值，在于将一个繁琐的视觉翻译工作，收敛成了一个清晰的布局树重建算法问题。以下是该方案的具体实现拆解。

不把商户差异当成零散条件分支处理，而是把它当成需要治理的对象。

在 MultipleSite 这套多站点页面平台里，真正稳定串起整条链路的，不是 React 组件本身，也不是某个后台页面，而是一份被多个子系统共同消费的协议。

很多团队都会经历一个看似顺理成章的阶段：先做一套 React 组件库，把按钮、轮播、卡片、导航、表单都沉淀下来，然后相信页面搭建问题会随着组件数量的增加自然被解决。

配置驱动值钱的从来不是"把代码写进 JSON"，而是逼着你把散落在各个角落的定义重新收拢，建立起一套所有模块都认的页面模型。菜单、路由、权限、面包屑，不是四个独立的问题——它们是同一个问题的四种表现。

本文基于一个真实中后台项目的演进过程，聊聊这套结构是如何从老旧的单体系统一步步走过来的，主壳和子应用怎么协作，以及踩过哪些坑。