全开源电竞俱乐部打手系统源码 | 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}'"

🟠 高危问题

#	问题	详情
H1	CORS 全域名开放	cors_request_domain => '*' 允许任意域名跨域请求
H2	CSRF 防护缺失	所有 POST 接口无 CSRF Token 验证
H3	数据库弱密码	用户名密码同为 ceshi
H4	ThinkPHP 5.0.28 停更	2019年版本，已无安全更新
H5	批量罚单无限制	可对所有打手无频率限制批量发罚单
H6	前端 AppID 硬编码	微信公众号 AppID wxaea673fdf57dce75 写死在前端源码中
H7	debug 模式生产可用	.env 中 debug = true 会暴露错误堆栈

🟡 中危问题

#	问题	详情
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 改为登录+管理员