简介：一份基于uni-app + PHP + MySQL构建的在线悬赏任务平台完整源码，适合熟悉Vue与PHP的开发者快速启动任务发布/接取类APP项目。前端以uni-app实现iOS、Android、H5多端覆盖，包含任务列表、任务详情、注册登录、发布接取等核心模块；后端采用PHP 7.2配合宝塔面板部署，处理API请求与用户认证，并需安装fileinfo扩展，数据库选用MySQL 5.6且附带SQL初始化脚本。压缩包共5884个文件、约168.5MB，主要以php、png、js、html、jpg、gif等类型构成，涵盖后端逻辑、界面素材与前端交互代码，目录结构完整。已通过核心功能验证，任务发布、接取、完成提交及赏金支付均可正常运行，同时也有助于学习多端应用架构设计与PHP服务端开发。目前已有1045人学习参考，适合作为二次开发或教学研究的项目起点。
1. 蓝色任务悬赏系统源码：从需求到落地，先看清这套 uni-app + PHP 能做什么
做外包这些年，我接过不少「接任务、发任务」的需求，小到社区跑腿，大到企业内部的工单流转，业务叫法五花八门，抽出来就三板斧：谁发布、谁接单、怎么结算。这套「情义2022最新蓝色任务悬赏系统APP源码完整版」正好把这三板斧打包成了可直接编译的 uni-app 前端和 PHP 后端，任务发布、抢单、审核、余额提现都有现成页面，配色是蓝色主调，后台管理也带。你拿到的不是一份半成品 Demo，而是一套能装到服务器上跑、能通过 HBuilderX 打包成 Android/iOS APP 的完整工程。想省掉从零搭前后端的工作量，或者想找一个能改造成接单平台基座的源码，这套值得下载下来拆一遍。
2. 先拆功能边界：任务悬赏系统的核心模块与数据库设计
2.1 用户端与发布端：一个池子接住三类角色
拿到源码第一件事，别急着部署，先把它的人机交互边界理清楚。这套系统里其实跑着三类角色：普通用户（接单者）、发布者（悬赏人）、平台管理员。一个账号体系内用user_type字段区分，前端注册时不强制选择，发布任务时会自动要求补全实名信息。这个设计比直接分三个注册入口要省事——用户的决策成本低，后台的审核链路也短。
看前端 pages 目录能发现，用户端首页是任务大厅，按悬赏金额排序，带分类筛选；任务详情页里能看到发布者的信用分、任务剩余时间、当前参与人数。发布端的核心是「发布任务」页，表单支持标题、描述、分类、悬赏金额、截止时间，还带一个上传附件的功能，附件提交后端会存到uploads目录。管理后台是单独一套 HTML 模板，不走 uni-app，直接由 PHP 渲染，登录入口在/admin下。
提示：代码里用户端和管理端是两个入口，域名根目录指向前台 APP 的接口，后台管理在
admin子目录。别把它俩改成同一个入口，Session 的读取范围不一样，混在一起会出登录态串号的问题。
2.2 任务生命周期与状态机设计
任务状态是整个系统的核心命脉，源码里用的是状态机而不是简单的 status 字段。我从 mysql 表结构和控制器代码里把状态流捋出来，大概是下面这条链：
pending（待审核）→ongoing（进行中）→submitted（待验收）→completed（已完成）
另外还有两个终点状态：canceled（已取消）和failed（未达标）。最容易被忽略的是submitted状态——接单者点「交付任务」后，任务并不会直接完成，而是等发布者确认。发布者可以「通过验收」或「驳回重做」，驳回后任务回到ongoing，但会记录一次reject_count，超过三次系统自动转人工审核。
这里有个设计细节值得抄：任务的超时处理不是用定时器，而是每次查询任务列表时用WHERE deadline > NOW()过滤，再配合一个 Cron 脚本把所有过期且无人领取的pending任务批量置为canceled。为什么不完全依赖触发器和事件？因为 MySQL 的 event 在搬库时经常被遗漏，而 PHP 侧的判断在代码层面可控，排错也直观。
2.3 数据库表结构：从任务表到订单流水，字段设计里的细节
这套源码的数据库文件在db目录下，导入后主要表有这几张：user、task、task_order、wallet、wallet_log、category、config。我重点说三张容易被忽略的表。
第一是task_order，它不只是记录谁领取了任务，还有一个status字段单独走接单侧的状态流。任务本身的状态和接单的状态是分开的两个字段，初读源码时我一度把两者理解成一个状态，后来发现不对：一个任务可以被多人领取（源码默认允许 3 人报名），但只有第一个交付验收通过的才算完成，其他人自动落选。这个「一任务多领取、按交付先后来结算」的模型在接单平台里很常见，比一对一模型热闹得多，但也给后面的订单金额计算埋了坑。
第二是wallet_log，它是所有金额变动的流水表。源码在余额变动时坚持「先写流水，再改余额」，流水里记录了user_id、change_amount、before_balance、after_balance、type、related_order_no。这六个字段缺一不可，特别是before_balance和after_balance，没有它们，对账就是一笔糊涂账。
第三是config表，平台的佣金比例、提现门槛、最低发布金额都存在这里。系统没有把佣金比例写死在代码里，而是每次调用时动态读取，这就意味着运营可以在后台改数值而不用动一行代码。
CREATE TABLE `task_order` ( `id` int(11) NOT NULL AUTO_INCREMENT, `task_id` int(11) NOT NULL COMMENT '任务ID', `user_id` int(11) NOT NULL COMMENT '接单用户ID', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0待执行 1已交付 2已通过 3已驳回 4已取消', `submit_desc` varchar(255) DEFAULT NULL COMMENT '交付说明', `submit_file` varchar(255) DEFAULT NULL COMMENT '交付附件', `created_at` datetime DEFAULT NULL, `updated_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `task_id` (`task_id`), KEY `user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这张表是任务接单模型的基础。注意task_id和user_id都建了索引，因为查询高频是「某个任务有谁接了」和「某个用户接了哪些任务」，没有索引的话一旦数据量到几万行，列表接口就要开始超时。status字段虽然是单值，但在管理后台筛选时需要它做条件查询，我实际用下来觉得还可以再补一个idx_status，源码没给，二次开发时可以自己加上。
3. 部署 PHP 后端：从环境准备到接口联调
3.1 环境要求与目录结构
这套 PHP 后端不依赖框架，核心是原生 PHP 写的 API，外加一个admin目录放管理后台。部署环境我建议用 Nginx 1.20 + PHP 7.4 + MySQL 5.7，这个组合最稳。源码里有几处代码用了 PHP 7 的语法特性，如果拿 PHP 5.6 去跑会直接白屏；反过来用 PHP 8.2，又会因为部分老写法触发 Deprecated 警告。所以 7.4 是这套源码的最优解。
拿到压缩包解压后，目录结构是这么一回事：
api/public/index.php：前端接口的入口文件，所有/api开头的请求都走这里api/config/database.php：数据库连接配置api/controllers：按控制器拆分的业务逻辑api/models：数据模型admin：管理后台的前端页面和 PHP 脚本db/task_db.sql：数据库初始化脚本uploads：用户附件存储目录
这份源码走的是「单入口 + 路由映射」模式，index.php里根据r参数分发到对应的 controller 方法。比如请求/api/index.php?r=task/list，代码就会去找TaskController::actionList()。这套模式比纯 RESTful 简单，调试时也容易定位问题，不用在 Nginx 层做太复杂的 rewrite 配置。
3.2 配置数据库连接与站点伪静态
部署的第一步是建库导数据。用命令行导入是最不容易出错的，图形化工具在导入大 SQL 时经常断在半路。
mysql -uroot -p < db/task_db.sql导入完成后验证一下表是否齐全，重点看有没有task_order和wallet_log这两张表，很多精简版源码会故意砍掉它们，砍掉之后整个结算链路就不完整了。然后在api/config/database.php里修改连接信息：
return [ 'host' => '127.0.0.1', 'port' => 3306, 'dbname' => 'task_db', 'username' => 'root', 'password' => 'your_password', 'charset' => 'utf8mb4', ];这段配置说明一下：host如果 Web 服务和数据库在同一台服务器，建议写127.0.0.1而不是localhost，因为某些系统下 PHP 的 PDO 会把localhost解析成 unix socket，走不了 TCP 连接，导致连不上。charset必须用utf8mb4，任务描述里用户可能输入 Emoji 表情，用utf8会在写入时直接报错或乱码。
Nginx 站点配置里，根目录指向api/public，并加一段伪静态规则，把不存在的文件请求全部交给 index.php 处理：
server { listen 80; server_name your-domain.com; root /path/to/api/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }try_files这行是关键，它把路由重写的压力交给了 PHP，前端不管请求什么路径，只要不是真实文件，全部进 index.php。有同学喜欢用 Apache，那就在.htaccess里写RewriteRule ^(.*)$ index.php [L]，效果一样。
3.3 用 curl 验证接口链路
后端配好后，先别急着打开 APP，用 curl 走一遍接口更能看清楚问题出在哪一层。我习惯的验证顺序是：注册用户、登录拿 token、拉任务列表。
curl -X POST http://your-domain.com/api/index.php?r=user/register \ -H "Content-Type: application/json" \ -d '{"username":"test001","password":"123456","nickname":"测试"}'如果返回 JSON 里带着code: 0和data.user_id，说明数据库连接和控制器路由都通了。接着登录：
curl -X POST http://your-domain.com/api/index.php?r=user/login \ -H "Content-Type: application/json" \ -d '{"username":"test001","password":"123456"}'登录接口会返回一个 token，后面的请求都需要在请求头带上Authorization: Bearer <token>。这里有个常见的坑：源码里判断请求头用的是$_SERVER['HTTP_AUTHORIZATION']，Nginx 默认会把这个头透传，但如果你的 Nginx 配置了 fastcgi 参数没包含它，PHP 侧就收不到。
curl -X GET "http://your-domain.com/api/index.php?r=task/list&page=1&page_size=10" \ -H "Authorization: Bearer <token>"任务列表能拉到数据，说明整个接口链路已经通了。到这里后端部署就算成功了大半，剩下的坑集中在 APP 打包和真机环境上，放到第五章专门说。
4. 运行 uni-app 前端：HBuilderX 编译到 APP 的完整流程
4.1 拿到源码后的前端目录说明
前端是标准的 uni-app 工程，用 HBuilderX 打开根目录就能直接识别。目录里有几个关键位置需要注意：
pages/index/index.vue：任务大厅pages/task/detail.vue：任务详情pages/publish/publish.vue：发布任务pages/user/center.vue：个人中心api/request.js：封装了 uni.request 请求方法，全局接口地址都在这config.js：站点配置
打开api/request.js，能看到它做了一件很重要的事：在请求头里统一注入 token，并且在返回码为 401 时自动跳转登录页。这个封装值得保留，后续二次开发时新增接口直接在api/目录下加方法就行，不用每个页面都重新写请求逻辑。
4.2 修改接口地址与打包配置
接口地址集中在config.js文件里，我拆到的这个版本的写法是这样：
export default { baseUrl: 'http://your-domain.com/api/index.php?r=', imageBaseUrl: 'http://your-domain.com/uploads/', appId: 'wx1234567890', appSecret: 'your-app-secret' }baseUrl是前后端联调的命门。开发调试时如果你用模拟器，your-domain.com不能写localhost，因为 Android 模拟器里的localhost指向它自己，不是你的电脑。要写你电脑在局域网里的 IP，比如http://192.168.1.100/api/index.php?r=。
打包配置在manifest.json里，需要改的主要是这几项：
- 基础配置里的应用名称、版本号
- App 图标：源码自带一套蓝色图标，但默认尺寸不一定符合渠道要求，建议直接用 1024x1024 的 png 重新生成一套
- 权限配置：需要勾选网络访问、存储权限。如果任务附件要调用相机相册，还要把相机权限和相册权限都勾上
云打包时有一个细节：证书指纹（SHA1）在每次云打包后会变，如果你接了微信登录或分享，需要把新的指纹回填到微信开放平台。这是个很典型的上线流程坑，打包前最好把指纹先固定下来。
4.3 真机调试与云打包注意事项
HBuilderX 的真机调试功能比模拟器好使，因为 APP 里的网络请求不会受开发机的代理影响，能看到更真实的表现。插上手机，开启开发者模式的 USB 调试，运行到手机即可。这个阶段最常见的报错是request:fail，十有八九是baseUrl配错或者没有在 manifest.json 里申请网络权限。
真机调试通了之后，再走云打包。云打包填写的包名com.xxx.taskapp要用你自己的域名反写，Android 各应用市场要求包名唯一，且后续更新包必须用同一个平台证书。这里的血泪经验是：第一次云打包就生成并保存好私钥，万一弄丢了证书，应用市场里那个抱着几万用户的 APP 就永远无法更新了。
打包完成后的产物是一个apk文件，iOS 因为证书和描述文件机制门槛更高，源码里虽然支持ios端，但上架还需要开发者账号、描述文件配置、以及处理支付 - 审核相关的合规字段。做外包交付时，我一般建议先安卓包交付演示，iOS 上架作为后续付费项，免得卡死在账号环节。
5. 避坑手册：部署这套悬赏系统最常见的 5 个翻车点
5.1 现象：接口 404，登录页能开但无法注册
现象是 HBuilderX 里页面能打开，但每次注册都提示「接口不存在，请稍后重试」。打开浏览器 DevTools 看请求，发现请求的 URL 是http://your-domain.com/index.php?r=user/register，掉了一个/api路径。
原因是 baseUrl 没按源码默认路径配对。源码接口统一规划在api/public/index.php下，如果你 Nginx 的 root 不自带/api这个路径前缀，前端就必须在 baseUrl 里补全。解决方法是保证config.js里的baseUrl和 Nginx 实际监听的路径一致，写完之后在浏览器里直接访问你的域名/api/index.php?r=task/list，能返回 JSON 再往下走。
5.2 现象：任务列表为空，后台却有数据
后台管理里能看到发布者创建的任务，状态也是ongoing，但 APP 首页的任务列表永远返回空数组。
最后定位到问题出在任务列表的 SQL 查询里，它带了一个is_hidden过滤条件。后台审核通过后的任务默认is_hidden=0，但如果发布者发布任务时没有走完「支付」流程，源码会在事务里把任务悄悄置为is_hidden=1；而 MySQL 的事务隔离级别若是READ COMMITTED，外部读到的就是被隐藏的数据。解决方式是去后台「任务管理 - 回收站」里看看有没有被隐藏的数据，有就恢复；没有的话直接用 sql 检查task表里is_hidden字段的值分布。
提示：遇到列表为空先别改代码，先执行
SELECT status, is_hidden, COUNT(*) FROM task GROUP BY status, is_hidden;，把数据的真实分布看清楚，再判断是逻辑问题还是数据问题。
5.3 现象：APP 打包后请求被拦截，证书校验失败
真机调试时接口全通，打好正式包发出去后用户反馈所有请求都失败。看日志发现是 SSL 证书链问题。
原因是源码在request.js里默认开了sslVerify: false，真机调试时绕过证书验证能跑通，但云打包时平台强制了证书校验策略或个人签名未配置正确。解决方式是先确认服务器部署的是完整证书链，把nginx.conf里的证书链配置补上；然后再把request.js里的sslVerify改成true。如果服务器没有正式的 HTTPS 证书，只靠未校验的模式上线，很大概率在应用市场审核时被拒。血的教训是：别为了省一张证书的钱，浪费了整个提审周期。
5.4 现象：PHP 7.4 下报错，代码用了 5.x 的写法
部署到 PHP 7.4 环境，打开页面出现Function mysql_* is deprecated或者白屏。这个现象是源码的历史包袱，部分老代码用了已经被移除的mysql_connect系列函数。
原因是这套源码的数据库层在 PHP 5 时代起步，虽然大部分代码已经迁移到了 PDO，但个别管理员接口里还残留旧函数。解决方式是全局搜索mysql_前缀函数，把老接口逐段改成 PDO 预处理写法；搜索global $db这种写法的地方也顺手换掉。如果只是自己学习用，直接用 PHP 5.6 环境跑也行，但线上交付我建议还是动一遍 PDO 迁移，否则后续加新功能时写的代码风格会跟源码脱节。
5.5 现象：任务发布成功但余额没扣，订单状态错乱
发布者发布任务后，页面显示「发布成功」，但钱包余额没变化，任务详情页里订单号也不对。这个问题的定位思路：发布任务的业务逻辑里，理论上有三个动作必须在一个事务里完成——创建任务、冻结余额、写钱包流水。源码中有一个提交顺序缺陷，余额扣款走的是异步写日志，异常时又不回滚任务状态。
解决方式是检查TaskController::actionCreate()是否包在PDO::beginTransaction()和commit()里。我通常会在钱包扣款、任务创建、流水记录三条语句执行完之前不允许任何一次commit，并在catch块里执行rollback()。遇到现有源码没做事务的，自己补一层也不难，关键是做好这之后，再加上一条针对钱包流水的对账脚本。
try { $pdo->beginTransaction(); // 创建任务 $taskId = createTask($data); // 扣减余额 $walletResult = deductWallet($userId, $amount); if (!$walletResult) { throw new Exception('余额不足'); } // 写钱包流水 insertWalletLog($userId, -$amount, $before, $after, 'task_publish'); $pdo->commit(); } catch (Exception $e) { $pdo->rollBack(); // 记录日志，返回错误提示 }这段是补事务的核心写法。注意deductWallet返回 false 时一定要先抛异常再回滚，否则前一步创建的任务已经插进了数据库，但余额没扣，后台对账就永远对不上。
6. 把这套系统用到真实项目里：二次开发顺序与上线前验证清单
6.1 二次开发的首选顺序
这套源码的最大价值不是直接上线，而是当一个悬赏接单平台的基座。如果我要拿它接一个真实项目，二次开发我会按这个顺序推进：先加「实名认证」和「人工审核」流程，再做「提现打款」的对接，最后才考虑 UI 定制和性能优化。为什么认证要最先做？因为任务悬赏的核心是信任，没有实名第一道门槛，平台里会迅速出现羊毛党和骗术表演者。
单说提现对接：源码的wallet表目前是虚拟币设计，提现流程走到「待打款」就是终点。要接真实打款，需要在wallet_log的type字段上扩展withdraw类型，并新增一张withdraw_record表，记录银行卡号、开户行、真实姓名、申请时间、打款时间、打款状态。这块建议新老数据共存而不是改结构，避免影响对账。
6.2 上线前必跑的验证用例
源码本身没有测试用例，所以上线前我强烈建议自己走一遍核心链路。先注册一个新账号，发布一个 1 元悬赏任务，确认钱包余额减少 1 元且流水记录正确；然后用第二个账号抢单、交付，再用第一账号验收通过，确认第一账号的钱包余额恢复、第二账号钱包增加悬赏金额减去平台佣金。这中间如果哪一步对不上，优先去看wallet_log表里的before_balance和after_balance。
第二组用例是并发场景。开两个客户端同时抢同一个人数上限为 1 的任务，正确结果是只有一个成功、一个失败。如果不做并发控制，可能同一任务被领取两次，后续交付时就有得吵了。源码里用的是UPDATE task SET accept_count = accept_count + 1 WHERE id = ? AND accept_count < limit_count这种乐观锁写法，我实测过并发请求下不容易出问题。第三组用例是异常流程：任务过期后隔一天再登录 APP，确认任务已变更为「已取消」，且发布者的余额已自动退回钱包并产生了流水记录。
6.3 从这套源码里学到的三个工程习惯
拆完这套源码，我留在项目里的不只是部署记录，还有三个每次写后台系统都会遵守的习惯。第一个是金额操作必须留审计日志，任何余额变化都要能回答「谁、在什么时间、因什么订单、变了多少」；第二个是状态流转只允许单向推进，拒绝从「已完成」跳回「进行中」，所有回退动作都走新的状态标签而不是改旧字段；第三个是给所有对外接口加上分配性和速率控制，任务列表接口我在二次开发时就让它默认支持分页和关键词搜索，而不是把所有数据一次性倒给客户端。
还有一个小技巧值得分享：这套源码的config表是动态读取的，运营改佣金比例后，APP 端佣金展示用的接口会带上一个ver参数做缓存刷新。我后来给接单列表页加了个下拉刷新，顺手把缓存策略也调整成了「每次下拉刷新都强制拉取最新配置」。从那以后我每次部署新后端，都会先看一眼它的配置表到底是自动缓存还是每请求全量查库，再决定要不要做 Redis 缓存这一层。希望帮到你。
本文还有配套的精品资源，点击获取
