项目启动那天，产品经理对着屏幕吼了半句：“别让界面和逻辑混在一起，把前端和后端拆了。” 我当时质疑自己是不是刚入行，抿了口茶，心想这行是不是被某种高深哲学束缚住了，如何最近都流行“分离”这个词？后来才发现，这实际上是个挺实在的改造策略，就是俗称的前后端分离。好办说，就是那会儿咱们搞 MVC 要么管住器架构，把业务逻辑、数据展示和接口处理挤在一个容器里，如何想如何来。目前嘛，前端负责在浏览器里干活，后端在服务器（比如阿里云 OSS 要么私有数据库）里搞事，两者分工明确，互不干扰。 那会儿写代码，你认定自己是个通才，一个函数要能当管住器用，也能当管住器里的逻辑类，还得负责渲染模板。

这样折腾下来，代码像一团浆糊，改一个 Bug 可能连带把接入点搞崩了。目前变成前后端各司其职，前端只管如何把数据画出来，后端只管如何把数据拉过来。前端要加个下拉框，后端直接给个 JSON；前端想做个大图，后端传个文件流那会儿。

这就好比那会儿你做饭，得先洗菜、切菜、炒菜、摆盘，最终还得把盘子端上桌。目前前后端分离，就是厨师专门负责切菜，服务员负责端盘子，你只需求盯着盘子里的菜（数据）好不好吃，至于如何炒了如此长工夫再端上餐桌，那就不关你的事了。 这种模式在大型项目里特别好用。

那会儿那个“一个代码库，一套逻辑，一套渲染”的旧模式，叫 MVC 要么传统三层架构，听起来挺专业。但仔细拆解，后端管住层里的逻辑类，前端视图层里的模板，实际上是两套彻底不同的语言体系。后端写 Java 或 Go，前端写 Vue 或 React，要是混在一起，就像让一个英文单词去管中文语法，最终生成的代码烂到连机器都认不出它。 举个例子，假设我们要做一个电商详情页。

那会儿你会写一个 Controller 类，里面套个 Service，Service 里又套个 View 渲染逻辑。当你想优化页面加载速度时，你得去改那个 View 层；当你想增添一个搜索功能时，你得去改那个 Controller 层的映射逻辑。结局呢？数据源改了，整个页面的路由、接口鉴权、就连 CSS 样式都得跟着改，结局上线的半小时，整个项目可能要停摆半天。 而后端分离后，逻辑层彻底抽离。前端只要拿到前端传来的 JSON 数据，自己拍板如何渲染、如何加动画、缓存如何样。后端只管把数据吐出来，不管前端如何动。

这就好比后端就是个可靠的数据库接口，而前端就是你的手机浏览器。

你想换个手机装个最新版 OS（更新前端代码），只要后端接口没停机，你不用敲一行服务器代码。 数据量上来，这种分离的优势就体现得淋漓尽致。

那会儿那种所有代码放在一个 Git 仓库里，推上去就完了。目前前端和后端成了两个独立的仓库，前端能够频繁更新，哪怕有 Bug 了直接热更新（HMR），用户简直感觉不到。后端数据库改结构了，前端不需求关心，就连不需求重新编译。

这种解耦，让团队规模扩大了一倍，出于前端组能专注做交互和 UI，后端组能专注做性能和 API，互不挖坑。 还有个挺有意思的，就是代码体积和部署成本。

那会儿后端代码往往占大头，出于要跑各种逻辑。分离后，后端代码变得挺精简，那种“胶水代码”（连接前后端的 Controller、Service 层）就少了大量，部署时的依赖关系也清楚了。前端代码别看也变大了，但大局部是静态资源（图片、JS），部署到 CDN 上，速度极快，并且各个前端项目都能复用自己的资源库。 自然，这不代表没有挑战。前后端分离对开发者素质要求更高了。你得懂一点后端思维，知道数据是如何生成的；也得懂一点前端原理，知道 DOM 如何操作，如何搞缓存策略。

不然你前端写得再嗨，后端给的接口要是挂了，你也得去后端跑代码救场，这还不算工作量翻倍吗？这种“双修”的日子，初期肯定认定累，但只要方向对了，后期你会发现，这种清楚的分工反而让团队磨合得更快了，出于没人会在心里纠结“这个逻辑到底该不该写在前端还是后端”。 对于中小团队，可能还能混着点用，把好办的逻辑塞进管住器层，省事就行。等到项目规模超过某个阈值，那种“披肝沥胆”写混在一起的感觉忒杀风景了，还是得把逻辑层抽出来，哪怕略微高一点，把团队效率提起来。

毕竟，在 Web 世界里，清楚比厚重关键，灵活比复杂关键。

这种“裂缝”一旦打开，世界才会真正变得通透。