澳洲娱乐德州王-H5德州扑克PHP+Swoole后端源码/七级代理带点控抽水/后端可深度二开

文章摘要： 这是一套跑在微信里的 H5 德州扑克，前端画面用 Cocos Creator 打包，真正撑起实时牌桌的是一个用 Swoole 写的 PHP WebSocket 服务端。它的后端源码相当完整——自研框架、游戏逻辑、后台管理都是明文，能读能改；短板是前端只有编译产物、包里也没带数据库。下面把这套源码的构成、技术栈、部署要点和二开空间讲清楚。

拿到这套源码，第一眼会以为它是个普通的 H5 小游戏——毕竟界面就是在微信里打开一张网页。但翻进目录会发现它并不简单：前端是一套 Cocos Creator 的 H5 打包产物，后端是一整套 PHP 自研框架，而牌桌上那种"到你下注了""底池涨了"的实时反馈，靠的是一个常驻运行的 Swoole WebSocket 进程。三块拼在一起，才是一套能开局的德州扑克。

拿到手的到底是什么

先把包里的东西分个类，这决定了这套源码值不值得二开、能改到什么程度：

结论提前说：后端三块（框架、游戏服务端、后台）都是完整明文源码，能读能改；前端是打包好的产物，没有 Cocos 工程文件。这也是它和"全开源"项目最大的差别所在。

技术栈一览

值得留意的是 Web 后端和游戏服务端虽然都是 PHP，但跑法完全不同：Web 那部分是常规的"请求进来、返回页面"，处理登录、充值、提现、后台这些；而游戏服务端是一个用命令行常驻起来的进程，专门盯着牌桌。

从进大厅到坐上牌桌

先看玩家这一侧的完整动线。进游戏是微信里打开的一张网页，顶部挂着"澳洲娱乐-德州王"的招牌，下面按金币门槛分成四个区，想和朋友单独开局还能走私密牌局输密码进场。

四个分区不是写死在前端的，而是后端配置里可调的四组参数——进场金币门槛和小盲注一一对应：

牌桌本身就是标准德州玩法：两张手牌、逐轮翻出的公共牌、底池、跟注加注弃牌。一张桌子最多坐 9 个人，发牌和每步决策各留 8 秒倒计时，超时自动处理。这些数字（每桌人数、倒计时、抽水比例）全在后端一处配置里改，不用碰前端。

真正的核心：Swoole 牌桌服务端

一般人容易忽略 youxi/dezhouJ.php 这个文件，但它才是这套源码技术含量最高的地方。将近 4000 行代码，干的是一件事——把一整局德州扑克的实时对战管起来。

它的开头就写着 if(isset($_SERVER['HTTP_HOST']))exit('no cli')，意思是这文件只能命令行启动，不能当网页访问。启动时接一个服务器编号参数，然后 new swoole_websocket_server(...) 起一个 WebSocket 服务，前端通过 ws:// / wss:// 连上来。

它用 Swoole 的几个能力把牌桌状态全放进内存里跑：

• 用 swoole_table 建了好几张共享内存表，分别装在线用户、连接映射（fd）、牌桌、房间等运行时数据——玩家坐哪桌、手里什么牌、底池多少，都在内存里，不用每步都读数据库；

• 用 swoole_process 起独立子进程，处理定时推送这类后台活；

• open（有人连进来）、message（收到玩家操作）、close（有人断线）几个事件回调，构成整局牌的驱动主干。

这种"一个常驻进程 + 内存表管状态"的写法，是 H5 实时对战类游戏的典型套路，好处是响应快、扛得住一桌多人的频繁交互。代价是这个进程得一直活着，部署时要专门伺候（下面部署环节会讲）。抽水逻辑也在这里：每局按底池抽 10%，抽完再结算给赢家。

顺带一提，前面提到的私密牌局密码、牌型判定、超时托管，也都是在这个文件里实现的，属于游戏规则的核心，看得懂 PHP 就能顺着改。

运营那一套：转盘、战绩、七级代理

德州扑克的规则是死的，但一套源码能不能"运营"起来，看的是它周边的钱和人怎么转。这套在这方面配得挺全：转大转盘白嫖金币、个人中心看盈亏战绩、还有一套七级往下分的推广代理。

幸运大转盘是留存工具：免费抽一次，或者花 15 金币抽一次，当日充值满 500、消费满 1000 还能各送一次转盘机会——把充值和活跃度绑在一起。奖项和概率都在后台可配。

个人战绩给玩家看近 7 日、近 30 日和总盈亏，下面列每一局的输赢流水，属于账目透明那一类的展示。

