很多 BFF 最后会变成一层“Node 接口转发”。页面请求进来，Node 拉几个接口，拼一下 JSON，再吐给前端。这个模型能跑，但一旦页面系统变复杂，很快会遇到几个问题：SSO、国家路径、多站点这些全站规则写得到处都是；每个页面都在重复聚合首屏数据；渲染模板又和接口字段绑在一起，改一种渲染方式会牵动一堆业务代码。

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

这篇文章只讨论一个问题：横切、聚合、渲染为什么要分开，以及分开之后各自应该管什么。

三件事不要混在一起

先把三个词说清楚：

横切：还没进入具体页面之前，就应该处理的全站规则，比如域名、登录态、国家路径、尾斜杠、远程渲染开关。
聚合：已经知道是哪一页之后，为这页准备首屏或流式首段需要的数据。
渲染：数据准备好以后，决定怎么输出 HTML、怎么把状态交给浏览器，以及失败时走哪条备用路径。

它们一旦混在一起，后面会很难改。

全站规则写进页面，SSO 或多站点规则改一次，就要翻很多页面。聚合散落在组件里，首屏和浏览器端容易各写一套请求，Cookie、鉴权、网关前缀都可能不一致。渲染和业务 API 绑死以后，想换 SSR、流式或降级策略，也会牵动接口封装。

分层的目的不是把 BFF 画得更复杂，而是减少三类变化互相污染：全站规则变化，不应该改页面聚合；接口字段变化，不应该改模板；渲染策略变化，也不应该牵动网关封装。

一次请求怎么穿过 BFF

这里有一个容易误解的点：Vite 的位置。

开发态下，Vite middlewareMode 确实在请求链路里处理模块图、HMR、/@vite 等能力。生产态通常不是 Vite 扛用户请求，而是 Nginx/CDN 和构建产物提供静态资源。图里把它们放在同一格，只是为了表达“请求最先接触的往往是静态与模块层”，不是说线上还跑一个 Vite 进程处理流量。

再往后，请求会先经过全站中间件，再进入路由。只有路由命中具体页面以后，页面 Handle 才开始变重：加载页面配置、拉取下游数据、整理视图模型，然后交给渲染模板。

这个顺序很重要。越靠前的层，越应该处理全站一致的规则；越靠后的层，才应该处理页面自己的业务数据和渲染细节。

横切：先定规则，再进页面

横切逻辑的原则很简单：凡是还没知道是哪一页之前就能决定的规则，尽量放在页面路由之前。

比如当前 Host 对应哪个 clientId，Cookie 域怎么设置，请求是否经过 SSO，URL 里有没有国家路径，尾斜杠要不要归一化，是否尝试远程整页渲染并在失败时回落。这些都不是某个页面独有的逻辑，写进每个页面只会增加维护成本。

横切前移的收益很直接：规则集中配置，全站一致执行，业务页不用重复实现。代价也存在：排查问题时，不能只看页面代码，还要知道请求在进入页面之前被哪些中间件改写过。

这里最常见的坑是 path。页面路由看到的路径，未必就是浏览器地址栏里的原始路径，中间可能已经被国家段、尾斜杠或代理规则处理过。

聚合：这一页要哪些数据

路由命中以后，BFF 才真正进入“这一页”的上下文。聚合层要回答的问题是：这页首屏或流式首段需要哪些数据，分别从哪里来，失败时怎么处理。

它和普通 JSON 网关的区别在于，聚合结果经常不只是返回给浏览器的 REST JSON，而是要进入 HTML：一部分用于 SSR，一部分会被序列化成全局状态，交给浏览器继续 hydrate。

防腐层：不要让组件穿透后端字段

只把多个接口结果拼起来，价值有限。更关键的是把下游那些层次深、命名受历史约束、和 UI 模型不一致的 JSON，整理成组件可以直接绑定的结构。

比如下游可能返回：

const raw = {
  goods_info: {
    goods_name: 'Argus 4 Pro',
    main_image_url: 'https://example.com/argus.png',
  },
  price_info: {
    sale_price: 129.99,
    currency_code: 'USD',
  },
  stock_state: {
    is_in_stock: true,
  },
};

页面真正需要的可能只是：

const viewModel = {
  title: 'Argus 4 Pro',
  image: 'https://example.com/argus.png',
  price: '$129.99',
  available: true,
};

如果组件里到处写 goods_info.goods_name、price_info.sale_price，后端字段结构就会穿透到 UI 层。接口一改，组件跟着抖。Data Transformer 的作用就是在 BFF 或页面边界把它挡住：模板和组件面向站点自己的 View Model，而不是后端字段的逐字映射。

分工上可以这样划：

