---
URL: "/zh-CN/blog/2025-07/when_use_bff.html"
LLMS_URL: "/zh-CN/blog/2025-07/when_use_bff.md"
lastUpdated: true
commentabled: true
recommended: true
title: "🤔什么时候用BFF架构？"
description: "🤔什么时候用BFF架构？"
date:

pageClass: "blog-page-class"
cover: "/covers/platform.svg"
---

---
lastUpdated: true
commentabled: true
recommended: true
title: 🤔什么时候用BFF架构？
description: 🤔什么时候用BFF架构？
date: 2025-07-18 10:05:00 
pageClass: blog-page-class
cover: /covers/platform.svg
---

## 🍃前言 ##

你好啊，我是你的人类朋友！

今天说说 **BFF架构**

看完之后你会对标题有自己的答案

## 🏃‍♂️BFF架构——快速认识！ ##

BFF（Backend For Frontend，前端专用后端）架构是一种为特定前端应用或用户界面定制后端服务的模式。

举个例子吧，比如PC端屏幕大，可能显示的东西就多，需要的字段也就多

移动端界面小，需要展示的字段可能就少

那我们就可以在BFF层为他们分别设置特定的接口，而不是共用字段多的接口

实现网络传输过程的优化

还有就是我请求一个数据

这个数据包含多次请求，都放在前端写，那就与服务器太耦合了

BFF出来了，将多次请求进行*聚合*——先请求A拿到B，再用B拿到C...

前端请求BFF层就完事了

## 🌰上场景，帮助理解 ##

### 场景一：多端体验差异显著的大型应用 ###

**案例**：某大型电商平台拥有Web、移动App、小程序、智能电视等多个客户端

**问题**：

- Web端需要丰富完整的产品信息（描述、参数、评论、推荐等）——总结：屏幕大
- 移动App需要精简的核心信息（价格、主图、库存）——总结：屏幕小
- 智能电视只需极简信息（主图、名称、价格）——总结：追求极简风格，毕竟用户要看电视

**传统方案**：所有客户端使用同一API，导致：

- 移动端收到冗余数据浪费流量
- 电视端需要额外处理不需要的字段
- 任何改动需要考虑所有客户端兼容性

**BFF方案**：

> 🤔没有什么是加一个中间层不能解决的，如果有就再加一层

- Web-BFF：提供完整产品详情聚合
- Mobile-BFF：只返回核心字段，优化图片尺寸
- TV-BFF：极简响应结构，大字体友好数据

**效果**：

- 各端获得最佳数据体验
- 网络传输量平均减少了不少！！
- 各端可独立迭代不互相影响，这不就解耦了吗？

### 场景二：微服务架构下的前端集成 ###

**案例**：银行系统改造为微服务架构（账户服务、交易服务、风控服务等）

**问题**：

- 前端展示一个账户概览页需要调用5-6个微服务=>前端老哥😠😠😠："不是哥们，你这么搞是吧，`&……*#￥…#￥%#￥#@%￥#@@%￥`
- 移动网络下多次请求成功率下降，说白了就是性能问题
- 服务响应格式不一致增加前端处理复杂度，前端血压容易高

**传统方案**：

- 前端直接调用多个微服务
- 需要处理服务发现、熔断等复杂逻辑
- 多次请求延长页面加载时间

**BFF方案**：

- 实现聚合层，一次调用获取所有必要数据。因为BFF层帮我们做了各个请求，封装好了结果，调用放拿来直接用就可以了。
- 统一错误处理和重试机制
- 转换各服务数据为前端友好格式

**效果**：

- 页面加载时间直接起飞
- 网络错误率下降
- 前端代码简化

## 🦉不适用BFF架构的情况 ##

> 了解了解，防止过度设计🍵重点看前面的就可以了，后面的知道一下留个印象即可

- **简单应用**：只有单一客户端且需求简单，没必要拆一层BFF了
- **资源极度有限**：无法承担额外部署和运维成本
- **实时性要求极高**：BFF可能增加少量延迟
- **前端技术高度统一**：所有客户端需求基本一致

## 🤔BFF实施的关键决策点【点题了兄弟们】 ##

当考虑采用BFF时，问以下几个问题：

> 重点看我加粗的字！！

- 我们是否有多个客户端且它们的需求**差异显著**？
- 前端是否因后端接口不合适而存在大量**适配**代码？
- **不同客户端**是否需要不同的性能优化策略？
- 后端服务变更是否会**频繁影响前端**？
- 是否有**足够的资源**维护额外的BFF层？

如果多数答案为"是"，BFF可能是合适的架构选择。

## 🤖现代BFF的演进趋势 ##

BFF的进化方向：

> 名字起的有点玄乎，配合栗子，我保证你能看懂ヾ(◍°∇°◍)ﾉﾞ

> ヾ(◍°∇°◍)ﾉﾞ名字起的有点玄乎，配合栗子，我保证你能看懂

> 名字起的有点玄乎，配合栗子，我保证你能看懂ヾ(◍°∇°◍)ﾉﾞ


### 边缘BFF ###

- → 把接口服务塞到离用户最近的机房（比如你在深圳就连广州服务器），我直接把饭喂你嘴里，你都不用动，问对面怎么说😏
- → 立即推：刷抖音更快了

### Serverless BFF ###

- → 不用管服务器，流量大了自动扩容（双十一自动加机器，平时不浪费钱）
- → 效果：省钱+不怕崩

> 一句话总结：BFF越进化，前端越自由【记住，BFF为前端服务！！】，性能越好，团队越少吵架。

## 👋最后 ##

大家一起变强！

🫏....。.。。.🫏🫏.🫏.🫏。。。...🫏🫏..。。.🫏🫏..🫏...