前后端分离架构中那些被忽视的连接点

一、不是画条线就叫分离

前后端分离讲了这么多年，大部分团队的实践就是：前端写 Vue/React，后端写 Spring Boot/Go，中间用 RESTful API 一接，完事。

但真正上线跑了几个月之后，你会发现一堆没人在架构图上画过的问题：

• 前端发起的请求，后端到底能不能接住？（接口契约漂移）
• 列表页翻到第 3 页，数据突然变了？（分页一致性）
• 用户点了一个按钮，前端乐观更新了，后端实际失败了？（状态同步）

这些才是前后端分离真正难的地方。下面聊几个我踩过的坑。

二、接口契约漂移：谁的锅？

一个经典的场景：后端改了字段名，Swagger 文档更新了，但没人通知前端。前端还在发旧字段，后端为了兼容又加了中间层——三个月后，一个接口有三套字段映射逻辑。

我们的做法很简单：共享一份 DTO 定义。

不是手写两遍，而是后端定义 OpenAPI spec，前端用工具自动生成 TypeScript 类型。后端改了什么，前端编译直接报类型错误，根本不用人去通知。

工具链：后端 FastAPI/SpringDoc → openapi.json → 前端 openapi-typescript-codegen → 类型文件。

这是最便宜的契约保障，一行运行时开销都没有。

三、分页一致性问题

用户在第 1 页看到 20 条数据，翻到第 2 页的时候，中间有人新增了一条——第 1 页最后一条被挤到了第 2 页开头，用户感觉"翻页重复了"。

游标分页（cursor-based）能解决这个问题，但不是所有场景都适用。对于大多数管理后台，我们用的是"快照时间戳"方案：

每次进入列表页，后端返回一个 snapshot_id（实际就是毫秒时间戳），后续翻页请求都带上它，后端只返回这个时间点之前的数据。用户体验上，翻页不会漂移。

代价是实时性稍差，但对管理后台来说完全够用。

四、乐观更新的状态黑洞

用户操作 → 前端立即更新 UI → 发 API → 失败 → 回滚 UI。这个模式在 ToC 产品里很常见，但做不好会出现"状态黑洞"——用户以为操作成功了，关掉页面走人，实际上后端根本没收到。

我们的策略是分级处理：

• 低风险操作（切换开关、标记已读）：乐观更新 + 失败静默重试 3 次
• 中风险操作（修改配置、保存草稿）：先发请求，loading 态，不搞乐观更新
• 高风险操作（删除、发布、支付）：必须后端确认，前端不允许提前反馈

分级的依据不是"技术上能不能回滚"，而是"用户感知到错误后的愤怒程度"。

五、总结

前后端分离的难点从来不在技术上，而在"边界处没人管"。接口契约、分页一致性、状态同步——这些都不归前端管也不归后端管，但出问题的时候用户骂的是整个产品。

建议每个团队指定一个人（轮值也行）专门盯这些边界问题，比什么都有效。