简介：最新商业视频打赏系统源码提供完整的前后端实现与运营功能，面向需要快速上线视频打赏、短视频裂变推广业务的站长和开发者；内置多套前端模板、代理后台并已对接支付，可支撑从内容展示、直播讲解到左右滑动式裂变分享的完整链路。系统设有5次免费播放机会，用户每推广一人增加5次播放，配合域名分流防御技术，可提升业务稳定性并降低被攻击风险。源码基于ThinkPHP6+EasyAdmin与Vue+Node.js开发，附带详细搭建教程及第三方链接配置图文说明，覆盖域名池轮换、腾讯云COS、微博、公众号、百度云等接入方式，可自行完成链接配置、避免外部高价收费，并结合SQL文件快速初始化部署。资源包为ZIP格式，共2001个文件，以1760个JS、137个HTML、23个CSS等前后端文件为主，另有63个MD说明文档及SQL文件，压缩包约54.17MB。目前已有320人学习下载，适合有一定后端基础、希望快速商用或二次开发的团队参考。
1. 商业视频打赏系统的技术底牌与选型逻辑
做泛娱乐社交产品的开发者，拿到一套号称“商业级”的视频打赏源码，第一反应通常是怀疑：它到底是套了管理后台的演示项目，还是真能支撑生产流量的完整系统？拆完这套基于 ThinkPHP6 + EasyAdmin + Vue 的源码后，我的结论是：它把裂变增长、代理分销、支付分账、域名容灾这几条业务主线都做成了可配置的模块，而不是写死的功能页。
这套系统值得关注的点不在“打赏”本身，而在于它处理了三个高频痛点：用户播放次数耗尽后如何用裂变机制拉新、代理后台的分润规则如何灵活配置、域名被拦截后如何通过接口快速切换资源链接。源码里同步提供了完整的部署教程和第三方链接配置图文指南，覆盖从服务器初始化到支付参数填写的全流程。正文涉及的 CSS 文件名如chunk-vendors.af0f3e3f.css、app.3b3bb1ef.css属于前端构建产物，说明前端采用了 Webpack 分包策略，这一细节在后续优化加载性能时还会用到。
适合阅读这篇拆解的人：正在选型短视频裂变系统的技术负责人、需要二次开发打赏系统的 PHP 工程师、以及想了解 ThinkPHP6 在真实商业项目中如何落地的开发者。我会把支付对接、代理分账、域名池轮换、播放次数控制这几个核心模块逐一拆开讲。
2. Swoole 协程常驻内存架构：为什么它能扛住高并发打赏请求
2.1 从 PHP-FPM 到常驻内存的范式切换
传统 ThinkPHP6 项目部署在 Nginx + PHP-FPM 环境下，每个请求都要经历“初始化框架 → 加载配置 → 建立数据库连接 → 执行逻辑 → 销毁资源”的完整生命周期。这套源码没有走这条老路，而是基于 Swoole 的协程能力，把 ThinkPHP6 跑在常驻内存的 Service 中。这意味着应用启动后，框架内核、数据库连接池、Redis 连接全部保持在内存里，请求到来时直接复用，跳过了重复加载。
从源码目录结构看，项目入口不再是public/index.php，而是think命令行启动文件配合 Swoole 扩展。生产环境下的典型启动命令是：
php think swoole:start -p 9501 -d-p 9501指定监听端口，-d表示守护进程模式。启动后可用ps aux | grep swoole确认进程是否存活。这套方案的核心收益是 QPS 能力的数量级提升，本地压测环境下，同样的打赏接口从 FPM 模式的几百 QPS 提升到两千以上。
2.2 协程并发模型下的编码约束
Swoole 协程虽然是同步写法，但底层是异步调度。这对业务代码提出了隐形约束，源码里的数据操作基本都走了连接池。以用户打赏后更新余额为例：
use think\facade\Db; Db::startTrans(); try { // 锁定用户余额行，防止并发覆盖 $user = Db::name('user')->lock(true)->where('id', $uid)->find(); $newBalance = bcsub($user['balance'], $amount, 2); if ($newBalance < 0) { throw new \Exception('余额不足'); } Db::name('user')->where('id', $uid)->update(['balance' => $newBalance]); Db::name('user_balance_log')->insert([ 'uid' => $uid, 'amount' => -$amount, 'type' => 'reward', 'create_time' => time() ]); Db::commit(); } catch (\Throwable $e) { Db::rollback(); }这里用lock(true)做行锁，配合事务保证余额一致。bcsub是 PHP 的任意精度函数，处理金额计算时避免浮点误差。需要注意的是，Swoole 协程下不能用sleep()做延时，必须用Swoole\Coroutine::sleep()，否则会阻塞整个 Worker 进程，源码的异步任务模块中对这类细节做了封装。
2.3 模板机制与前端构建产物的配合
EasyAdmin 后台基于 LayUI 封装，前端业务页面则走 Vue + Node.js 构建流程。源码附带的 CSS 文件名带哈希后缀（如app.3b3bb1ef.css），这是 Webpack 的内容哈希机制，好处是静态资源更新时浏览器能准确拉取新版本。如果二次开发改了前端代码，需要在项目根目录执行：
npm install npm run build构建产物会输出到public/static目录下。注意chunk-vendors这一层是公共依赖包，被多个页面复用，浏览器会单独缓存它。日常迭代中，如果只是修改了业务组件，产物通常只更新app相关的文件，无需让用户重新下载整套 JS——这也是性能优化的第一层。
提示：在 EasyAdmin 后台修改菜单名称或权限规则后，需要清理
runtime目录下的缓存文件，否则前端菜单不会刷新。
3. 裂变分享次数控制的数据流设计与防刷策略
3.1 五 + N 次的播放次数非对称逻辑
这套系统的核心裂变机制是：新用户默认获得 5 次免费播放机会，每成功邀请一位新用户点击链接，邀请者的播放次数增加 5 次。从产品逻辑上看，它刻意设计了 1:5 的投入产出比——用户邀请一个人就能看 5 个视频，沉没成本会让用户更愿意继续分享。
要实现这个逻辑，数据库里至少需要两张核心表：用户播放次数表和邀请关系表。次数变更必须走事务，避免并发下的超发。示例数据结构如下：
CREATE TABLE `user_play_count` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `uid` INT UNSIGNED NOT NULL COMMENT '用户ID', `total_count` INT NOT NULL DEFAULT 5 COMMENT '总播放次数', `used_count` INT NOT NULL DEFAULT 0 COMMENT '已用次数', `invite_count` INT NOT NULL DEFAULT 0 COMMENT '累计邀请人数', `update_time` INT NOT NULL, UNIQUE KEY `idx_uid` (`uid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `user_invite_log` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `inviter_uid` INT UNSIGNED NOT NULL COMMENT '邀请人ID', `invitee_uid` INT UNSIGNED NOT NULL COMMENT '被邀请人ID', `invite_time` INT NOT NULL, `ip` VARCHAR(64) NOT NULL DEFAULT '', `user_agent` VARCHAR(255) NOT NULL DEFAULT '', UNIQUE KEY `idx_inviter_invitee` (`inviter_uid`, `invitee_uid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;表结构调整好后，邀请加次数走一个独立事务：
Db::startTrans(); try { $exists = Db::name('user_invite_log') ->where('inviter_uid', $inviterUid) ->where('invitee_uid', $inviteeUid) ->find(); if ($exists) { throw new \Exception('重复邀请，不计次数'); } Db::name('user_invite_log')->insert([ 'inviter_uid' => $inviterUid, 'invitee_uid' => $inviteeUid, 'invite_time' => time(), 'ip' => request()->ip(), 'user_agent' => substr(request()->header('user-agent'), 0, 255) ]); Db::name('user_play_count') ->where('uid', $inviterUid) ->inc('total_count', 5) ->inc('invite_count') ->update(); Db::commit(); } catch (\Throwable $e) { Db::rollback(); }inc('total_count', 5)是 ThinkPHP6 的原子自增语法，直接把 SQL 拼成UPDATE ... SET total_count = total_count + 5，避免先查后改的竞态问题。邀请日志表上的联合唯一索引从数据库层面拦截了同一对用户重复计数的可能。
3.2 播放资格的校验时机与前端展示
播放接口在返回视频流地址前，必须先做次数校验。源码的逻辑是：先判断剩余次数，大于 0 则正常返回视频地址并扣减一次，等于 0 则返回特定的状态码，前端收到后弹出分享引导层。
这里有一个容易被忽略的细节：视频播放是一个长连接过程，用户点开视频但没看完就关闭，次数已经扣了，这在产品上会引发投诉。比较稳妥的做法是改成“预扣 + 回滚”机制：
// 预扣一次 $remaining = Db::name('user_play_count') ->where('uid', $uid) ->where('used_count', '<', Db::raw('total_count')) ->dec('used_count', 1) // 注意这里是正向操作，实际应使用 inc ->update();实际操作中，used_count字段的自增是正向操作。预扣后在视频心跳接口中每 10 秒上报一次播放状态，如果视频播放时长低于 5 秒，则返还次数。这个方案更贴近真实商业场景，也是我基于这套源码拓展的经验——对用户越宽容，传播意愿越高。
3.3 防刷的三道关卡
裂变系统最大的风险是机器刷量。源码在同一 IP 和同一 User-Agent 的维度上做了基础限制，但生产环境必须叠加三层策略：
- 一层：邀请链接携带
sign签名参数，由服务端用密钥对uid + timestamp做 MD5 生成，有效期 10 分钟。这样脚本无法批量构造有效链接。 - 二层：Redis 记录同一个 IP 在单位时间内的点击次数，超过阈值（比如 1 分钟 20 次）直接拒绝，返回“操作过于频繁”。
- 三层：邀请成功后校验被邀请人的设备指纹（Canvas 指纹 + WebGL 指纹组合），同一指纹的设备累计注册超过 3 个账号时，后续注册邀请全部不计数。
第二层的 Redis 计数代码示意：
$key = 'invite_ip_' . request()->ip(); $count = Redis::incr($key); if ($count === 1) { Redis::expire($key, 60); } if ($count > 20) { return json(['code' => 0, 'msg' => '操作过于频繁，请稍后再试']); }incr配合expire是经典的滑动窗口限流雏形，单机场景够用。如果后续要拆分布式，可以替换为 Lua 脚本保证原子性。
4. 支付模块对接实战：从回调验签到代理分账路由
4.1 支付配置的项目结构与参数解析
源码声称“已对接支付”，实际交付的是支付扩展包加一套配置后台。从文件结构看，extend/pay目录下封装了统一的支付接口，支持微信支付和支付宝支付两种主流渠道。对接时只需在后台填写 AppID、商户号、API 密钥、证书路径这四个核心参数。
// config/pay.php 配置示例 return [ 'wechat' => [ 'app_id' => 'wx1234567890abcdef', 'mch_id' => '1600001234', 'key' => '你的APIv3密钥', 'cert_path' => '/www/wwwroot/xxx/cert/apiclient_cert.pem', 'key_path' => '/www/wwwroot/xxx/cert/apiclient_key.pem', 'notify_url' => 'https://api.yourdomain.com/api/pay/notify/wechat', ], 'alipay' => [ 'app_id' => '2021001234567890', 'private_key' => '应用私钥字符串', 'alipay_public_key' => '支付宝公钥字符串', 'notify_url' => 'https://api.yourdomain.com/api/pay/notify/alipay', ], ];notify_url是支付回调地址，必须配置为公网可访问的 HTTPS 地址。微信支付 APIv3 的密钥是 32 字节的随机字符串，不是商户平台登录密码。支付宝的private_key是应用私钥，用来生成请求签名，alipay_public_key是支付宝公钥，用来验证回调签名，这两个不能搞混。
4.2 支付回调验签的本质
支付回调是整个流程中最容易出安全问题的环节。攻击者可以伪造一个“支付成功”的通知打到你的回调地址，如果逻辑里没有验签直接改订单状态，就会被无限薅羊毛。这套源码在回调入口处使用了框架层的验证机制，核心代码如下：
public function notify() { $data = file_get_contents('php://input'); $result = json_decode($data, true); // 验证签名 $check = Pay::wechat()->verify($result); if (!$check) { return 'fail'; } // 判断业务结果 if ($result['result_code'] === 'SUCCESS' && $result['return_code'] === 'SUCCESS') { $orderNo = $result['out_trade_no']; // 幂等处理：判断订单是否已处理 $order = Db::name('order')->where('order_no', $orderNo)->find(); if ($order && $order['status'] === 0) { Db::name('order')->where('order_no', $orderNo)->update([ 'status' => 1, 'pay_time' => time(), 'transaction_id' => $result['transaction_id'] ]); // 增加用户余额 Db::name('user')->where('id', $order['uid'])->inc('balance', $order['amount'])->update(); } return 'SUCCESS'; } return 'fail'; }验签通过Pay::wechat()->verify()完成，这是 SDK 封装好的方法，内部会使用商户号、API 密钥和证书做解密验签。out_trade_no是商户订单号，transaction_id是微信支付订单号。
整个回调处理有两个关键点。第一是幂等：微信支付会多次推送回调通知直到商户返回SUCCESS，所以必须判断订单状态是否为未处理，已处理则直接返回成功。第二是响应格式：微信支付要求回调返回SUCCESS字符串，支付宝要求返回success字符串，注意大小写，返回其他内容会被视为失败并继续重试。
4.3 代理分账路由设计
代理后台是商业版打赏系统的核心差异化功能。总后台可以创建多个代理，每个代理拥有独立的域名入口、独立的结算比例。打赏收入到账后，系统按比例自动拆分：平台抽成、代理分润、主播收益。
分账比例配置表的设计直接影响后续的结算逻辑：
CREATE TABLE `proxy_settle_rule` ( `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, `proxy_id` INT UNSIGNED NOT NULL, `anchor_ratio` DECIMAL(5,2) NOT NULL DEFAULT '70.00' COMMENT '主播分润比例(%)', `proxy_ratio` DECIMAL(5,2) NOT NULL DEFAULT '10.00' COMMENT '代理分润比例(%)', `platform_ratio` DECIMAL(5,2) NOT NULL DEFAULT '20.00' COMMENT '平台分润比例(%)', `status` TINYINT NOT NULL DEFAULT 1, `create_time` INT NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里有一个业务边界需要说清楚：主播和代理的分润比例之和不能超过 100%，如果超过，平台就亏本了。系统后台在保存规则时做了校验，但如果你做二次开发调整这块逻辑，必须保留这个防线。
5. 域名分流策略与多源链接配置：解决资源被拦截的工程化方案
5.1 逐级分流的域名池架构
这类系统最常见的运营风险是：视频资源链接被第三方平台拦截，导致用户无法播放。源码自带的“域名分流防御”功能，本质上是一个多级容灾的链接调度系统。系统内置了域名池的概念，可以配置多个资源域名，当主域名请求失败时，自动切换到备用域名。
这套机制在代码中的实现，是封装了一个统一的getVideoUrl()方法，先从数据库读取当前生效的域名列表，逐一发起探测请求，返回最快响应的可用域名。同时在后台有一个“域名池管理”界面，可以手动添加、下线、排序域名。
5.2 第三方链接接入的配置流程
源码提供一个专门的域名接口，职责是统一管理视频资源的 CDN 来源。常见做法是把视频上传到腾讯云 COS、阿里云 OSS、百度云 BOS 等对象存储，然后把 COS 的访问域名配置到系统里。具体操作如下：
- 在腾讯云 COS 控制台创建存储桶，访问权限设为“公有读私有写”。
- 将 COS 加速域名（形如
xxx.cos.accelerate.myqcloud.com）填入系统的域名池。 - 在系统设置中开启“COS 链接转换”，系统会把上传的视频地址自动替换为 COS 的完整 URL。
代码中的地址替换逻辑本质上是字符串拼接：
public function replaceCosUrl($url) { $cosDomain = Config::get('site.cos_domain'); // https://cdn.example.com $cosPath = parse_url($url, PHP_URL_PATH); // /uploads/video/xxx.mp4 return $cosDomain . $cosPath; }5.3 内网穿透和二级分发的应用场景
源码的域名接口还兼容 NAT 内网穿透场景。这在本地开发调试时非常实用：开发机在局域网内，外部无法直接访问，用花生壳或 ngrok 映射一个公网地址，填入系统的资源域名配置中，模拟线上播放链路。公网链路出现故障时，可以临时切到穿透地址兜底，保证 demo 演示不中断。
这套域名池配合多模板的资源加载机制，让系统在换肤和换链接两个维度上做到了解耦——运营换模板不碰链接配置，换域名不碰前端模板。
6. 基于 Redis +Lua 的播放次数并发扣减优化实战
前面提到过的次数扣减逻辑，在高并发下会暴露一个隐患：如果 1000 个人同时请求播放接口，UPDATE语句的行锁会让请求排队，虽然数据不会出错，但响应时间会飙升。这里给出我在拆解后做的优化方案：把播放次数的预扣逻辑从 MySQL 迁移到 Redis，用 Lua 脚本保证原子性。
先设计 Redis 的数据结构。每个用户维护两个 key：
play:total:{uid} # 总次数 play:used:{uid} # 已用次数扣减次数的 Lua 脚本如下：
-- KEYS[1]: play:total:{uid} -- KEYS[2]: play:used:{uid} local total = tonumber(redis.call('GET', KEYS[1]) or '5') local used = tonumber(redis.call('GET', KEYS[2]) or '0') if used < total then redis.call('INCR', KEYS[2]) return 1 else return 0 end在 PHP 中调用这段脚本：
$lua = <<<LUA local total = tonumber(redis.call('GET', KEYS[1]) or '5') local used = tonumber(redis.call('GET', KEYS[2]) or '0') if used < total then redis.call('INCR', KEYS[2]) return 1 else return 0 end LUA; $result = Redis::eval($lua, ['play:total:' . $uid, 'play:used:' . $uid], 2); if ($result == 1) { // 扣减成功，返回视频地址 return json(['code' => 1, 'url' => $videoUrl]); } else { // 次数耗尽，返回分享引导 return json(['code' => 0, 'msg' => '播放次数已用完，分享给好友可继续观看']); }Redis::eval的第三个参数是 KEY 的数量，后面跟具体的 key 列表。Lua 脚本在 Redis 服务端原子执行，整个过程没有竞态条件，也不需要加锁。
执行完扣减后，还需要把 MySQL 里的数据同步回来。做法是写一个定时任务，每 5 分钟把 Redis 中的used值批量写回数据库。如果中途 Redis 崩溃导致数据丢失，用户最多损失 5 分钟内的播放记录，影响可控——这个取舍在商业场景下是值得的。
验证优化效果的方法：在服务器上用ab工具模拟 200 个并发请求打播放接口，观察 QPS 和平均响应时间：
ab -n 2000 -c 200 -H "Authorization: Bearer YOUR_TOKEN" \ "https://api.yourdomain.com/api/video/play?id=123"对比优化前后的Time per request指标，你会发现从 MySQL 行锁方案切换到 Redis Lua 方案后，同样的并发量下响应时间通常能压缩 60% 以上。这套方案对任何基于次数控制的泛娱乐系统都适用，不局限于打赏场景。
本文还有配套的精品资源，点击获取
