首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >游戏陪玩系统实战|多端同步|多角色权限设计

游戏陪玩系统实战|多端同步|多角色权限设计

原创
作者头像
DK l8583832252
发布2026-03-12 16:26:52
发布2026-03-12 16:26:52
70
举报

写在前面

游戏陪玩这个赛道,技术门槛其实不高,但业务逻辑比较复杂。

用户、店员、客服、管事、工作室,五个角色各有一套操作流程,订单状态流转、分账逻辑、上下级绑定,稍不注意就容易写成一堆if-else的泥潭。

最近用ThinkPHP6+Uniapp重构了一套代练系统,把一些设计和实现思路整理出来,希望对大家有帮助。


一、技术选型为什么是TP6+Uniapp

后端:ThinkPHP6

  • 文档完善,生态成熟
  • 中间件机制方便做权限控制
  • ORM用起来顺手,关联查询写起来不费劲
  • 命令行工具支持快速生成模块

前端:Uniapp

  • 一套代码,多端编译(小程序/H5/APP)
  • 条件编译解决各端差异化问题
  • 打包方便,HBuilder X点几下就行
  • 社区活跃,遇到问题基本都能搜到解决方案

管理后台:TH6

  • 基于TP6的后台框架
  • 自带权限管理、菜单生成
  • 快速搭建数据表管理界面

二、多角色权限设计

这个系统有5种角色,每种角色看到的菜单和能操作的接口都不一样。

用户表设计思路:

代码语言:txt
复制
// users表
id
username
password
mobile
role_type  // 1用户 2店员 3客服 4管事 5工作室
status
create_time

但光靠role_type不够,因为店员有等级、保证金字段,管事和工作室有上下级关系,所以用了用户主表+角色扩展表的设计:

  • users:基础账户信息
  • players:店员扩展表(等级、保证金、审核状态)
  • managers:管事扩展表(上级ID、缴费状态)
  • studios:工作室扩展表(邀请码、邀请人数)

权限控制: TP6的中间件派上用场了,每个请求先过中间件,判断角色类型和接口权限。

代码语言:txt
复制
// 中间件示例
public function handle($request, \Closure $next)
{
    $user = $request->user;
    if (!$user) {
        return json(['code' => 401, 'msg' => '未登录']);
    }
    
    // 根据角色类型校验接口权限
    $current_route = $request->route()->getPath();
    if (!in_array($current_route, $this->rolePermissions[$user['role_type']])) {
        return json(['code' => 403, 'msg' => '无权限']);
    }
    
    return $next($request);
}

三、订单流程的状态机设计

店员订单的状态流转比普通电商订单复杂一些:

代码语言:txt
复制
发单(待接单) 
  → 已接单(店员接单/客服派单) 
  → 进行中(店员上传截图) 
  → 待验收(客服审核) 
  → 已完成(验收通过) 
  → 已结算(分账完成)

还有一些边界状态:用户取消、客服驳回、订单申诉等。

实现方式: 用状态模式,每个状态定义允许的操作和下一个状态。

四、抢单模式的并发处理

店员端有个抢单功能,多个店员同时点抢单,不能出现超抢。

方案: Redis分布式锁 + 数据库事务

五、邀请码裂变的实现

工作室和管事都有邀请码功能,通过邀请码注册的用户自动绑定关系。

数据结构:

/

绑定关系表:

代码语言:txt
复制
// user_relations表
id
parent_user_id    // 上级ID
child_user_id     // 下级ID
relation_type     // 关系类型(工作室-用户 / 管事-打手)
create_time

注册流程里加个判断:

代码语言:txt
复制
if ($inviteCode) {
    $invite = InviteCodeModel::where('code', $inviteCode)->where('expire_time', '>', time())->find();
    if ($invite) {
        // 创建绑定关系
        UserRelationModel::create([
            'parent_user_id' => $invite['user_id'],
            'child_user_id' => $newUserId,
            'relation_type' => $invite['role_type'] == 4 ? 'manager_player' : 'studio_user'
        ]);
    }
}

六、多端打包的一些坑

1. 微信登录

  • 小程序用uni.login() + 后端解密
  • 公众号用OAuth2
  • APP用微信开放平台

2. 支付

  • 小程序支付调起方式不同
  • H5用公众号支付
  • APP用APP支付

七、数据库设计要点

核心表结构:

表名

说明

users

用户表

players

店员表

orders

订单表

withdrawals

提现表

invite_codes

邀请码表

user_relations

关系表

commission_logs

分账日志


八、源码说明

  • 开源,支持二次开发
  • 后台可配置店员等级、保证金、分账比例

需要演示或源码的朋友可以评论留言或私信。


九、总结

这套系统的难点不在于某个技术点有多难,而在于把五个角色的业务逻辑理顺,保证订单流转不出错,分账逻辑清晰。

用TP6+Uniapp组合,开发效率确实高,一套前端代码搞定多端,后端用TP6快速实现业务。

如果正在考虑做类似的平台,希望能给你一些参考。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 写在前面
  • 一、技术选型为什么是TP6+Uniapp
  • 二、多角色权限设计
  • 三、订单流程的状态机设计
  • 四、抢单模式的并发处理
  • 五、邀请码裂变的实现
  • 六、多端打包的一些坑
  • 七、数据库设计要点
  • 八、源码说明
  • 九、总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档