前后端分离架构解析

很多开发团队在项目初期拍着胸脯保证要做前后端分离，结果上线没三个月，前端抱怨接口字段天天变，后端吐槽前端连个分页参数都传不对。前后端分离架构听起来是个银弹，其实是一把双刃剑，砍中了业务增长的痛点，也容易划伤自己的手。

分离的本质是解耦，不是物理隔离

说白了，前后端分离绝不仅仅是把前端代码从后端项目的 public 目录挪到一个独立的 Git 仓库里。它的核心在于契约的建立与维护。传统 MVC 架构中，后端通过模板引擎渲染视图，数据流转在服务端闭环完成。而分离架构下，后端退化为纯数据提供者（通常以 RESTful API 或 GraphQL 形式），前端独立接管路由与状态管理。

这种模式下，双方唯一的纽带就是 API 契约。一旦契约定义不清晰，或者后端为了赶进度直接把数据库表结构原封不动抛给前端，所谓的分离就变成了灾难。原本后端改个字段只需改个模板，现在得前端发版、后端发版、联调测试，原本一杯咖啡搞定的事，硬生生熬成了三个通宵。

数据交互的底层屏障

为了抹平网络抖动和异常带来的割裂感，现代分离架构通常会在边界处做文章。后端通过统一异常处理切面（如 Spring 的 @RestControllerAdvice 或 Laravel 的 Exception Handler），把业务异常包装成标准 HTTP 状态码与 JSON 错误体。前端则通过 Axios 拦截器统一接管这些错误，进行全局弹窗或无感刷新 Token。

{
  "code": 401,
  "message": "令牌已过期，请重新登录",
  "data": null,
  "trace_id": "a1b2c3d4"
}

这种设计看似冗余，但在微服务网关层做全链路追踪时，那个 trace_id 就是排查跨域调用失败的救命稻草。

真实的工程代价

不要被技术博客里岁月静好的 Demo 骗了。在真实的高并发场景下，前后端分离会带来不可忽视的 SEO 困境。因为前端采用客户端渲染（CSR），搜索引擎爬虫抓取到的只是一个干瘪的 HTML 骨架和一堆异步请求，核心内容根本无法被索引。

为了弥补这个短板，团队往往需要引入 Next.js 或 Nuxt.js 这样的同构框架。这意味着前端工程师不仅要写组件，还得搞懂 Node.js 服务端的内存泄漏和进程管理。技术栈的突然变宽，直接拉高了招聘门槛和服务器成本。

接口安全的边界博弈

分离之后，API 完全暴露在公网。哪怕加了 Referer 校验，也防不住爬虫的伪造请求。CSRF（跨站请求伪造）的防护策略必须从依赖 Cookie 的 SameSite 属性，升级为显式的 Token 校验（JWT 或 OAuth2）。

不过，JWT 并非万能药。把用户状态全部塞进 Payload 里，一旦需要让某个用户强制下线，服务端就显得无能为力，除非引入 Redis 黑名单机制。这又把无状态的 API 重新拖回了有状态的泥潭。架构设计就是这样，按下了葫芦浮起了瓢，哪有什么完美方案，不过是权衡利弊后的妥协罢了。