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

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

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

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

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

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

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

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

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

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

> "工具本身从来不是问题的答案,理解问题才是。" —— 未署名的架构师

引言：一场永无止境的争论

在技术社区里,关于 API 设计的争论从未停止。REST 的支持者会告诉你:"遵循 RESTful 原则,你的 API 就会优雅、可扩展。" GraphQL 的拥趸则反驳:"单一端点、精确查询、类型安全,这才是现代 API 的未来。"

但如果我告诉你,这场争论本身就是一个错误的问题?

真正的问题不是"应该选择 REST 还是 GraphQL",而是我们为什么需要在两种范式之间做非此即彼的选择?更深层次的问题是:我们是否真正理解了 API 设计背后的本质问题?

REST 的谎言:资源导向的美丽陷阱

REST(Representational State Transfer)在 2000 年由 Roy Fielding 提出时,是一个革命性的概念。它将 Web 服务抽象为"资源"的集合,通过标准的 HTTP 方法(GET、POST、PUT、DELETE)进行操作。听起来很完美,对吧?

Introducing OData
Data Access for the Web, the cloud, mobile devices, and more

David Chappell
Chappell & Associates

Published: May 2011

Download this whitepaper (PDF)

比特：

位或者比特(Bit)也简称小b(b)。

字节：

Byte简称大B（B）。

1个字节(B) = 8个比特(b)

所以：

常说的16位电脑，它是以： 16b/8 = 2个字节 为一个存储单元存储的。

常说的32位电脑，它是以： 32b/8 = 4个字节 为一个存储单元存储的。

常说的64位电脑，它是以： 64b/8 = 8个字节 为一个存储单元存储的。

字：

字是由一个或多个字节组成的。

因为计算机里最小的处理单位是：字节(B)，所以字肯定是字节的整数倍。一般来说，英文状态下，键盘上能敲出来的字都是一个字节的。但是如果是中文或者日文，一般是2个字节的。

但是，如果你是UTF8编码格式的话，字节数是1-6范围内的。因为UTF8是由1-6字节编码UNICODE字符。