前言
游戏陪玩这个赛道，技术门槛不高，但业务复杂度不容小觑。用户、店员、客服、管事、工作室五个角色，各有各的操作流程和权限边界；订单状态流转、分账逻辑、上下级绑定，稍有不慎就容易写成面条代码。
最近用 ThinkPHP6 + Uniapp 重构了一套陪玩系统，把业务逻辑理顺了。这篇文章不吹不黑，纯粹分享技术设计和实现思路，希望对正在做类似项目的朋友有帮助。
一、业务模型梳理
1.1 五个角色，五种视角
用户（发单人） → 发单、选店员、看进度
店员（接单人） → 抢单、打单、上传截图、提现
客服（调度人） → 派单、验收截图、线下报单
管事（管理者） → 带团队、看收入、提现
工作室（运营方）→ 邀请码裂变、分配订单、管团队
每个角色看到的数据和能做的操作完全不同，这是权限设计的核心出发点。
1.2 核心业务流程
→ 派单/抢单（客服/店员）
→ 接单（店员）
→ 上传截图（店员）
→ 验收（客服）
→ 结算（系统自动分账）
中间穿插着：
✅线下报单（客服录入线下收款订单）
✅邀请绑定（管事/工作室通过邀请码拉新）
✅抽奖活动（下单后抽奖）
✅协助打单（店员邀请其他店员帮忙）
二、技术选型：为什么是 TP6 + Uniapp？
2.1 后端：ThinkPHP 6
选 TP6 的理由很朴实：
✅文档完善：遇到问题基本都能查到
✅ORM 顺手：关联查询写起来不费劲
✅中间件机制：做权限控制很方便
✅命令行工具：快速生成模块，开发效率高
2.2 前端：Uniapp
核心诉求是一套代码覆盖多端：
✅微信小程序（流量大头）
✅微信公众号（H5 方便分享）
✅APP（iOS/Android 打包）
✅PC 管理端（后台用 TH6）
Uniapp 的条件编译确实好用，各端差异化需求都能处理。
2.3 管理后台：TH6
基于 TP6 的后台框架，自带权限管理和菜单生成，快速搭出数据管理界面。
三、数据库设计：用户与角色的解耦
3.1 用户表设计
CREATE TABLE `users` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`mobile` varchar(11) DEFAULT '',
`openid` varchar(64) DEFAULT '',
`role_type` tinyint(4) DEFAULT '1' COMMENT '1用户 2店员 3客服 4管事 5工作室',
`status` tinyint(4) DEFAULT '1',
`create_time` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
);
但光靠 role_type 不够——店员有等级、保证金字段，管事有上级 ID、缴费状态。所以用了主表 + 扩展表的模式：
3.2 邀请码与上下级绑定
3.3 订单表设计
四、核心功能实现
4.1 多角色权限控制（TP6 中间件）
4.2 订单状态机
用状态模式管理订单流转，避免到处写 if-else：
4.3 抢单的并发处理
多个店员同时抢一个订单，不能超抢。用 Redis 分布式锁：
4.4 邀请码裂变机制
注册时处理邀请码绑定：
五、前端 Uniapp 多端适配
5.1 条件编译处理各端差异
5.2 图片上传封装
六、部署与打包
6.1 环境要求
✅PHP 7.4+（推荐 8.0）
✅MySQL 5.7+
✅Nginx/Apache
✅Redis（用于锁和缓存）
6.2 多端打包
✅小程序：HBuilder X 直接上传
✅H5：编译后部署到服务器
✅APP：云打包或本地打包
七、总结
这套系统的核心难点不在技术栈本身，而在于把五个角色的业务逻辑理顺，保证订单流转不出错，分账逻辑清晰。
TP6 负责稳，Uniapp 负责快，两者结合开发效率确实高。如果正在考虑做类似平台，希望这篇文章能给你一些参考。
源码说明：开源，支持二次开发。需要演示或源码的朋友欢迎评论或留言相互交流。
