前后端分离架构：到底"分"的是什么，又怎么落地

一、先说清楚：分离的不是"人"，是"职责"

很多人以为前后端分离 = 前端一个人写、后端一个人写。这只是组织层面的结果，技术上的本质是"职责的边界"：

• 前端负责：页面结构、样式、交互、把数据"画"出来。跑在浏览器里，直接面对用户。
• 后端负责：业务逻辑、数据存储、权限校验、对外提供"数据接口"。跑在服务器上，不直接面对用户。

两边通过一份约定好的接口契约（通常是 HTTP + JSON）通信。谁也不碰对方的代码，只认接口。

前端（浏览器）  ──HTTP 请求(JSON)──▶  后端（服务器）
   ◀──HTTP 响应(JSON)──┘

一句话总结：分离的是"渲染"和"逻辑/数据"这两件事，而不是两拨人。

二、一张图看懂整体架构

下面这张图是典型的生产级前后端分离架构，从用户访问到数据返回全链路都标出来了：

逐层说一下每一块干什么：

注意一个铁律：前端永远不直接连数据库。它只能通过后端暴露的接口要数据。这和早期的"PHP 里混着 HTML、SQL 直接写在页面里"有本质区别。

三、一次请求是怎么走完的

光看架构还不够直观，把"用户点一下按钮"到"页面出现数据"的全过程拆开：

六步走：

1. 前端请求：用户在页面点操作，前端用 fetch / axios 发一个 HTTP 请求。
2. 网关路由：请求先到 API 网关，网关做鉴权（token 合法吗？）和路由（该转发给哪个后端服务？）。
3. 后端处理：后端服务收到请求，执行业务逻辑（校验参数、算业务）。
4. 查库 / 缓存：需要数据时，后端去查 MySQL 或读 Redis 缓存。
5. 返回 JSON：后端把结果整理成统一格式的 JSON 返回。
6. 前端渲染：前端拿到 JSON，更新视图，用户看到结果。

整个过程里，前端和后端唯一的交集就是第 2 步发出的那个 HTTP 请求和第 5 步回来的 JSON。这就是"契约驱动"——只要 JSON 格式不变，前端换框架、后端换语言，互相不影响。

四、为什么一定要分离（不分离会怎样）

我看到不少小项目图省事，后端模板里直接写 HTML、SQL 写在页面里。项目小的时候真省事，但长大后就痛：

• 改个样式要动后端：前端想调个按钮颜色，得后端发版。协作灾难。
• 多端复用难：同一套逻辑，Web 要一套、App 要一套、小程序要一套。分离后，后端只写一次接口，三端共用。
• 性能优化束手束脚：静态资源没法独立上 CDN，首屏慢。
• 技术栈被绑死：前端想用 React，后端模板是 JSP，改不动。

分离之后这些都不是问题：前端随便换框架，后端随便换语言，多端共用一套 API。

五、落地时的几个关键决策

真要做分离，有几个点得提前想好：

1）接口怎么约定

推荐用 OpenAPI（Swagger）把接口文档化。前后端先对齐字段，再各自开发，谁也不等谁。

# 一个最小化的接口约定示例（OpenAPI 片段）
paths:
  /api/users/{id}:
    get:
      summary: 获取用户详情
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: integer }
      responses:
        '200':
          description: 成功
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'

2）登录态怎么带

前端登录后拿到 token，后续每个请求在 Authorization 头里带上。登录态这件事后面会专门展开讲，这里先记住一句："前端只持有 token，不持有密钥"就行。

3）跨域（CORS）怎么处理

前端 localhost:8080 调后端 api.xxx.com，浏览器会因为同源策略拦掉。两种解法：

• 开发期用前端 dev server 的代理（/api 代理到后端）。
• 生产期后端配 CORS 白名单，或前面挂一层网关统一处理。

4）构建产物怎么布

前端 npm run build 出来的 dist/ 是纯静态文件，丢 CDN 或对象存储（比如华为云 OBS 静态网站托管）就行，不需要应用服务器。

六、新手最容易踩的 5 个坑

1. 把 token 存 localStorage 还不防 XSS——敏感场景优先 httpOnly Cookie，或做好 XSS 防护。
2. 接口字段随心所欲——今天 user_id 明天 userId，前端崩溃。约定大于习惯。
3. 前端做权限判断——“这个按钮隐藏了所以安全”，大错。权限必须在后端校验，前端隐藏只是体验。
4. 过度设计——小项目硬上微服务 + 网关 + 服务网格，把自己累死。按需来，单体也能分离。
5. 忽略错误态——只写成功渲染，接口挂了页面白屏。加载中、空数据、报错三态都要照顾。

七、小结

前后端分离的核心就一句话：各管各的，靠接口说话。前端管"看得见的交互"，后端管"看不见的逻辑和数据"，中间用 HTTP + JSON 当契约。

它是为了"可维护、可扩展、多端复用"而存在的工程手段，不是炫技。小项目可以轻量落地（前端 SPA + 一个后端服务 + 直接 CORS），等规模上来了再补网关、微服务、缓存那一层。别一上来就堆架构，也别永远不分离——按团队和业务的真实节奏走。