前后端边界与网络层

Category

client / 前后端边界。节点定位：把表现逻辑、交互逻辑、权威逻辑三层划清——裁决权、预测、回滚、断线恢复都以这条边界为前提。

Definition

很多客户端架构问题，表面看起来像“网络不稳定”或“服务端逻辑太重”，本质上其实是前后端边界没画清。玩家一次点击之后，到底是客户端先反馈、服务端再确认，还是必须等权威返回；客户端能不能预测、缓存、回放；断线重连后状态以谁为准，这些问题都不属于单纯的网络层，它们是边界问题。

前后端边界如果没定义清楚，最常见的后果不是某个功能做不出来，而是系统长期处于“有时客户端说了算，有时服务端说了算”的混乱状态。

Problem

表面是「网络不稳定」「服务端逻辑太重」，本质是边界没画清：客户端能不能预测、缓存、回放，断线后状态以谁为准，一次点击先反馈还是等权威返回。边界不清的项目，要么被作弊打穿（裁决权在客户端），要么被体验拖垮（什么都等服务器）。

客户端为什么不能只被当成显示器

客户端天然握着很多本地能力：

• 输入和即时反馈
• 本地 UI 状态和交互节奏
• 局部缓存和资源调度
• 视觉预测、插值和表现修正
• 断线、弱网和重试时的用户体验兜底

如果这些能力完全不用，体验会很差；如果这些能力没有边界地扩张，又会开始侵入裁决和权威状态。所以真正的难点从来不是“客户端要不要做逻辑”，而是“客户端到底做哪种逻辑”。

最重要的边界：表现逻辑、交互逻辑和权威逻辑

比较稳妥的理解方式，是先把三类逻辑分开：

• 表现逻辑：特效、动画、镜头、UI 过渡、本地提示
• 交互逻辑：输入响应、页面状态、本地校验、局部预测
• 权威逻辑：资源变更、战斗裁决、匹配结果、房间状态、支付结果

前两类很多时候可以留在客户端，以换取流畅体验；第三类通常必须由服务端或权威运行时决定。问题往往出在边界不清，一部分权威判断悄悄长进客户端，后面又靠服务端补丁去兜。

网络层真正解决的不是收发包，而是状态收敛

网络层当然要处理协议、序列化、重连、心跳、超时和弱网，但更根本的问题是：

• 本地状态和远端权威状态如何对齐
• 客户端预测错了以后怎么回收
• 断线期间哪些状态允许本地继续推进
• 重连以后是拉快照、追增量还是重新入场

也就是说，网络层最关键的不是“把数据发到对面”，而是让前后端围绕同一套状态语义收敛。

哪些能力适合留在客户端

客户端适合承担的，通常是那些能明显改善体验、但不决定最终裁决的逻辑，例如：

• 动画前摇和命中表现的本地预播
• UI 状态机和交互流转
• 路径预览、技能指示器、本地提示
• 资源缓存和断点续传
• 弱网下的提示和退化体验

这类能力值钱的地方，是减少玩家感知的等待，而不是替代权威判断。

哪些能力必须谨慎留在客户端

下面这些能力如果长期长在客户端，通常会带来公平性和一致性风险：

• 关键经济资产结算
• 战斗最终命中、伤害和位移裁决
• 作弊敏感的可见性判断
• 排位和匹配结果确认
• 权限校验和订单确认

有些项目为了提速，会把一部分规则先放客户端试跑，但如果没有清楚的服务端确认与回收路径，迟早会在作弊、回滚和版本兼容上出问题。

断线、弱网和重连会真实暴露边界设计

正常网络下，很多边界问题会被掩盖。真正能暴露系统质量的，往往是这些场景：

• 丢包和高延迟
• 前后台切换
• 网络闪断
• 版本切换中的协议兼容
• 重连后的状态恢复

只要这些场景频繁出现“画面恢复了但状态不对”“客户端显示成功但服务端没记上”“重连以后位置和血量乱了”这类问题，通常就不是简单的网络 bug，而是边界没有被正式设计。

一个更稳妥的前后端分工

比较稳妥的做法通常是：

• 客户端负责交互体验和表现流畅度
• 服务端负责关键裁决和权威状态
• 网络层负责协议、重连和状态同步语义
• 项目层框架负责把预测、确认、回滚和恢复做成正式机制

这样做的核心不是“谁干得更多”，而是避免裁决权在客户端和服务端之间漂移。

常见误区

最常见的错误，是把“客户端需要更流畅”理解成“客户端应该决定更多事情”。第二类错误，是把网络层只看成协议收发，不把预测、确认、回滚和重连放回同一套状态设计里。第三类错误，是平时只看正常路径，等到弱网、断线和版本兼容出问题时，才发现前后端其实没有统一的状态语义。