七级推广代理是这套源码的重头。推广 ID 拉人、生成分享二维码，往下能分七级用户，每一级都有对应的佣金返点比例（后端里 7 级的比例是逐级递减配置的）。加上提现审核、佣金工资结算，构成一条完整的裂变分销链路。这种"多级代理 + 佣金"的设计，是这类平台走量的标准玩法。

除此之外，后端还带了提现系统（手续费、单笔上限、每日提现次数都可配，且提现要走后台审核）、积分与金币双货币体系、道具商城、公告消息这些常规运营件。

后台：layui 撑起的三十多个管理页

管理端在 admin/ 目录，是基于 layui 做的一套后台，页面数得上号的就有三十多个，覆盖面相当广：

• 用户与账目：用户列表、用户日志、金额/货币/积分的信息与流水；

• 游戏运营：游戏列表、房间列表、游戏服务器管理、德州专属设置、下注日志、牌型统计；

• 资金：充值订单、支付配置、提现订单、提现审核；

• 推广与奖励：分组权限、工资/佣金日志、奖品与转盘记录、道具；

• 系统：系统设置、公告、快捷登录日志、统计报表。

其中"德州设置""下注日志""牌型统计"这几个页面值得单独点一句——它们对应的是这类游戏常说的"点控"能力，也就是运营方对牌局结果有一定干预和统计的手段。这块是明文可读的，想研究或改动都能下手。

部署要点与环境要求

这套的部署比普通 PHP 站点要麻烦一档，麻烦就麻烦在那个 Swoole 游戏进程。环境上大致需要：

部署顺序大致是：

1. 装好 LNMP 环境，额外给 PHP 编译或安装 Swoole 扩展（这一步最容易卡，版本要和 PHP 对上）；

2. 建数据库 dzpk、导入数据表，改 WangYa/config.php 里的库名、账号、密码；

3. 改 WangYa/conn.php 里的域名、抽水比例、四个分区门槛、代理返佣比例等运营参数；

4. Web 端配好 Nginx 站点，能打开大厅页；

5. 命令行把 youxi/dezhouJ.php 常驻起来（配合 supervisor / screen / nohup 守护，挂了要能自动拉起），并在后台"游戏服务器管理"里登记它的 IP 和端口；

6. 前端连的 WebSocket 地址指向这个进程，配 SSL 走 wss，微信里才连得上。

熟手在环境齐备的情况下，大半天到一天能把架子搭起来看到大厅和牌桌；但要注意，包里没有附带 .sql 数据库文件，数据表得自己想办法补齐或还原，这一步没有现成的会比较费劲，是搭建路上最大的一个坑。

能二开吗，能到什么程度

这套源码二开空间是"半开"的，得分两头看。

后端：能深度二开。 WangYa 框架、Swoole 游戏服务端、后台接口全是明文 PHP，没混淆没加密。想改抽水比例、加一个分区、调代理层级、改转盘奖品、动牌局逻辑甚至加一种新玩法，都能顺着代码改下去。对懂 PHP 的人来说，这部分是真能上手的资产。

前端：基本改不动。 res/ 下是 Cocos Creator 的打包产物（import 资源 + 压缩 JS），没有 .fire 场景和脚本工程，等于只有成品没有图纸。想换皮、改界面布局、加新界面，只能替换零散的图片资源和改极少数配置，做不到真正的界面级二开——除非拿 Cocos Creator 从头重做前端。

两个现实缺口要认清：一是前面说的没带数据库文件，得自己补库；二是前端无工程源码，深度换皮无门。所以它更适合"后端逻辑研究 / 运营参数定制 / 服务端二开"，而不是"整套换品牌重新做界面"。

顺带一提，之前拆过一套 WePoker 微扑克的源码，同样是 Cocos + PHP 的 H5 德州扑克，但那套是全开源无加密、前端工程也在，和这套"后端全源码但前端只有编译产物"正好是两种交付形态。选型做德扑二开时，两套对照着看能少踩不少坑，那篇也放在文末了，想深挖的朋友可以去看看。

小结

一句话概括这套源码：一个 Cocos 打包的 H5 壳子，包着一套完整的 PHP 后端和一个 Swoole 实时牌桌内核。技术上最有嚼头的是 Swoole 那个常驻进程和内存表管状态的写法；运营上配齐了分区、抽水、转盘、七级代理、提现审核这一整套；短板是前端只有产物、包里缺数据库。适合拿来研究 H5 实时对战服务端怎么写，或者在后端上做定制运营，不适合指望它开箱换皮直接上线。