
游戏陪玩这个赛道,技术门槛其实不高,但业务逻辑比较复杂。
用户、店员、客服、管事、工作室,五个角色各有一套操作流程,订单状态流转、分账逻辑、上下级绑定,稍不注意就容易写成一堆if-else的泥潭。
最近用ThinkPHP6+Uniapp重构了一套代练系统,把一些设计和实现思路整理出来,希望对大家有帮助。
后端:ThinkPHP6
前端:Uniapp
管理后台:TH6
这个系统有5种角色,每种角色看到的菜单和能操作的接口都不一样。
用户表设计思路:
// users表
id
username
password
mobile
role_type // 1用户 2店员 3客服 4管事 5工作室
status
create_time但光靠role_type不够,因为店员有等级、保证金字段,管事和工作室有上下级关系,所以用了用户主表+角色扩展表的设计:
users:基础账户信息players:店员扩展表(等级、保证金、审核状态)managers:管事扩展表(上级ID、缴费状态)studios:工作室扩展表(邀请码、邀请人数)权限控制: TP6的中间件派上用场了,每个请求先过中间件,判断角色类型和接口权限。
// 中间件示例
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);
}店员订单的状态流转比普通电商订单复杂一些:
发单(待接单)
→ 已接单(店员接单/客服派单)
→ 进行中(店员上传截图)
→ 待验收(客服审核)
→ 已完成(验收通过)
→ 已结算(分账完成)还有一些边界状态:用户取消、客服驳回、订单申诉等。
实现方式: 用状态模式,每个状态定义允许的操作和下一个状态。
店员端有个抢单功能,多个店员同时点抢单,不能出现超抢。
方案: Redis分布式锁 + 数据库事务
工作室和管事都有邀请码功能,通过邀请码注册的用户自动绑定关系。
数据结构:
/
绑定关系表:
// user_relations表
id
parent_user_id // 上级ID
child_user_id // 下级ID
relation_type // 关系类型(工作室-用户 / 管事-打手)
create_time注册流程里加个判断:
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. 微信登录
2. 支付
核心表结构:
表名 | 说明 |
|---|---|
users | 用户表 |
players | 店员表 |
orders | 订单表 |
withdrawals | 提现表 |
invite_codes | 邀请码表 |
user_relations | 关系表 |
commission_logs | 分账日志 |
需要演示或源码的朋友可以评论留言或私信。
这套系统的难点不在于某个技术点有多难,而在于把五个角色的业务逻辑理顺,保证订单流转不出错,分账逻辑清晰。
用TP6+Uniapp组合,开发效率确实高,一套前端代码搞定多端,后端用TP6快速实现业务。
如果正在考虑做类似的平台,希望能给你一些参考。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。