实战案例：一次「客户端说成功，服务端没记上」的裁决权漂移排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「最重要的边界：表现逻辑、交互逻辑和权威逻辑」「哪些能力必须谨慎留在客户端」「断线、弱网和重连会真实暴露边界设计」「常见误区」用到深水区：购买与结算两边各说各话——这是裁决权漂移的对账排查，也是「避免裁决权在客户端和服务端之间漂移」的完整展开。

背景与现象：一款带付费道具的动作手游，上线两周后客诉集中在一个形态：客户端弹出「购买成功」，权威侧却查无此单。周对账差单 143 笔；重连后状态错乱工单占比 62%，全是「画面恢复了但状态不对」这一形态；排位结算争议 27 起，复盘发现其中 19 起的结算判定当时先写在客户端试跑。

第一步：现象与口径——把「显示成功但没记上」拆成两边账

权威口径：周对账差单 143 笔，客户端交易日志与服务端订单逐笔比对，91 笔客户端有、权威无——差单全部落在订单确认这一类。

恢复口径：重连后状态错乱工单占比 62%，重连后两边各按各的语义恢复，画面先回来、权威状态后到或不到。

第二步：分层归因——按本页三类逻辑清单排查

裁决权漂移归因  占比
  成交先判定长在客户端，服务端只做补记        50%
  网络层只管收发，预测与确认没有回收路径      30%
  重连后两边状态语义不同，各按各的恢复        20%

逐项比对：本页的谨慎清单——关键经济资产结算、战斗最终命中与伤害裁决、作弊敏感的可见性判断、排位和匹配结果确认、权限校验和订单确认——91 笔差单全部踩中「权限校验和订单确认」这条；三类逻辑里权威逻辑长进了客户端。

第三步：根因——把「更流畅」理解成了「本地说了算」

项目在「客户端需要更流畅」的压力下，把购买成交先在客户端判定、服务端事后补记，补不上就靠热修打补丁。本页把后果说得很直接：系统长期处于“有时客户端说了算，有时服务端说了算”的混乱状态。断线场景进一步放大问题——本页常见误区第三类「平时只看正常路径，等到弱网、断线和版本兼容出问题时，才发现前后端其实没有统一的状态语义」逐字应验：重连后没有统一状态语义，差单和错乱工单一起冒出来。

第四步：处置与回填——把裁决权钉回权威侧

1. 权威先行：购买、结算、排位确认只出服务端结果，客户端成交弹窗改为「已提交，等待权威确认」，权威未确认不放行任何资产表现。
2. 预测回收：本地预播只做表现逻辑，确认与回滚走同一条状态机，超时按权威结果回滚，不允许客户端结果静默生效。
3. 重连语义统一：重连先拉权威快照再补增量，两边恢复口径写进同一份状态设计，版本切换中的协议兼容随重连窗口一起测。

复核账：周对账差单 143 笔 → 6 笔；重连后状态错乱工单占比 62% → 7%；排位结算争议 27 起 → 2 起。

回填清单：

回填项	动作	回填处
权威先行	购买与结算只出服务端结果，客户端弹窗等权威确认	最重要的边界：表现逻辑、交互逻辑和权威逻辑
谨慎清单评审	经济结算、命中裁决、权限校验逐条登记裁决归属	哪些能力必须谨慎留在客户端
预测回收路径	本地预播超时按权威结果回滚，确认走同一状态机	网络层真正解决的不是收发包，而是状态收敛
重连状态语义	重连先拉权威快照再补增量，恢复口径单份设计	断线、弱网和重连会真实暴露边界设计

案例的三个教训

1. 流畅不等于裁决——客户端值钱的是减少玩家感知的等待，而不是替权威做决定。
2. 对账差单是边界的体检报告——「客户端有、权威无」的每一笔，都是裁决权漂移的实测证据。
3. 断线重连会把没设计过的边界全部暴露——统一的状态语义要先写进设计，而不是等弱网工单来提醒。

Used By

任何带服务端玩法的客户端/服务端接口评审；反作弊与结算权威设计（裁决权归属）；断线重连与状态恢复方案。

Related

关系链：表现逻辑 → 交互逻辑 → 权威逻辑 → 状态收敛 → 断线恢复。下游：客户端内部分层（web/06，进程内部再分层）、networking 树（接入协议与弱网）、server 树的状态同步与结算权威。

Reference

本页为工程经验归纳；确定性口径的展开见 server 树同步节点（server/sync）；页内实战案例为教学示例（数字取整简化）。