通用游戏服务
Category
system / 通用服务子树总览。覆盖：账号与角色（01）、活动排行匹配社交（02）、交易支付与经济（03）、风控审计 GM 与客服（04）。
Definition
游戏项目早期最容易把精力都压在战斗、玩法和主链路上，等到版本进入上线准备或进入长线运营，团队才发现真正把项目拖慢的往往不是核心玩法代码，而是那些看起来“不够性感”的公共能力：账号、角色、活动、排行、匹配、社交、支付、风控、客服和 GM。
这些能力有几个共同特点。第一，它们跨系统、跨团队、跨生命周期，几乎不会只服务一个玩法。第二，它们和资产安全、用户关系、运营效率直接相关，一旦出错，影响通常比某个局内技能 bug 更大。第三，它们很容易被“先做一个能跑的版本”拖成历史包袱，最后每个项目都维护一套近似但不兼容的实现。
因此，这一章真正讨论的不是“要不要做这些功能”，而是三个更难的问题：
- 哪些能力应该平台化，哪些能力必须保留项目定制
- 哪些操作必须可审计、可回放、可追责
- 业务效率、运营灵活性和资产安全之间应该怎么取舍
阅读这一章时，建议始终带着下面几个判断框架：
- 先分清楚账号、角色、订单、社交关系、处罚记录分别是谁的权威状态
- 再看这些状态的读写路径里，哪些属于主链路，哪些属于外围治理链路
- 最后再决定复用方式，是统一服务、统一 SDK、统一控制台，还是只统一协议和数据口径
Related
关系链：账号角色（01）→ 四件平台化候选（02）→ 交易与经济（03）→ 治理四件套（04）。上游：security 树（治理面）；下游：numerical/04（经济设计侧）、database 树（建模）、树根 系统总览。
Reference
节点清单见下节。
本章文章
- 账号、角色与基础系统：讨论登录身份、角色实体、区服归属和基础资料服务为什么决定很多后续系统的边界。
- 活动、排行、匹配与社交：讨论高频运营能力如何在复用和项目差异之间取平衡，以及这些系统为什么经常变成线上流量尖峰来源。
- 交易、支付与经济系统：讨论订单、发货、资产变更和经济循环为何必须按“可追账、可补偿、可对账”来设计。
- 风控、审计、GM 与客服：讨论治理系统为什么不能只做检测，还必须覆盖证据、处置、申诉和人工干预闭环。