全开源电竞俱乐部打手系统源码 | Uniapp 电竞陪玩护航接单平台源码

审计日期：2026-06-05

---

一、系统概述

电竞护航 是一个电竞陪玩/代练服务平台，连接”玩家”（下单方）和”打手”（接单方），提供商品购买、打手接单、在线支付、实时通讯等服务。

核心业务流程

玩家下单 → 打手接单 → 开始服务 → 完成服务 → 玩家确认 → 佣金结算                                                      ↓                                                 双层分佣（上级/上上级）

---

二、技术栈

层次	技术
前端框架	UniApp (Vue3 + Vite)
前端 UI	uview-plus 3.4.40 + uv-ui 1.1.20
后端框架	FastAdmin 1.6.0 (ThinkPHP 5.0.28)
数据库	MySQL (utf8mb4, 44张表)
支付	微信支付 V2/V3 + 易支付（三方聚合）+ 余额支付
短信	阿里云短信 (alisms)
第三方登录	微信登录、QQ登录
即时通讯	香白城 IM（第三方服务）

---

三、功能模块

3.1 前端页面（40+ 页）

首页 ── 轮播图、商品列表、分类导航分类 ── 综合浏览 / 热销排行榜消息 ── 官方公告 / 订单通知 / IM聊天个人中心 ── 个人信息、订单、余额、会员等级、分销、入驻打手端 ── 接单大厅、打手主页、打手订单、排行榜购买流程 ── 搜索 → 商品详情 → 下单 → 收银台管理 ── 提现、保证金、罚单、售后、投诉

3.2 后端 API（约 60 个接口）

模块	接口数	主要功能
Index	7	轮播图、公告、等级、配置、客服
Common	4	初始化、上传、验证码、微信JS-SDK
User	23	登录注册、信息管理、提现、分销、充值
Goods	20	商品、订单、评论、抽奖、投诉、退款
Thug	15	打手申请/接单/服务/提现/排行
Fine	6	发罚单、缴纳、检查、撤销
Payment	2	支付方式、配置查询
Sms	2	发送/验证短信验证码
Im	2	IM授权、创建会话

3.3 数据库（44 张表）

核心业务表：

• fa_user — 用户表（含余额、积分、上级pid等）
• fa_thug — 打手表（含审核、保证金、评分）
• fa_goods — 商品表（含虚拟销量、活动价）
• fa_order — 订单表（订单状态、价格、打手关联）
• fa_goods_category — 商品分类（两级分类）
• fa_goods_comment — 商品评价

资金相关表：

• fa_user_money_log — 金额变动日志（核心流水表）
• fa_user_balance_log — 余额日志
• fa_user_score_log — 积分日志
• fa_thug_commission_log — 打手佣金日志
• fa_balance_recharge_order — 余额充值订单
• fa_withdrawal — 提现记录
• fa_bond — 保证金记录
• fa_user_reward — 打赏记录

运营相关表：

• fa_lunbo — 轮播图
• fa_notice — 公告
• fa_level — 会员等级
• fa_customer_service — 客服配置
• fa_payment_method — 支付方式
• fa_thug_fine — 打手罚单
• fa_order_complaint — 订单投诉
• fa_jackpot — 抽奖奖品

---

四、安全审计

🔴 严重问题【已修复】

#	问题	详情
S1	无管理员权限校验	发罚单(fineCreate)、退款审核(orderRefundAudit) 等关键管理操作仅靠登录认证，无管理员角色判断
S2	订单自动确认接口未授权	orderAutomatic 设为 noNeedLogin，任何人都可以触发所有超时订单的自动确认
S3	支付密钥硬编码	微信V2密钥 28reGoO22j2p2oEhGv2GES28SOoO2O2D 和易支付密钥 EDUbEaewZPueixiXJxip6jYPI1kesXeD 直接写在配置文件中
S4	SQL注入风险	balanceLog 中拼接表名查询 "SHOW TABLES LIKE '{$tableName}'"

🟡 中危问题

#	问题	详情
M1	抽奖用 mt_rand() 可被预测	应使用 random_int()
M2	无参数白名单校验	大部分接口依赖简单的 input('param/d') 类型转换
M3	无 API 频率限制	登录、短信、下单等接口可被暴力调用
M4	分佣比例无上限校验	distribution 设为 100 即全部分成
M5	无敏感操作审计日志	罚款、退款、提现等操作无统一日志
M6	订单号用 mt_rand 生成	可预测且有碰撞风险
M7	前端 Token 明文存储	uni.getStorageSync('token') 明文
M8	z-index 层叠问题	18+ 个页面存在 *-box-bg 用 z-index: 0 可能导致内容被遮盖（类 classfiy 页面的问题）

---

五、代码质量审计

前端

• 组件注册不一致：main.js 中 camelCase 命名，模板 kebab-case
• 重复请求：onShow 和 onMounted 都调用数据加载，页面切换时重复请求
• 错误处理不一致：有的页面有 res.data.data 防御判断，有的直接取值
• 目录名拼写错误：compontents 应为 components
• 配置文件残留：旧域名注释未清理

后端

• API 模块无 Validate 验证器类：所有参数验证散落在控制器内
• 异常处理不规范：try-catch + $this->error 散见各处
• 部分方法注释错误/缺失
• 大量冗余的 $noNeedRight = ['*']：所有登录用户拥有所有权限，相当于无权限体系

---

六、架构建议

短期（可立即修复）

1. 移除 orderAutomatic 的 noNeedLogin，改为后端定时任务
2. 支付密钥从配置文件迁移到数据库 fa_config 表
3. 给 fineCreate、orderRefundAudit 增加管理员权限校验
4. 统一将 *-box-bg 的 z-index: 0 改为 z-index: -1
5. 前端 AppID 改为接口动态获取

中期

1. 引入 API Validate 验证器体系
2. 添加 API 频率限制中间件
3. 关键操作添加审计日志
4. 提现流程增加风控判断
5. 订单号改用 UUID 生成

长期

1. 升级 ThinkPHP 到 6.x 获取安全更新
2. 引入 Redis 做分布式锁（余额/接单防并发）
3. 前后端分离+接口签名校验
4. 生产环境禁用 debug，开启 HTTPS

---

七、修复内容

这套系统功能完整、业务逻辑清晰，核心流程（下单→接单→服务→确认→分佣）运转正常，支付渠道多样。主要问题集中在安全防护层面：

• 支付密钥和敏感配置硬编码需要优先解决
• 管理权限几乎是”登录即管理员”的状态
• 前端也有 18+ 页面可能存在类似 classify 的 z-index 遮盖问题需要一并修复

1：发罚单/撤销罚单 — 加管理员权限

2：支付密钥迁移到数据库

3：SQL注入修复

4：orderAutomatic 改为登录+管理员