拉取、重试、并行：交给 API 封装和 HTTP 客户端。
字段如何整理成 UI 模型：交给页面或共享 transformer。
哪些数据允许进入首屏状态：交给页面和模板共同约束。

请求方向（去网关）：

响应方向（回到 BFF 之后）：

常见做法是：将整理后的 View Model 交给模板，由模板使用安全的序列化方式写入全局，例如项目约定的 window.__SSR_RENDER_DATA__。这里可以记成一句话：先防腐，再交接。

拉取顺序、依赖关系与失败策略由页面或布局决策；连接方式与默认缓存下沉到统一 HTTP 客户端；字段到 UI 模型的映射放在防腐层。这样三类变化不会搅在一起。

渲染：HTML、流与数据交接棒

渲染层主要管两件事。

第一，决定输出形态：SSR HTML、CSR Shell、流式响应，还是失败时退回备用路径。

第二，把 Node 侧的状态安全地交给浏览器，让客户端 bundle 能接着 hydrate。

也就是说，BFF 侧更关心请求如何进入、上下文是什么、数据从哪里来；模板更关心数据如何进入 DOM，以及异常时怎么退。

CSR、SSR、混合、流式这些都属于页面交付形态。用 Handle 生命周期和模板把它们收住，可以避免业务代码里到处出现“如果是 SSR 就这样，如果是 CSR 就那样”的条件分支。

交接棒：序列化与 Hydrate

聚合和防腐之后，数据仍然是 Node 内存里的 JavaScript 对象。浏览器 bundle 拿不到这份引用，所以 SSR 场景下必须通过 HTML 把状态交出去。

这个过程可以拆成两步：

序列化：在 Node 中将 View Model 转成可嵌入 <script> 的字符串，全局名由项目统一，比如 window.__SSR_RENDER_DATA__。
反序列化与 Hydrate：浏览器加载 bundle 后读取同一份状态，让框架和服务端已经输出的 DOM 对齐，避免整页重绘或双份渲染。

这里最容易出两类问题。

安全问题：如果对象里有用户可控字段，未经转义的 JSON.stringify 直接拼进 <script>，会有 XSS 风险。应该使用 serialize-javascript 这类安全序列化手段，并明确哪些字段允许进入首屏状态。

性能问题：内联状态越大，HTML 体积和解析开销越大。大列表、详情字段、低优先级信息不要一股脑塞进首屏；能裁剪就裁剪，能分页就分页，必要时只传标识，详情由客户端再拉。

防腐解决“数据形状是否适合 UI”，交接棒解决“状态能否安全、稳定地跨过 Node 和浏览器”。SSR 线上最容易暴露的问题，往往就出在这两个地方。

缓存是边界问题

缓存不是单独的一层，它通常夹在横切和聚合的边界上，所以最容易出错。

比如一个接口看起来是公共数据，但请求里带了国家、站点、登录态或 AB 实验；又比如 HTTP 客户端默认缓存了响应，但页面以为每次请求都是实时数据。这类问题排查起来很烦，因为 bug 表现像业务问题，根因却在缓存键或默认 TTL。

可以按三类看：

类型	作用	风险
连接层默认缓存	减轻下游压力、降低重复读延迟	用户相关读路径若缓存键设计不当，可能串数据。
按请求配置的 TTL	热点公共数据、按环境调节	TTL 过长会导致配置变更对用户不可见。
应用层节流与合并	防击穿、合并并发请求	与 HTTP 层缓存语义不同，不宜混用。

建议在规范里明确哪些路径禁止缓存，哪些允许短 TTL，缓存键必须包含哪些上下文字段。不要完全依赖默认行为，更不要让页面开发者靠猜。

收益与成本

这套拆分带来的收益比较明确：

全站横切规则集中演进，业务页改动面可控；
聚合和防腐留在页面边界内，组件不直接依赖后端字段形状；
渲染形态与下游网关解耦，模板与接口版本可以分别迭代；
接入层与表现层职责分离，便于分工、评审与分层测试。

但它也会增加系统理解成本：

请求链路更长，排障时要看中间件、路由、Handle、模板；
开发态和生产态存在差异，尤其是 Vite middleware 和静态资源服务；
需要配套日志、监控和链路字段，否则出了问题很难定位。

所以这套分层适合页面系统已经开始变复杂的场景。页面少、接入方式单一时，没必要提前把所有层都搭满。

小结

BFF 不应该只被理解成“Node 转发层”。在页面系统里，它更像一条服务端流水线：横切先处理全站规则，聚合在页面边界准备 View Model，渲染负责 HTML 输出、fallback 和状态交接。

这套分层的价值，不是让架构图更好看，而是让变化有边界。全站规则变化，不污染页面聚合；接口字段变化，不污染模板；渲染策略变化，也不需要把业务 API 重新翻一遍。

0 条评论

发表评论