账号、角色与基础系统

Category

system / 通用服务子树。节点定位：账号与角色先分清——基础系统不是「做个表单」，实现方式与代价对比，几个最容易被忽略的设计点。

Definition

账号系统和角色系统经常被误认为是“项目初始化时顺手搭一下的底座”，但它们其实决定了很多后续设计能不能收敛。登录、实名认证、游客转正、角色创建、区服归属、封禁、换绑、找回、合服迁移，这些流程一旦边界不清，后面每加一个系统都会继续叠债。

Problem

账号角色系统事故多是先把二者混着设计：账号是身份与安全边界，角色是玩法数据载体，混在一起后合并、找回、封禁全部变难。基础系统真正的复杂度不在表单在边界——注册渠道、绑定解绑、找回封禁这些路径才是事故源。

问题为什么会出现

账号和角色天然跨越多个边界：

• 对平台和渠道来说，账号首先是身份入口，要解决登录、授权、实名和支付主体问题
• 对游戏业务来说，角色才是真正承载资产、进度、社交关系和行为记录的对象
• 对运营和客服来说，需要能把账号、角色、区服、设备、订单、处罚记录关联起来

麻烦在于，这三套视角既相关又不能混成一个对象。很多事故都来自“为了省事先合起来做”。例如把渠道 uid 直接当内部主键，短期省去映射表，后面一旦接第二个渠道、支持游客转正、做跨端互通或账号找回，整个身份体系都会被迫重做。

先分清账号和角色

一个长期在线项目通常至少要明确下面几层对象：

• 登录身份：谁在外部平台上完成认证，通常对应渠道账号、手机号、邮箱或自建账号
• 游戏账号：项目内部的统一身份，用来绑定多个登录方式，承接实名、支付主体、封禁状态等信息
• 角色：某个分区或世界中的游戏实体，承载背包、任务、成长、社交和战斗状态
• 人工服务对象：客服和风控在后台看到的聚合视图，能把多个角色、多笔订单、多次处罚串起来

这几层对象不一定都要拆成独立服务，但语义必须先拆开。否则你会在一些很具体的场景里立刻出问题：

• 玩家换区后，资产到底跟着账号走还是跟着角色走
• 同一账号能否创建多个角色，限制在全局还是区服维度
• 合服后角色 id 是否变化，历史日志如何回查
• 封禁是封角色、封账号、封设备还是封支付能力

基础系统为什么不是“做个表单”

所谓基础系统，通常包括昵称、头像、货币展示、邮件、公告、签到、背包入口、设置、协议确认等看似普通的模块。难点不在页面，而在这些模块都处在资产、审计和用户触达的交汇处。

以邮件系统为例，它往往同时承担几种不同职责：

• 作为奖励投递入口，补发活动奖励、补偿道具、客服补单
• 作为运营触达工具，发公告、通知召回、推送版本提示
• 作为审计辅助链路，给每笔发货和补偿留痕

如果把邮件只当成客户端 UI 功能来做，很快就会遇到这些问题：

• 奖励重复领取或超时清理后无法补发
• 批量发送没有幂等键，脚本重跑后重复发货
• 无法区分“系统自动发放”“运营后台发放”“客服人工补发”

常见实现方式与代价

项目内单体实现

小团队最常见的做法是登录、角色、邮件、公告都放在游戏服或网关里一起做。优点是开发快，调用简单，出了问题也容易在一套代码里定位。代价是后面每个项目都会复制一遍，而且身份规则、审计口径、后台接口很难统一。

这种方案适合：

• 体量较小、生命周期短的产品
• 单渠道或少渠道接入
• 不需要复杂账号找回、跨端互通和大规模客服运营

它不适合：

• 同一公司多个项目共享账号体系
• 需要统一实名、防沉迷、封禁和支付风控
• 后期有明显的平台化运营预期

平台账号中心加项目角色服务

更常见的中型方案是把登录身份、账号绑定、实名、防沉迷、统一封禁等做成平台层能力，角色和区服数据仍由项目服务负责。这样既能统一治理，又能保留项目对角色模型的控制权。

代价在于接口设计会变难：

• 登录成功不代表角色可进入游戏，中间还要经过区服选择、角色列表、灰度资格等判断
• 平台账号状态变化要及时传给项目，例如实名状态刷新、处罚升级、找回申诉处理
• 客服后台需要穿透平台和项目两边数据，否则工单无法闭环

全量账号角色平台化

更重的做法是连角色基础服务都做成统一平台，比如统一角色主键、统一邮件、统一公告、统一角色封禁和迁移接口。好处是运营后台和审计口径极强一致，多项目共享成本低。坏处是项目定制能力会被压缩，角色模型演化也会受平台版本牵制。

这类方案只有在下面条件同时成立时才划算：

• 公司内产品类型相对集中
• 组织上有明确的平台团队和治理机制
• 业务团队愿意接受统一规范和接入成本

最容易被忽略的几个设计点

主键策略

不要让外部渠道标识直接污染内部主键。内部至少要有自己的稳定账号 id 和角色 id，否则一旦渠道变化、合规规则变化或跨平台互通，数据迁移会非常痛苦。

区服与世界模型

“区服”不是简单的展示字段，而是权限、路由、容量、社交边界和活动边界的综合对象。要尽早明确：

• 同服是否等于同世界
• 跨服玩法里资产归属和排行榜归属算哪边
• 合服后历史战绩、邮件和公会关系如何映射

人工操作的安全边界

客服补发、角色改名、封禁解封、资产回退这些操作必须有严格的权限、工单号、审批链和审计日志。很多团队在上线前只做了“后台能改”，真正出事后才发现没有回放、没有理由字段、没有操作前后快照。

常见错误

• 把账号、角色、设备、渠道用户混成一个 id 使用，导致后期无法扩展
• 只设计登录成功流程，不设计找回、换绑、封禁、申诉和迁移流程
• 客户端基础功能和后台治理能力完全脱节，运营和客服只能靠数据库脚本救火
• 把角色服务做成“所有系统都能直接写”的共享数据库，最后没有真正的权威边界

真正成熟的账号和角色体系，不是登录页做得多漂亮，而是当你接入新渠道、做跨端互通、处理资产争议、执行合规策略时，系统仍然知道谁是谁、东西在哪、谁改过、为什么改。

Used By

账号体系设计评审；角色数据归属约定；封禁与找回流程建设。

Related

关系链：为什么出问题 → 账号/角色分清 → 不是表单 → 实现方式与代价 → 易忽略设计点 → 常见错误。上游：无（services 子树入口）。下游：services/04（风控封禁的对象）、database 树（账号角色建模）。

Reference

本页为工程经验归纳。