玩家账号体系设计

概述

玩家进入游戏的第一步是登录。小游戏场景下账号体系几乎都依托微信/QQ/手机号等第三方登录，配合游客登录降低门槛，再用 Token 完成后续鉴权。本文设计一套完整的玩家账号体系：第三方登录接入、游客登录、Token 认证、设备绑定与防沉迷接口。

---

一、登录方式全景

1.1 小游戏的登录方式

方式	门槛	场景	优点	缺点
微信登录	低	微信小游戏	免输账号密码	依赖微信环境
手机号登录	中	App / 验证码	全渠道统一	验证码成本
游客登录	极低	首进入	转化率高	换设备丢账号
账号密码	高	自有平台	可控	输入成本高

设计原则：
  游客一键进游戏 → 高转化
  后续绑定手机/微信 → 防丢号
  登录链路：游客 → 引导绑定 → 正式账号

1.2 登录链路总览

客户端 → 授权获取凭证 → 服务器换取用户信息
  → 匹配/创建账号 → 签发 Token → 进入游戏

微信小游戏标准链路：
  前端 wx.login() 拿 code
  后端用 code 调微信接口换 openid
  openid 作为玩家唯一标识

---

二、第三方登录接入

2.1 微信登录

流程：
  1. 客户端 wx.login() 获取临时凭证 code
  2. 客户端把 code 发给游戏服务器
  3. 服务器调微信 jscode2session 接口：
     appid + secret + code → openid + session_key
  4. 服务器用 openid 作为账号唯一标识
  5. 首次登录创建新账号，否则加载已有账号

安全要点：
  code 一次有效，5 分钟过期
  secret 只存在服务器，绝不下发客户端
  服务端校验 code，不信任客户端传的 openid

2.2 QQ / 手机号登录

QQ 登录：与微信类似，换 openid 的接口不同
手机号登录：
  客户端调运营商/平台取手机号（微信一键手机号）
  服务器校验后以手机号作为绑定标识
  可绑定到已有账号，或创建新账号

统一抽象：
  channel（渠道）+ openId（渠道内唯一 ID）
  → 映射到平台内唯一 playerId

2.3 渠道抽象设计

public class AuthService {

    // 渠道类型：WECHAT / QQ / PHONE / GUEST
    public AuthResult auth(AuthRequest req) {
        // 1. 渠道校验：调对应渠道接口验证凭证
        ChannelUser channelUser = verify(req.getChannel(), req.getCode());
        // 2. 按 channel + channelUserId 查账号绑定
        PlayerAccount account = accountDao.findByChannel(req.getChannel(), channelUser.getOpenId());
        if (account == null) {
            account = createAccount(req.getChannel(), channelUser.getOpenId());
        }
        // 3. 生成并返回 Token
        String token = tokenService.issue(account.getPlayerId());
        return new AuthResult(account.getPlayerId(), token);
    }
}

扩展新渠道：
  新增一个 verify 实现即可
  账号表结构支持多渠道绑定同一 playerId

---

三、游客登录

3.1 游客流程

游客登录：
  客户端生成设备标识（deviceId）
  服务器以 deviceId 创建临时账号
  发放游客 Token，直接进入游戏

特点：
  零门槛，首日转化关键
  无真实身份，需引导绑定
  设备重置/换机 → 账号丢失风险

3.2 游客转正（绑定）

绑定时机：
  触发条件：进行敏感操作（充值前必绑）、累计天数、主动弹窗
  绑定方式：微信授权 / 手机号验证

绑定流程：
  游客账号 + 新渠道凭证 → 校验渠道账号未被占用
  → 关联到游客 playerId → 升级为正式账号

关键约束：
  一个渠道账号只能绑一个玩家
  绑定冲突（渠道账号已绑他人）→ 提示换渠道

3.3 设备标识与防作弊

deviceId 获取：
  客户端持久化存储随机 UUID（卸载重装会变）
  或取设备唯一标识（受系统限制）

风险与对策：
  游客刷号：限制单设备游客账号数
  游客绕过绑定：敏感操作强校验（充值、交易）
  批量游客：同 IP/设备频控

---

四、Token 认证

4.1 为什么用 Token

HTTP 无状态，登录后每次请求都要证明"我是谁"
方案对比：
  Session（服务器存状态）→ 分布式下需共享存储
  Token（客户端持有凭证）→ 服务器只验签，天然无状态
  游戏场景：Token 配合长连接网关鉴权

