客户端、服务端、平台与运营的边界

Category

industry / methodology 子树。节点定位：客户端/服务端/平台/运营四条边界——边界模糊会转化成扯皮、重复实现与无人负责；边界划分是设计动作。

Definition

游戏项目最耗团队精力的问题，很多不是技术不会做，而是边界长期模糊。一个功能到底归客户端还是服务端，一个限制到底由平台兜还是业务兜，一个活动故障算研发事故还是运营事故，如果这些问题在设计阶段不清楚，上线后就会不断转化成扯皮、重复实现和无人负责。

Problem

最耗团队精力的常不是技术不会做，而是边界长期模糊：功能归谁、限制谁兜、事故算谁，设计期不定清楚，上线后全部变成组织摩擦。边界不会随组织自然长出来，必须显式设计。

客户端的边界

客户端负责把体验交到玩家手里，因此天然承担这些职责：

• 输入采集、渲染、动画、音频、UI 和交互反馈。
• 对局部状态做预测、插值、补间和表现纠正。
• 管理资源加载、设备适配、崩溃采集和端侧性能控制。

但客户端不适合拥有不可审计的最终资产裁决权，也不适合独占那些会直接影响公平性和收益结算的关键逻辑。客户端可以先响应，不能无限制地“说了算”。

服务端的边界

服务端的核心职责不是“做所有事”，而是承担权威状态和共享规则：

• 管理账号、角色、资产、战斗结果、匹配关系和核心世界状态。
• 对关键操作做校验、裁决、补偿和审计。
• 在多人共享环境下维持一致性和恢复能力。

服务端一旦承担了权威职责，就必须同时承担恢复职责。只会裁决、不会恢复的服务端设计，在掉线、重启、重试和版本切换时会非常脆弱。

平台层的边界

平台层包括渠道、操作系统能力、第三方 SDK、审核机制、实名防沉迷、支付网关、广告和社交能力。平台层的特点是：它不是你能完全控制的，但它会持续限制你的实现。

因此平台层更像外部约束源，而不是普通依赖库。团队需要明确：

• 哪些能力必须直接依赖平台。
• 哪些平台差异应该被适配层吸收。
• 哪些失败模式要在业务侧准备兜底。

把平台差异散落在业务代码里，后面每增加一个渠道或地区，维护成本都会指数上升。

运营侧的边界

运营不是“发公告和配活动”的非技术部门。只要项目是长期运营，运营需求就会直接塑造系统：

• 活动开关、奖励发放、灰度实验、用户触达都需要可控后台。
• 风控处置、客服补偿、封禁解封、公告邮件都要求可审计。
• 数据分析和转化实验会反过来影响埋点、配置和版本节奏。

如果研发把运营系统当外围工具，最后主业务经常要靠手工补数据、临时改库和紧急发版来配合运营动作，风险极高。

边界划分的原则

比较稳的边界划分，通常遵循三条原则：

• 谁拥有最终裁决权，谁就必须承担校验和审计责任。
• 谁最接近体验，谁就优先负责即时反馈和本地表现。
• 谁无法被团队完全控制，谁就必须通过适配层和失败兜底隔离影响。

这三条原则能帮助团队避免“为了省事先混着做，出问题再补边界”的老路。

常见错误

• 客户端和服务端都保存一份关键规则，但没有明确谁是最终来源。
• 运营想要灵活性，研发就直接给数据库改写入口，没有审计链路。
• 平台接入由各业务模块各自处理，导致回调、登录态、支付态无法统一治理。
• 把“这个先放哪边都行”当小事处理，最后演化成大规模重构。

边界划分不是组织管理话题，而是系统设计本身。边界越清楚，技术决策越容易稳定，线上故障也越容易定位和收敛。

Used By

前后端分工约定；平台与业务的责任界面；事故归属判定。

Related

关系链：客户端边界 → 服务端边界 → 平台边界 → 运营边界 → 划分原则。上游：methodology/02（平台也是边界输入）。下游：client/02（前后端边界的技术面）。

Reference

本页为工程经验归纳。