写代码这几年前后端分离大概是最绕不开的话题了。哪怕你没亲手搭过项目也一定听过前端调接口、后端出数据这套说法。但真到了实际开发里“分离”这两个字往往比想象中复杂得多接口怎么定才不吵架按钮重复提交到底该谁拦权限校验放前端还是后端一旦团队里没人把这些事想清楚项目就会陷入一种微妙的互相消耗——前端改一版后端跟着调联调两天上线前又发现边界漏了。这篇文章我想从实际项目出发把前后端分工和分离架构这件事彻底聊透。不搬概念不讲空话就讲一线开发里最常遇到的拆解思路、校验边界、接口约定和踩坑教训。适合刚接触前后端分离的新人也适合正在被重复提交、权限校验、接口混乱折磨的团队参考。看完你至少能回答一个问题一个功能到底应该由谁负责边界画在哪里才算合理。1. 分离架构到底在解决什么问题1.1 从“不分家”说起传统开发模式的痛点先别急着聊分离的好处得先知道不分离是什么样。早几年常见的做法是后端用模板引擎直接渲染页面前端只负责写 CSS 和简单的 JavaScript 交互。当时团队规模小、业务简单这种方式确实高效——一个后台管理系统后端搂草打兔子顺手就把页面写了省去联调成本。但业务一复杂问题就冒出来了。第一是职责边界模糊页面逻辑、数据组装、渲染状态全堆在同一套代码里改一个搜索框的样式都可能要动后端的模板文件前端工程师想调页面却不敢碰服务端代码。第二是前后端耦合严重后端改了返回结构前端页面立刻跟着崩前端想多展示一个字段得等后端重新打包上线。第三是并行开发效率低前后端必须排着队来前端永远等后端的渲染输出时间全浪费在等待上。我印象最深的一次经历是维护一个老系统改一个列表页的分页逻辑。前端要新增一个“每页显示条数”的下拉框听起来很简单对吧结果后端模板里写死了分页参数前端改了页面还得等后端改模板、重新发布前后折腾了两天。这种体验你只要经历过一次就会明白分离不是炫技是被逼出来的必然选择。1.2 分离架构的核心价值解耦、并行、复用前后端分离之后最直观的变化就是解耦。前端通过 HTTP 接口拿数据后端不再关心页面长什么样两者之间唯一的契约就是接口文档。前端可以把页面交互、路由跳转、状态管理全部管起来后端可以专心设计 api、处理业务逻辑互相不干扰代码的边界变得非常干净。并行开发是另一个立竿见影的价值。接口定义好之后前端可以用 mock 数据先把页面写完后端同时把真实逻辑实现好。两边不需要互相卡脖子等到联调阶段把接口地址一换就能快速对上。我自己做过好几个同时开工的项目体验就是只要接口约定清晰前后端完全可以各写各的效率比串行开发翻倍都正常。还有一个容易被忽略的好处是复用性。后端提供的是标准的 HTTP api一套接口可以同时供给 Web 端、移动端、小程序端使用。如果哪天公司要新开一个客户端前端团队只需要重新写一套界面后端几乎不用动。这在传统模板渲染模式下是不可想象的那意味着每个端都要单独做一套后端逻辑开发量和维护成本都会成倍增长。1.3 不是所有项目都适合“一刀切”分离聊完了好处也得泼点冷水。分离架构不是银弹小项目、轻量项目、原型验证阶段强行拆成前后端两套反而会增加成本。一个只有五六个页面的内部工具你非要单独搞一套 Vue 工程加一套 Spring Boot 服务中间还要维护接口文档和跨域配置明显是杀鸡用牛刀。这时候我更推荐渐进式的策略先用模板渲染快速出活等业务复杂度上来了再把页面和接口逐步剥离。还有一类场景需要谨慎判断——强交互、重状态管理的页面其实非常适合分离但纯展示型、几乎无动态交互的页面分离带来的收益并不明显。判断标准其实很简单页面还需要深度定制交互吗接口需要被多个端复用吗团队能支撑起前后端的并行维护吗三个问题想清楚再决定要不要分离比盲目追逐架构潮流靠谱得多。2. 前后端分工的边界到底怎么画2.1 数据渲染与控制权页面归前端数据归后端分离架构下最混乱的往往不是技术选型而是“谁说了算”的问题。我的经验可以浓缩成一句话凡是用户看得到、摸得着的交互全都归前端凡是稳定、可复用的业务数据和规则全都归后端。这句话翻译一下就是页面上的按钮颜色、表格排序、弹窗展示、路由跳转、状态保持这些前端说了算后端不该干预。而用户信息、订单状态、库存数量、权限角色这类数据以及“订单金额必须大于零”“库存不足不能下单”这类业务规则必须后端说了算前端只负责把规则的结果呈现给用户。但这里有个经常踩的坑页面上的展示逻辑。比如“根据用户余额显示不同的充值引导”这算前端还是后端我见过不少团队把这种逻辑直接写死在 Vue 组件里余额小于多少显示弹窗、大于多少显示 banner。结果后端一改会员等级策略前端代码就得跟着改。正确的做法是后端返回一个明确的字段例如 display_level 或者 guide_type前端只负责根据这个字段渲染对应的 UI。如果某一天引导策略变了后端改一个值前端一行都不用动。2.2 接口契约定义接口就是定义项目边界既然前后端的唯一交集是接口那接口契约就是整个项目的“宪法”。我在项目启动时一定会和团队做一件事先写接口文档再开工。速度再赶这一步也不能省。用 Swagger/OpenAPI 也好用 Apifox、YApi 这种在线工具也好关键是要把接口的路径、请求方法、请求参数、返回结构、错误码全部写清楚。这里必须强调返回结构的一致性。我习惯统一类似 { code: 0, message: ok, data: { ... } } 的 JSON 格式code 为 0 表示成功非 0 表示业务失败。用 HTTP 状态码区分网络层错误404、500用业务 code 区分业务错误比如“库存不足”code 10086这样前端拦截器只需要统一处理 code 非 0 的情况代码会简洁很多。接口定义还有一个细节容易忽略枚举值和状态码必须有可读性。不要直接返回 1、2、3 让前端去猜要在文档里写明每个值对应的含义。团队大一点的话我建议做枚举共享——后端导出代码前端直接 import双方从源头上避免字段拼错和值对不上的尴尬。2.3 协作流程从接口定义到联调的标准化姿势很多团队联调效率低不是因为技术不行而是流程太随意。我现在比较习惯的一套流程是需求评审阶段就拉上前端、后端、产品一起把接口大致定下来然后后端快速输出接口文档初版前端拿着文档直接开始写页面、用 mock 数据自测后端实现完成后前端把 mock 切换到真实环境集中做联调。联调之前必须做一件事约定环境。这个看似废话但我在实际项目里真的遇到过后端改的是测试环境前端连的是开发环境两边折腾一上午才发现的乌龙。所以环境配置尽量别让开发手动改前端工程里用环境变量区分 dev、test、prod联调前确认两边都指向同一个环境能少生很多气。还有一个协作细节是接口变更的同步机制。分离之后前端当然不能改后端代码那后端要改接口怎么办我的经验是三步走先在接口文档里标注变更内容和生效时间再用消息群通知前端最后在代码里做兼容过渡比如加一个新的可选参数而不是直接删参数。前端知道后端在变后端知道前端在用两边不对齐就直接改是团队协作里最容易踩的雷。3. 前后端分离项目的工程化落地要点3.1 前端工程的架构思路与请求层设计前端工程化已经非常成熟Vue、React 都有配套的脚手架这部分不展开。我想重点聊聊请求层的设计因为这是前后端分离项目的前端核心。很多人写项目就是每个页面里直接 a用 axios 调接口开发一时爽维护火葬场。因为接口地址散落在各个组件里改一个 baseURL 得全局搜错误处理逻辑复制粘贴了好几次根本管不住。我习惯在工程里单独建一个 api 目录把每个接口封装成函数getUserList(params)、createOrder(data)。页面里只调用这些函数不直接写接口路径。同时封装一个统一的 request 实例把 baseURL、超时时间、请求拦截器如自动附带 token、响应拦截器统一处理 code 非 0、401 跳转登录都收口到一处。这样新增一个接口只是加一个函数后端改了域名只是改一处置线上出问题排查起来也快。响应拦截器里还有一件事我建议加进去统一的错误提示。业务 code 非 0 时前端往往要弹 toast 提示用户。如果每个页面都自己写一遍 message.error(“xxx”)那代码就太碎了。封装在拦截器里后端返回的 message 字段直接作为提示文案页面里只需要关心成功分支的数据异常分支统一走公共逻辑体验和代码质量都会好很多。3.2 后端接口设计的规范与参数校验后端的核心职责是提供稳定、安全的接口。稳定是指接口的返回结构不随意变安全是指服务端必须能独立完成必要的校验和鉴权。很多前端同学会问参数校验前端都做了后端还要做吗我的回答永远是必须做。前端校验是为了用户体验后端校验才是真正的安全防线。后端校验分两个层面第一是格式校验比如必填字段、类型、长度、枚举值范围这种可以用 Bean Validation 这类框架的注解解决框架会自动返回统一格式的错误信息不用自己手写一堆 if。第二是业务校验比如用户是否有权限、订单状态是否允许取消、库存是否足够这类校验需要有一定的上下文不能只靠注解得在 service 层写清楚判断逻辑。特别要强调一点不要让业务错误码五花八门。如果后端的校验失败时一会返回 400、一会返回 500、一会返回业务 code前端拦截器就没法统一处理。我建议后端所有预期内的校验失败统一走业务 code 通道HTTP 状态码保持 200 不动只有预期外的异常比如空指针、数据库挂了才返回 500。前端的处理逻辑会因此简化很多排查问题时边界也清晰。3.3 认证与鉴权会话管理与权限控制的常见组织方式分离架构下前端不是服务器直接渲染的页面传统的 Session 方式还能用但更常见的做法是 Token 认证用户登录成功后后端发放一个 token前端每次请求都把它带在请求头里后端解析 token 判断用户身份和权限。我在实际的若依这类后台管理系统里看到过一套很典型的方案前端登录后把 token 存在本地存储里请求拦截器自动加上 Authorization 请求头后端用拦截器统一解析 token把用户信息放到 ThreadLocal 或上下文对象里业务方法直接取用户 ID。权限控制方面后端在接口上声明需要的角色或权限码比如 RequiresPermissions(system:user:add)拦截器里统一判断不满足就返回无权限错误。这里有一个非常关键的边界问题菜单和按钮的显示控制放前端真正的数据权限和操作权限放后端。前端可以根据用户角色动态渲染菜单、隐藏按钮让界面更友好但后端必须再做一次真实的权限校验防的就是有人绕过前端直接调接口。权限从来不是前端的事前端只是体验层的装饰后端才是最后一道锁。4. 按钮重复提交的校验边界谁负责才是正解4.1 这个经典场景为什么值得单独拿出来讲按钮重复提交大概是所有前后端分离项目里最容易起争执的场景之一。用户手一抖连点两下提交前端做了防抖却拦不住脚本直接调接口后端做幂等又觉得前端也能做为什么还要后端写那么多代码。两边都觉得是对方的事联调时自然就吵起来了。我的结论先说清楚前端要做防重复后端必须做幂等。这俩不是二选一而是各司其职的两道防线。前端负责用户体验层——用户正常操作时快速点击不会产生两次请求后端负责数据正确性层——就算前端被绕过、网络重试、消息重复投递数据库里也不会出现重复数据。这个场景非常典型因为它完美体现了前后端分工的本质靠近用户的位置做体验优化靠近数据的位置做安全兜底。理解了按钮重复提交的边界划分基本就理解了分离架构里所有类似问题的处理思路——校验、鉴权、限流核心都是这套逻辑。4.2 前端方案防重复点击与请求层的幂等拦截前端做按钮防重复点击最简单的方式是提交后立刻把按钮置灰等接口返回后再恢复。用状态变量控制按钮的 loading 属性这是最直观也最常用的方案。但有经验的开发者都知道置灰只能防鼠标点击防不住用户回车提交、快速切换焦点、或者在无头浏览器里直接多发请求。所以我会建议在前端请求层再加一道“请求级防重”简单做法是给每个提交类接口定义一个唯一的业务标识比如表单内容生成一个 hash 值提交时把标识记录在内存 Map 里同样的 hash 还没处理完就去掉拦截或者用 Axios 的取消机制重复点击时取消前一个未返回的请求。这类方案能挡住大多数误操作实现成本也不高。但要清醒一点前端所有防重手段都只是概率性的。用户刷新页面重新进入、另开一个浏览器标签页、直接用 curl 调接口这些场景完全绕过了前端的逻辑。所以前端防重做得再好也替代不了后端的兜底。这个认知不扭转过来团队才会一直在这种无谓的争论里耗时间。4.3 后端方案幂等性设计是真正的数据兜底后端解决重复提交的思路核心是幂等设计。所谓幂等就是同一个操作执行一次和执行 N 次最终结果是一样的。最简单的方案是幂等表 / 唯一索引业务表上加一个唯一约束比如订单号重复插入时数据库直接报错或者用 INSERT ... ON DUPLICATE KEY UPDATE 之类的语句把重复写吞掉从而保证同一订单不会生成两次。更通用一点的做法是 token 机制后端在打开提交页面时下发一个一次性 token比如 uuid 存到 Redis设置有效期提交时前端把这个 token 带上后端先检查 Redis 里有没有这个 token有就删除并继续处理没有就说明是重复提交直接拒绝。这个方案几乎可以套在任何写接口上是后端做幂等拦截的常用姿势。选哪个方案取决于业务场景创建类接口订单、工单适合用唯一索引配合业务单据号通用写接口可以用一次性 token更新类接口则更适合乐观锁或版本号机制避免并发覆盖。关键不在于哪种方案“最牛”而在于你的数据表结构、并发量、业务约束适合哪一种。这份判断力才是后端工程师真正的价值所在。4.4 我推荐的前后端组合拳说了这么多我直接给一套可落地的组合方案。前端提交时把按钮置灰同时记录一个请求中标记相同请求未完成前直接忽略新的点击如果用的是 Vue 组件库按钮自带的 loading 属性就能做到大部分效果。后端根据接口类型选择幂等方案——创建接口用唯一索引 业务单号通用写接口用 Redis token 机制核心资金类操作再叠加乐观锁确保极端并发下的数据安全。这样组合之后的效果是正常用户多快的手速都只会产生一次有效请求恶意绕过后端也能挡住重复写日志里还能准确看到哪些请求被视为重复提交被拦截。两边都做了自己该做的事接口联调时不再互相甩锅。我曾经在一个订单系统里按这套方式落地过上线后线上重复订单数直接从每天几十单降到零排查问题也变得特别省心。5. 热点场景实战解析若依框架与电子签名项目5.1 若依框架主流前后端分离脚手架的分工样本若依是国内非常流行的开源后台管理系统常被拿来改造成各类管理后台。我拿它当例子是因为它的前后端分工非常标准几乎就是“教科书级别”的分离架构模板前端是 Vue Element UI后端是 Spring Boot MyBatis前后端通过 RESTful 接口对接权限体系采用 RBAC 模型。在若依里可以清楚看到我们前面讲的边界划分菜单、路由、按钮级别的权限控制前端根据用户角色动态生成菜单和按钮后端在每个接口上声明权限标识真正执行操作时还会再校验一次。代码生成器这类工具也特别值得借鉴——根据表结构直接生成前后端全套 CRUD 代码生成的代码里请求风格、返回格式都是统一的这本身就是一种隐形的最佳实践。我觉得若依最大的价值不是代码本身而是它在代码里固化了那些“团队协作时总被争论”的规范。比如分页请求统一用 pageNum/pageSize、返回统一用 TableDataInfo、token 统一放请求头。新人进了项目照着已有代码写就会自动遵循这些约定团队不用靠文档反复提醒。这种通过代码落实规范的做法比开会强调一百遍都有用。5.2 电子签名的前后端实现路径密码学与流程分工电子签名这种场景最能体现前后端分离的分工深度。从一个普通的签名功能说起用户在页面上签下自己的姓名或者画一个手写签名这属于前端交互但如果要在法律意义上达成“电子签名”就必须用到密码学技术这部分不是前端画个图就够了。简单方案的做法是前端用 canvas 或签名板组件采集签名图片传给后端保存。实现很快但安全性和法律效力都很弱——图片可以被复制、被粘贴、被替换。正规一点的做法是引入数字签名后端用哈希算法对合同内容生成摘要再用私钥加密生成签名值前端把合同和签名值一同展示任何人对合同内容的修改都会让验签失败。更复杂的方案会引入 CA 机构证书和可信时间戳这就是政务、金融级电子签名的范畴了。从分工角度看非常清晰前端负责签名交互的体验、合同展示和用户确认流程后端负责密钥管理、签名生成、验签逻辑和存证留痕密码学算法需要依赖正规的加密机或云服务商。前端再炫酷也不能替代后端的可信计算后端再严谨也需要前端把法律提示和操作确认做得足够清楚。电子签名项目要是没想明白这层分工大概率会做出一个“看起来很电子实际上没签名”的半吊子功能。6. 绕不开的坑跨域、环境与安全拦截6.1 跨域问题的常见处理方式前后端分离之后前端页面部署在一台服务器后端接口在另一台服务器浏览器出于安全同源策略就会拦截跨域请求。我刚做分离项目时在这上面栽过不少跟头后来把方案梳理清楚后发现其实就三种主流路线。第一种是后端开 CORS在响应头里加上 Access-Control-Allow-Origin 等字段Spring Boot 可以配置全局跨域Nginx 也可以在网关位置统一加。这种方式简单直接适合开发环境。第二种是前端用代理一般 Vite 和 webpack 都支持配置 proxy把 /api 前缀的请求代理到后端地址浏览器看来页面和接口永远是同源的。开发环境我最喜欢这种方式完全不用后端操心。第三种是网关统一处理在 Nginx 层配置反向代理同时解决跨域、路由转发和负载均衡。上线环境基本都走这条路。这几个方案的边界要分清本地联调用 Vite proxy测试和生产用 Nginx 代理真正需要后端配合的只是开发初期临时开的 CORS。别一上来就找人后端开跨域很多前端问题从前端代理就能解决省时也省事。6.2 环境配置与联调接口管理的避坑心得多环境一直是分离项目里最容易翻车的地方。开发环境、测试环境、预发环境、生产环境每个环境的接口地址不一样令牌密钥也各自独立。如果代码里写死接口地址每次换环境都得改代码重打包这本身就是个设计错误。我现在的做法是前端工程里建 .env.development、.env.test、.env.production 等文件分别配置 VITE_API_BASE_URL 之类的变量后端同样用 Spring profiles 拆分 application-dev.yml、application-test.yml、application-prod.yml把不同环境的数据库、Redis、密钥配置分开管理。代码里永远只引用配置项不写死具体地址。联调时还有一个常见坑前端连的接口到底是哪个环境的、数据是哪天的。现在比较推荐的方案是给测试环境配置清库和初始化脚本每次联调前重置数据避免上一次联调的脏数据影响这次判断。团队大一点还可以用 Apifox 或 Postman 的同步文档和 Mock 能力接口文档多环境自动切换前端看到示例数据也一目了然来回扯皮的次数会少很多。6.3 安全视角下的前后端各自防线谈安全的时候我的比喻是这样的前端是门卫后端是金库。门卫负责看起来不像坏人的人放进来——比如 token 过期了把用户送到登录页金库负责确认每个人真的没有偷东西——即使攻击者拿着合法工具直接调接口后端仍然要逐项校验权限、参数、业务规则。前端常见的安全措施有请求拦截器自动携带 token、退出登录时清理本地凭证、对用户输入做必要的展示层转义防 XSS。后端则是所有接口统一鉴权、参数校验白名单化、敏感数据脱敏、SQL 防注入、操作日志留痕。这些措施前后端都必须做但各自的粒度不同。前端做得再好也只是用户体验层面的防护后端的防线才是数据安全的根本。有一个特别容易被开发忽略的细节是日志中的敏感信息。前端打印日志不要输出用户的完整手机号、身份证号后端日志同样要脱敏不能让密码、token 等凭证明文出现在堆栈里。这个小习惯不花什么成本但非常提升项目的专业度真出事的时候能省很多麻烦。7. 分离架构的未来形态与团队核心素养7.1 从 BFF 到微前端分离在深化而不是终结前后端分离发展到现在边界又长出了新的层次。BFFBackend For Frontend就是典型——前端团队自己维护一层很轻的后端服务专门负责聚合、裁剪、格式化下游接口数据前端页面不必面对一堆复杂的微服务接口。这种模式进一步解放了前端让前端可以按自己的页面需求定制数据形状同时不破坏核心后端的稳定接口。微前端则是另一个方向解决的是大型前端工程的组织问题不同团队可以独立开发、独立部署自己的前端模块再由一个主应用把它们组合起来。这时候前后端的边界从“项目之间”变成了“团队之间”每个团队都有自己完整的前后端闭环这既是对分离架构的继承也是一种进阶。这些新形态的出现说明分离架构本身一直在演进。技术永远在变化但这条主线从来没变过把大问题拆成小问题让每个模块边界清晰、职责单一让团队可以通过契约并行协作。理解了这个主线以后无论什么新框架、新模式冒出来你都能很快找到自己的位置。7.2 团队分工背后真正重要的能力聊到最后我想说一点可能不太中听的实话。前后端分离不是把团队分裂成两拨人各干各的而是让两边在自己的领域深耕的同时更好地协作。一个真正成熟的前端愿意去了解接口怎么设计才合理一个真正成熟的后端会体谅前端的数据加工成本。这种换位思考的能力比任何框架都重要。我在带团队的时候特别看重一件事让每个人都有机会写一遍“对方的代码”。前端尝试写一个简单的后端接口后端修一个前端 Bug这个过程收获的不仅是技能更是对协作边界的具体感知。你会发现很多以前在群里吵来吵去的问题自己试过一遍之后自然就明白对方为什么那么做、那么要求了。一个前后端分离项目能不能做得顺技术只是基础真正的决定因素是团队是否对齐了共同的目标——稳定、高效地把功能交付出去。架构是骨架契约是肌肉而团队每个人的互相理解才是让这个系统真正运转起来的血液。我在实际项目的体会是分离架构最难的从来不是搭建而是在日复一日的迭代里守住边界。接口文档更新勤一点返回结构改得谨慎一点校验逻辑后端多写一层遇到重复提交先想清楚“这一道防线到底该谁守”——把这些小事做好了前后端自然就从“博弈”走向了“共生”。真到了那个状态你会发现所谓架构的核心价值不是技术多酷而是团队多省心。
写代码这几年前后端分离大概是最绕不开的话题了。哪怕你没亲手搭过项目也一定听过前端调接口、后端出数据这套说法。但真到了实际开发里“分离”这两个字往往比想象中复杂得多接口怎么定才不吵架按钮重复提交到底该谁拦权限校验放前端还是后端一旦团队里没人把这些事想清楚项目就会陷入一种微妙的互相消耗——前端改一版后端跟着调联调两天上线前又发现边界漏了。这篇文章我想从实际项目出发把前后端分工和分离架构这件事彻底聊透。不搬概念不讲空话就讲一线开发里最常遇到的拆解思路、校验边界、接口约定和踩坑教训。适合刚接触前后端分离的新人也适合正在被重复提交、权限校验、接口混乱折磨的团队参考。看完你至少能回答一个问题一个功能到底应该由谁负责边界画在哪里才算合理。1. 分离架构到底在解决什么问题1.1 从“不分家”说起传统开发模式的痛点先别急着聊分离的好处得先知道不分离是什么样。早几年常见的做法是后端用模板引擎直接渲染页面前端只负责写 CSS 和简单的 JavaScript 交互。当时团队规模小、业务简单这种方式确实高效——一个后台管理系统后端搂草打兔子顺手就把页面写了省去联调成本。但业务一复杂问题就冒出来了。第一是职责边界模糊页面逻辑、数据组装、渲染状态全堆在同一套代码里改一个搜索框的样式都可能要动后端的模板文件前端工程师想调页面却不敢碰服务端代码。第二是前后端耦合严重后端改了返回结构前端页面立刻跟着崩前端想多展示一个字段得等后端重新打包上线。第三是并行开发效率低前后端必须排着队来前端永远等后端的渲染输出时间全浪费在等待上。我印象最深的一次经历是维护一个老系统改一个列表页的分页逻辑。前端要新增一个“每页显示条数”的下拉框听起来很简单对吧结果后端模板里写死了分页参数前端改了页面还得等后端改模板、重新发布前后折腾了两天。这种体验你只要经历过一次就会明白分离不是炫技是被逼出来的必然选择。1.2 分离架构的核心价值解耦、并行、复用前后端分离之后最直观的变化就是解耦。前端通过 HTTP 接口拿数据后端不再关心页面长什么样两者之间唯一的契约就是接口文档。前端可以把页面交互、路由跳转、状态管理全部管起来后端可以专心设计 api、处理业务逻辑互相不干扰代码的边界变得非常干净。并行开发是另一个立竿见影的价值。接口定义好之后前端可以用 mock 数据先把页面写完后端同时把真实逻辑实现好。两边不需要互相卡脖子等到联调阶段把接口地址一换就能快速对上。我自己做过好几个同时开工的项目体验就是只要接口约定清晰前后端完全可以各写各的效率比串行开发翻倍都正常。还有一个容易被忽略的好处是复用性。后端提供的是标准的 HTTP api一套接口可以同时供给 Web 端、移动端、小程序端使用。如果哪天公司要新开一个客户端前端团队只需要重新写一套界面后端几乎不用动。这在传统模板渲染模式下是不可想象的那意味着每个端都要单独做一套后端逻辑开发量和维护成本都会成倍增长。1.3 不是所有项目都适合“一刀切”分离聊完了好处也得泼点冷水。分离架构不是银弹小项目、轻量项目、原型验证阶段强行拆成前后端两套反而会增加成本。一个只有五六个页面的内部工具你非要单独搞一套 Vue 工程加一套 Spring Boot 服务中间还要维护接口文档和跨域配置明显是杀鸡用牛刀。这时候我更推荐渐进式的策略先用模板渲染快速出活等业务复杂度上来了再把页面和接口逐步剥离。还有一类场景需要谨慎判断——强交互、重状态管理的页面其实非常适合分离但纯展示型、几乎无动态交互的页面分离带来的收益并不明显。判断标准其实很简单页面还需要深度定制交互吗接口需要被多个端复用吗团队能支撑起前后端的并行维护吗三个问题想清楚再决定要不要分离比盲目追逐架构潮流靠谱得多。2. 前后端分工的边界到底怎么画2.1 数据渲染与控制权页面归前端数据归后端分离架构下最混乱的往往不是技术选型而是“谁说了算”的问题。我的经验可以浓缩成一句话凡是用户看得到、摸得着的交互全都归前端凡是稳定、可复用的业务数据和规则全都归后端。这句话翻译一下就是页面上的按钮颜色、表格排序、弹窗展示、路由跳转、状态保持这些前端说了算后端不该干预。而用户信息、订单状态、库存数量、权限角色这类数据以及“订单金额必须大于零”“库存不足不能下单”这类业务规则必须后端说了算前端只负责把规则的结果呈现给用户。但这里有个经常踩的坑页面上的展示逻辑。比如“根据用户余额显示不同的充值引导”这算前端还是后端我见过不少团队把这种逻辑直接写死在 Vue 组件里余额小于多少显示弹窗、大于多少显示 banner。结果后端一改会员等级策略前端代码就得跟着改。正确的做法是后端返回一个明确的字段例如 display_level 或者 guide_type前端只负责根据这个字段渲染对应的 UI。如果某一天引导策略变了后端改一个值前端一行都不用动。2.2 接口契约定义接口就是定义项目边界既然前后端的唯一交集是接口那接口契约就是整个项目的“宪法”。我在项目启动时一定会和团队做一件事先写接口文档再开工。速度再赶这一步也不能省。用 Swagger/OpenAPI 也好用 Apifox、YApi 这种在线工具也好关键是要把接口的路径、请求方法、请求参数、返回结构、错误码全部写清楚。这里必须强调返回结构的一致性。我习惯统一类似 { code: 0, message: ok, data: { ... } } 的 JSON 格式code 为 0 表示成功非 0 表示业务失败。用 HTTP 状态码区分网络层错误404、500用业务 code 区分业务错误比如“库存不足”code 10086这样前端拦截器只需要统一处理 code 非 0 的情况代码会简洁很多。接口定义还有一个细节容易忽略枚举值和状态码必须有可读性。不要直接返回 1、2、3 让前端去猜要在文档里写明每个值对应的含义。团队大一点的话我建议做枚举共享——后端导出代码前端直接 import双方从源头上避免字段拼错和值对不上的尴尬。2.3 协作流程从接口定义到联调的标准化姿势很多团队联调效率低不是因为技术不行而是流程太随意。我现在比较习惯的一套流程是需求评审阶段就拉上前端、后端、产品一起把接口大致定下来然后后端快速输出接口文档初版前端拿着文档直接开始写页面、用 mock 数据自测后端实现完成后前端把 mock 切换到真实环境集中做联调。联调之前必须做一件事约定环境。这个看似废话但我在实际项目里真的遇到过后端改的是测试环境前端连的是开发环境两边折腾一上午才发现的乌龙。所以环境配置尽量别让开发手动改前端工程里用环境变量区分 dev、test、prod联调前确认两边都指向同一个环境能少生很多气。还有一个协作细节是接口变更的同步机制。分离之后前端当然不能改后端代码那后端要改接口怎么办我的经验是三步走先在接口文档里标注变更内容和生效时间再用消息群通知前端最后在代码里做兼容过渡比如加一个新的可选参数而不是直接删参数。前端知道后端在变后端知道前端在用两边不对齐就直接改是团队协作里最容易踩的雷。3. 前后端分离项目的工程化落地要点3.1 前端工程的架构思路与请求层设计前端工程化已经非常成熟Vue、React 都有配套的脚手架这部分不展开。我想重点聊聊请求层的设计因为这是前后端分离项目的前端核心。很多人写项目就是每个页面里直接 a用 axios 调接口开发一时爽维护火葬场。因为接口地址散落在各个组件里改一个 baseURL 得全局搜错误处理逻辑复制粘贴了好几次根本管不住。我习惯在工程里单独建一个 api 目录把每个接口封装成函数getUserList(params)、createOrder(data)。页面里只调用这些函数不直接写接口路径。同时封装一个统一的 request 实例把 baseURL、超时时间、请求拦截器如自动附带 token、响应拦截器统一处理 code 非 0、401 跳转登录都收口到一处。这样新增一个接口只是加一个函数后端改了域名只是改一处置线上出问题排查起来也快。响应拦截器里还有一件事我建议加进去统一的错误提示。业务 code 非 0 时前端往往要弹 toast 提示用户。如果每个页面都自己写一遍 message.error(“xxx”)那代码就太碎了。封装在拦截器里后端返回的 message 字段直接作为提示文案页面里只需要关心成功分支的数据异常分支统一走公共逻辑体验和代码质量都会好很多。3.2 后端接口设计的规范与参数校验后端的核心职责是提供稳定、安全的接口。稳定是指接口的返回结构不随意变安全是指服务端必须能独立完成必要的校验和鉴权。很多前端同学会问参数校验前端都做了后端还要做吗我的回答永远是必须做。前端校验是为了用户体验后端校验才是真正的安全防线。后端校验分两个层面第一是格式校验比如必填字段、类型、长度、枚举值范围这种可以用 Bean Validation 这类框架的注解解决框架会自动返回统一格式的错误信息不用自己手写一堆 if。第二是业务校验比如用户是否有权限、订单状态是否允许取消、库存是否足够这类校验需要有一定的上下文不能只靠注解得在 service 层写清楚判断逻辑。特别要强调一点不要让业务错误码五花八门。如果后端的校验失败时一会返回 400、一会返回 500、一会返回业务 code前端拦截器就没法统一处理。我建议后端所有预期内的校验失败统一走业务 code 通道HTTP 状态码保持 200 不动只有预期外的异常比如空指针、数据库挂了才返回 500。前端的处理逻辑会因此简化很多排查问题时边界也清晰。3.3 认证与鉴权会话管理与权限控制的常见组织方式分离架构下前端不是服务器直接渲染的页面传统的 Session 方式还能用但更常见的做法是 Token 认证用户登录成功后后端发放一个 token前端每次请求都把它带在请求头里后端解析 token 判断用户身份和权限。我在实际的若依这类后台管理系统里看到过一套很典型的方案前端登录后把 token 存在本地存储里请求拦截器自动加上 Authorization 请求头后端用拦截器统一解析 token把用户信息放到 ThreadLocal 或上下文对象里业务方法直接取用户 ID。权限控制方面后端在接口上声明需要的角色或权限码比如 RequiresPermissions(system:user:add)拦截器里统一判断不满足就返回无权限错误。这里有一个非常关键的边界问题菜单和按钮的显示控制放前端真正的数据权限和操作权限放后端。前端可以根据用户角色动态渲染菜单、隐藏按钮让界面更友好但后端必须再做一次真实的权限校验防的就是有人绕过前端直接调接口。权限从来不是前端的事前端只是体验层的装饰后端才是最后一道锁。4. 按钮重复提交的校验边界谁负责才是正解4.1 这个经典场景为什么值得单独拿出来讲按钮重复提交大概是所有前后端分离项目里最容易起争执的场景之一。用户手一抖连点两下提交前端做了防抖却拦不住脚本直接调接口后端做幂等又觉得前端也能做为什么还要后端写那么多代码。两边都觉得是对方的事联调时自然就吵起来了。我的结论先说清楚前端要做防重复后端必须做幂等。这俩不是二选一而是各司其职的两道防线。前端负责用户体验层——用户正常操作时快速点击不会产生两次请求后端负责数据正确性层——就算前端被绕过、网络重试、消息重复投递数据库里也不会出现重复数据。这个场景非常典型因为它完美体现了前后端分工的本质靠近用户的位置做体验优化靠近数据的位置做安全兜底。理解了按钮重复提交的边界划分基本就理解了分离架构里所有类似问题的处理思路——校验、鉴权、限流核心都是这套逻辑。4.2 前端方案防重复点击与请求层的幂等拦截前端做按钮防重复点击最简单的方式是提交后立刻把按钮置灰等接口返回后再恢复。用状态变量控制按钮的 loading 属性这是最直观也最常用的方案。但有经验的开发者都知道置灰只能防鼠标点击防不住用户回车提交、快速切换焦点、或者在无头浏览器里直接多发请求。所以我会建议在前端请求层再加一道“请求级防重”简单做法是给每个提交类接口定义一个唯一的业务标识比如表单内容生成一个 hash 值提交时把标识记录在内存 Map 里同样的 hash 还没处理完就去掉拦截或者用 Axios 的取消机制重复点击时取消前一个未返回的请求。这类方案能挡住大多数误操作实现成本也不高。但要清醒一点前端所有防重手段都只是概率性的。用户刷新页面重新进入、另开一个浏览器标签页、直接用 curl 调接口这些场景完全绕过了前端的逻辑。所以前端防重做得再好也替代不了后端的兜底。这个认知不扭转过来团队才会一直在这种无谓的争论里耗时间。4.3 后端方案幂等性设计是真正的数据兜底后端解决重复提交的思路核心是幂等设计。所谓幂等就是同一个操作执行一次和执行 N 次最终结果是一样的。最简单的方案是幂等表 / 唯一索引业务表上加一个唯一约束比如订单号重复插入时数据库直接报错或者用 INSERT ... ON DUPLICATE KEY UPDATE 之类的语句把重复写吞掉从而保证同一订单不会生成两次。更通用一点的做法是 token 机制后端在打开提交页面时下发一个一次性 token比如 uuid 存到 Redis设置有效期提交时前端把这个 token 带上后端先检查 Redis 里有没有这个 token有就删除并继续处理没有就说明是重复提交直接拒绝。这个方案几乎可以套在任何写接口上是后端做幂等拦截的常用姿势。选哪个方案取决于业务场景创建类接口订单、工单适合用唯一索引配合业务单据号通用写接口可以用一次性 token更新类接口则更适合乐观锁或版本号机制避免并发覆盖。关键不在于哪种方案“最牛”而在于你的数据表结构、并发量、业务约束适合哪一种。这份判断力才是后端工程师真正的价值所在。4.4 我推荐的前后端组合拳说了这么多我直接给一套可落地的组合方案。前端提交时把按钮置灰同时记录一个请求中标记相同请求未完成前直接忽略新的点击如果用的是 Vue 组件库按钮自带的 loading 属性就能做到大部分效果。后端根据接口类型选择幂等方案——创建接口用唯一索引 业务单号通用写接口用 Redis token 机制核心资金类操作再叠加乐观锁确保极端并发下的数据安全。这样组合之后的效果是正常用户多快的手速都只会产生一次有效请求恶意绕过后端也能挡住重复写日志里还能准确看到哪些请求被视为重复提交被拦截。两边都做了自己该做的事接口联调时不再互相甩锅。我曾经在一个订单系统里按这套方式落地过上线后线上重复订单数直接从每天几十单降到零排查问题也变得特别省心。5. 热点场景实战解析若依框架与电子签名项目5.1 若依框架主流前后端分离脚手架的分工样本若依是国内非常流行的开源后台管理系统常被拿来改造成各类管理后台。我拿它当例子是因为它的前后端分工非常标准几乎就是“教科书级别”的分离架构模板前端是 Vue Element UI后端是 Spring Boot MyBatis前后端通过 RESTful 接口对接权限体系采用 RBAC 模型。在若依里可以清楚看到我们前面讲的边界划分菜单、路由、按钮级别的权限控制前端根据用户角色动态生成菜单和按钮后端在每个接口上声明权限标识真正执行操作时还会再校验一次。代码生成器这类工具也特别值得借鉴——根据表结构直接生成前后端全套 CRUD 代码生成的代码里请求风格、返回格式都是统一的这本身就是一种隐形的最佳实践。我觉得若依最大的价值不是代码本身而是它在代码里固化了那些“团队协作时总被争论”的规范。比如分页请求统一用 pageNum/pageSize、返回统一用 TableDataInfo、token 统一放请求头。新人进了项目照着已有代码写就会自动遵循这些约定团队不用靠文档反复提醒。这种通过代码落实规范的做法比开会强调一百遍都有用。5.2 电子签名的前后端实现路径密码学与流程分工电子签名这种场景最能体现前后端分离的分工深度。从一个普通的签名功能说起用户在页面上签下自己的姓名或者画一个手写签名这属于前端交互但如果要在法律意义上达成“电子签名”就必须用到密码学技术这部分不是前端画个图就够了。简单方案的做法是前端用 canvas 或签名板组件采集签名图片传给后端保存。实现很快但安全性和法律效力都很弱——图片可以被复制、被粘贴、被替换。正规一点的做法是引入数字签名后端用哈希算法对合同内容生成摘要再用私钥加密生成签名值前端把合同和签名值一同展示任何人对合同内容的修改都会让验签失败。更复杂的方案会引入 CA 机构证书和可信时间戳这就是政务、金融级电子签名的范畴了。从分工角度看非常清晰前端负责签名交互的体验、合同展示和用户确认流程后端负责密钥管理、签名生成、验签逻辑和存证留痕密码学算法需要依赖正规的加密机或云服务商。前端再炫酷也不能替代后端的可信计算后端再严谨也需要前端把法律提示和操作确认做得足够清楚。电子签名项目要是没想明白这层分工大概率会做出一个“看起来很电子实际上没签名”的半吊子功能。6. 绕不开的坑跨域、环境与安全拦截6.1 跨域问题的常见处理方式前后端分离之后前端页面部署在一台服务器后端接口在另一台服务器浏览器出于安全同源策略就会拦截跨域请求。我刚做分离项目时在这上面栽过不少跟头后来把方案梳理清楚后发现其实就三种主流路线。第一种是后端开 CORS在响应头里加上 Access-Control-Allow-Origin 等字段Spring Boot 可以配置全局跨域Nginx 也可以在网关位置统一加。这种方式简单直接适合开发环境。第二种是前端用代理一般 Vite 和 webpack 都支持配置 proxy把 /api 前缀的请求代理到后端地址浏览器看来页面和接口永远是同源的。开发环境我最喜欢这种方式完全不用后端操心。第三种是网关统一处理在 Nginx 层配置反向代理同时解决跨域、路由转发和负载均衡。上线环境基本都走这条路。这几个方案的边界要分清本地联调用 Vite proxy测试和生产用 Nginx 代理真正需要后端配合的只是开发初期临时开的 CORS。别一上来就找人后端开跨域很多前端问题从前端代理就能解决省时也省事。6.2 环境配置与联调接口管理的避坑心得多环境一直是分离项目里最容易翻车的地方。开发环境、测试环境、预发环境、生产环境每个环境的接口地址不一样令牌密钥也各自独立。如果代码里写死接口地址每次换环境都得改代码重打包这本身就是个设计错误。我现在的做法是前端工程里建 .env.development、.env.test、.env.production 等文件分别配置 VITE_API_BASE_URL 之类的变量后端同样用 Spring profiles 拆分 application-dev.yml、application-test.yml、application-prod.yml把不同环境的数据库、Redis、密钥配置分开管理。代码里永远只引用配置项不写死具体地址。联调时还有一个常见坑前端连的接口到底是哪个环境的、数据是哪天的。现在比较推荐的方案是给测试环境配置清库和初始化脚本每次联调前重置数据避免上一次联调的脏数据影响这次判断。团队大一点还可以用 Apifox 或 Postman 的同步文档和 Mock 能力接口文档多环境自动切换前端看到示例数据也一目了然来回扯皮的次数会少很多。6.3 安全视角下的前后端各自防线谈安全的时候我的比喻是这样的前端是门卫后端是金库。门卫负责看起来不像坏人的人放进来——比如 token 过期了把用户送到登录页金库负责确认每个人真的没有偷东西——即使攻击者拿着合法工具直接调接口后端仍然要逐项校验权限、参数、业务规则。前端常见的安全措施有请求拦截器自动携带 token、退出登录时清理本地凭证、对用户输入做必要的展示层转义防 XSS。后端则是所有接口统一鉴权、参数校验白名单化、敏感数据脱敏、SQL 防注入、操作日志留痕。这些措施前后端都必须做但各自的粒度不同。前端做得再好也只是用户体验层面的防护后端的防线才是数据安全的根本。有一个特别容易被开发忽略的细节是日志中的敏感信息。前端打印日志不要输出用户的完整手机号、身份证号后端日志同样要脱敏不能让密码、token 等凭证明文出现在堆栈里。这个小习惯不花什么成本但非常提升项目的专业度真出事的时候能省很多麻烦。7. 分离架构的未来形态与团队核心素养7.1 从 BFF 到微前端分离在深化而不是终结前后端分离发展到现在边界又长出了新的层次。BFFBackend For Frontend就是典型——前端团队自己维护一层很轻的后端服务专门负责聚合、裁剪、格式化下游接口数据前端页面不必面对一堆复杂的微服务接口。这种模式进一步解放了前端让前端可以按自己的页面需求定制数据形状同时不破坏核心后端的稳定接口。微前端则是另一个方向解决的是大型前端工程的组织问题不同团队可以独立开发、独立部署自己的前端模块再由一个主应用把它们组合起来。这时候前后端的边界从“项目之间”变成了“团队之间”每个团队都有自己完整的前后端闭环这既是对分离架构的继承也是一种进阶。这些新形态的出现说明分离架构本身一直在演进。技术永远在变化但这条主线从来没变过把大问题拆成小问题让每个模块边界清晰、职责单一让团队可以通过契约并行协作。理解了这个主线以后无论什么新框架、新模式冒出来你都能很快找到自己的位置。7.2 团队分工背后真正重要的能力聊到最后我想说一点可能不太中听的实话。前后端分离不是把团队分裂成两拨人各干各的而是让两边在自己的领域深耕的同时更好地协作。一个真正成熟的前端愿意去了解接口怎么设计才合理一个真正成熟的后端会体谅前端的数据加工成本。这种换位思考的能力比任何框架都重要。我在带团队的时候特别看重一件事让每个人都有机会写一遍“对方的代码”。前端尝试写一个简单的后端接口后端修一个前端 Bug这个过程收获的不仅是技能更是对协作边界的具体感知。你会发现很多以前在群里吵来吵去的问题自己试过一遍之后自然就明白对方为什么那么做、那么要求了。一个前后端分离项目能不能做得顺技术只是基础真正的决定因素是团队是否对齐了共同的目标——稳定、高效地把功能交付出去。架构是骨架契约是肌肉而团队每个人的互相理解才是让这个系统真正运转起来的血液。我在实际项目的体会是分离架构最难的从来不是搭建而是在日复一日的迭代里守住边界。接口文档更新勤一点返回结构改得谨慎一点校验逻辑后端多写一层遇到重复提交先想清楚“这一道防线到底该谁守”——把这些小事做好了前后端自然就从“博弈”走向了“共生”。真到了那个状态你会发现所谓架构的核心价值不是技术多酷而是团队多省心。
![【线性DP】P10156 [LSOT-2] 胜者组](http://pic.xiahunao.cn/yaotu/【线性DP】P10156 [LSOT-2] 胜者组)