4.2 Token 设计

字段	说明
playerId	玩家唯一标识
expireAt	过期时间（如 7 天）
sign	签名（HMAC-SHA256）

两种实现：
  JWT：标准格式，含签名与载荷，可无状态验签
  自定义 Token：随机串 + Redis 映射
    优点：可主动踢人（删除 Redis key）
    缺点：需要查 Redis
  游戏推荐自定义 Token + Redis：
    顶号、封禁、强制下线都需要服务端主动失效

4.3 签发与校验

public class TokenService {

    // 签发：登录成功后调用
    public String issue(long playerId) {
        String token = UUID.randomUUID().toString().replace("-", "");
        redis.set(TOKEN_KEY + token, String.valueOf(playerId),
                  Duration.ofDays(7));
        return token;
    }

    // 校验：网关/业务入口调用
    public Long verify(String token) {
        String playerId = redis.get(TOKEN_KEY + token);
        return playerId == null ? null : Long.parseLong(playerId);
    }

    // 失效：登出、顶号、封禁时调用
    public void revoke(String token) {
        redis.del(TOKEN_KEY + token);
    }
}

安全要点：
  Token 走 HTTPS/WSS 传输，不落明文日志
  登录接口限流，防暴力
  顶号时旧 Token 立即失效
  封禁时删除全部 Token

---

五、设备绑定

5.1 绑定模型

设备与账号关系：
  一账号可多设备（手机 + 平板 + 小游戏）
  一设备可有多个游客/多个账号（家庭共用）

表结构：
  设备表：device_id → 最近登录账号、常用登录时间
  账号设备表：player_id + device_id → 绑定关系、绑定时间

5.2 设备绑定用途

用途	说明
游客找回	deviceId 找回游客账号
风控	异常设备登录提醒
防作弊	同设备多账号检测
合规	设备数限制（防刷号）

---

六、防沉迷接口

6.1 防沉迷要求

核心规则（中国区）：
  实名认证：未成年人需实名（真实姓名 + 身份证）
  时长限制：未成年人游戏时长受限（节假日/平日不同）
  时段限制：22 点 - 次日 8 点禁止未成年人游戏
  充值限制：未成年人月充值上限

技术对接：
  接入官方实名认证接口
  登录后查询防沉迷状态
  服务器强制计时与到点踢下线（服务端权威）

6.2 服务端实现要点

public class AntiAddictionService {

    // 登录时查询：返回该玩家的防沉迷等级
    public AntiAddictionInfo check(long playerId) {
        // 调实名认证接口 / 本地缓存结果
    }

    // 实时时长管控：服务端定时器累加
    public void onTick(long playerId, AntiAddictionInfo info) {
        // 未成年：累加在线时长
        // 超过限额 → 推送提示并强制下线
    }
}

强制手段：
  时长到了必须由服务器主动断开（客户端不可信）
  跨服也要统计总时长（统一服务）
  节假日时长规则与平日不同（按日历表配置）

6.3 实名认证流程

1. 客户端提示实名
2. 收集姓名 + 身份证 → 服务器
3. 服务器调实名认证接口校验真伪
4. 返回结果：通过 → 标记实名状态（成年/未成年）
5. 拒绝实名 → 按游客处理时长限制

---

七、登录链路安全清单

安全清单：
  凭证校验在服务端（code 不可伪造）
  Token 随机且不可预测（UUID / 安全随机数）
  登录接口限流 + 异常检测
  游客不能访问敏感功能
  渠道凭证过期时间检查
  登录日志全量记录（审计）

---

八、常见问题

问题	处理
换设备游客号丢失	引导绑定 + 设备找回
同 openid 重复注册	以 channel+openId 为唯一键
顶号逻辑	新登录使旧 Token 失效
防沉迷绕过	服务端计时 + 强制下线
渠道凭证伪造	服务端调用渠道接口验证

---

九、小结

账号体系是小游戏的第一道门：游客登录保证首日转化，第三方登录（微信/QQ/手机）提供正式身份，渠道抽象让多平台接入成本最低；Token 认证以"自定义 Token + Redis"实现无状态校验与可主动失效，支撑顶号与封禁；设备绑定与防沉迷接口则分别承担账号找回与合规责任。安全上牢记一条铁律：凭证与身份校验全部在服务端完成，客户端只负责传递，这是后续所有业务系统的信任根基。