前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。

这不是技术倒退，而是对"分离成本"的重新认识。

前后端分离的三大隐形成本

大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。

1. 沟通成本：从「对话」变成「会议」

以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。

前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。

我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。

金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。

这不是技术问题，是认知问题。

2. 抽象成本：API成为最脆弱的边界

前后端分离后，API成了两端的契约。听起来很美好，但现实是：

- 需求变化时，API要跟着改
- 前端要的字段，后端可能没有
- 后端返回的数据，前端可能用不上
- 版本升级时，兼容性是噩梦

更要命的是，API设计本身就是个难题。REST不够灵活，GraphQL引入了新的复杂度，BFF又需要额外的中间层维护。

我见过太多团队在API设计上反复纠结，最后妥协出一个"四不像"的方案——既不够RESTful，也没GraphQL那么灵活，还得维护一堆定制化的聚合接口。

这个成本，往往被低估。

3. 认知负担：前端要懂后端，后端要懂前端

理论上，前后端分离后各司其职。实际上？

- 前端要懂HTTP缓存、认证机制、错误处理
- 后端要懂前端渲染逻辑、性能瓶颈、用户体验

否则，前端会写出每次刷新都请求全量数据的代码，后端会返回前端根本用不上的1MB JSON。

更尴尬的是，遇到性能问题时，前端说"接口慢"，后端说"渲染慢"，互相甩锅。最后发现是接口返回了冗余数据，前端又没做分页加载。

如果有个全栈工程师在，这问题根本不会出现。

全栈工程师的真实价值

我不是说全栈工程师能解决所有问题，但在某些场景下，他们确实有不可替代的价值。

价值1：端到端的问题诊断

生产环境出了bug，前端说接口返回错了，后端说参数传错了。这时候如果有个全栈工程师，打开浏览器看下Network面板，再看下数据库日志，5分钟定位问题。

这不是技术能力的差距，而是全链路视角带来的效率。

金融业务里，用户投诉"收益计算不对"，可能是前端展示精度问题，也可能是后端计算逻辑问题，还可能是数据源本身有问题。全栈工程师能快速排查整个链路，而不是等前后端互相确认。

价值2：更合理的架构设计

前端工程师设计API时，容易从"前端好用"的角度出发；后端工程师设计API时，容易从"数据模型"的角度出发。

全栈工程师的优势是：他知道两端的约束。

比如BFF（Backend for Frontend）架构，本质上就是用全栈思维解决前后端分离的痛点——在前端和后端之间加一层，由最懂前端需求的人来设计这层API。

但问题来了：这层API谁来写？如果是纯前端工程师，他可能不懂后端的性能约束；如果是纯后端工程师，他可能不懂前端的渲染逻辑。

最理想的情况？全栈工程师来做这件事。

价值3：更快的迭代速度

初创团队为什么喜欢招全栈工程师？因为快。

一个全栈工程师能完整交付一个功能，不需要等前后端对齐、联调、互相等待。这在业务快速变化的场景下，优势明显。

即使在成熟团队，某些垂直功能（比如后台管理系统、内部工具）也更适合全栈工程师独立完成。

什么时候需要全栈，什么时候需要分离

我不是说前后端分离错了。恰恰相反，在很多场景下，前后端分离是必要的。

关键是：要根据团队规模、业务复杂度、迭代频率来判断。

适合前后端分离的场景

- 团队规模大（前端、后端各10人以上）
- 技术栈差异明显（比如Java后端 + React前端）
- 业务稳定，需求变化不频繁
- 有专门的API设计和文档维护能力

这种情况下，前后端分离的成本可控，职责清晰的价值更大。

适合全栈工程师的场景

- 初创团队，需要快速迭代
- 垂直功能模块（后台系统、内部工具）
- 业务逻辑复杂，前后端耦合度高（比如金融计算、实时数据处理）
- API变化频繁，沟通成本高

这种情况下，全栈工程师能显著提升效率。

混合策略：不是非此即彼

更现实的做法是：核心业务前后端分离，垂直功能全栈负责。

比如在我们金融团队：
- 核心交易系统：前后端分离，API由专门的架构师设计
- 理财产品配置后台：全栈工程师独立负责
- 用户端的推荐算法集成：全栈工程师写BFF层

这样既保证了核心系统的稳定性，又保证了边缘功能的迭代速度。

全栈工程师的「栈」到底是什么

很多人误解全栈工程师，以为是"什么都会一点，什么都不精"。

实际上，好的全栈工程师不是样样精通，而是：
- 有一端深度（前端或后端的专家级能力）
- 另一端够用（能独立完成功能，理解原理和约束）
- 全链路视角（知道问题出在哪一层，能快速定位和协调）

我从后端起步，深耕前端，现在做全栈。这个路径给我最大的收获不是"技术栈更广"，而是"看问题的角度变了"。

遇到性能问题，我不会只盯着前端代码，也会看接口设计、数据库查询、缓存策略。这种全局视角，是单一技术栈很难培养的。

写在最后

前后端分离不是错的，全栈工程师也不是万能的。

但如果你发现团队的沟通成本越来越高，API设计越来越复杂，需求迭代越来越慢——也许该重新思考一下：是不是分得太开了？

对个人来说，学全栈不是为了"多一项技能"，而是为了更好地理解整个系统。这种理解，在任何团队都是稀缺的。

至于要不要学全栈？问问自己：你是想成为"专精一端的专家"，还是"能独立解决问题的工程师"？

两条路都对，但答案不同。