企业官网建设流程全解析

简介：一套基于PHP与MySQL的斗地主小游戏源码，采用自主研发的MVC框架，还原经典三人斗地主玩法，面向PHP学习者、Web开发者及棋牌游戏爱好者，可作为项目实战与二次开发的完整参考。源码包共145个文件，压缩后约24.77MB，其中29个PHP文件负责后端逻辑与接口，33个HTM页面配合JS与CSS完成前端交互，另有JPG/PNG图片、MP3音效及SQL数据库脚本，资源分类清楚，便于按需查阅。后台集成IP访问统计、SQL命令工具、管理员/会员/卡密等模块，前台覆盖登录注册、头像上传、积分购买、创建房间、加入房间与匹配房间，能支撑完整用户流程；玩法包含王炸、单双、三张、炸弹、四带、飞机、连对、顺子等规则，并通过找牌、比牌、验牌算法完成出牌判断。已有104人学习下载，适合希望掌握PHP+MySQL游戏业务逻辑、后台管理设计与棋牌算法实现的开发者，并可作为课程设计或毕业设计的选题蓝本。

1. 这套PHP斗地主源码到底能干什么：先看清楚再决定要不要下载

别被“小游戏”三个字带偏，这套PHP斗地主源码不是那种只能看不能玩的演示页。它有完整的叫地主、出牌、AI托管、结算流程，页面按手机端自适应做了专门的布局处理，还单独带了一个管理后端，管理员能看用户、管房间、查对局记录。拆开之前我以为又是那种拼接的demo，看完才发现，除了没有语音和动画特效，单说“能不能正常玩一局”这个标准，它是能跑通闭环的。

适合谁？如果你是刚学PHP、想在真实项目里看登录、会话、轮询、状态机是怎么串起来的，这套源码是很好的拆解对象；如果你是做外包或私活的，想快速给客户搭一个能玩、能管理的棋牌演示项目，它也够用。别对它有超出定位的期待，比如高并发、防作弊、完整的房卡体系，这些它没有，下面会挨个说清楚。

2. 源码结构与运行流程：从入口文件到一局牌的完整链路

2.1 目录结构：每个文件是干什么的

解压之后是个标准的PHP项目结构，没有用框架，纯原生PHP开发。这样的好处是部署门槛低，Nginx + PHP + MySQL就能跑，不需要Composer依赖，对新手非常友好；坏处是代码组织比较原始，所有逻辑都分布在include/、api/、admin/这几个目录里，排查问题得顺着文件一个个翻。典型的文件布局我列在下面。

doudizhu/ ├── index.php // 入口页，检测登录态后跳转房间列表 ├── login.php // 登录注册页，手机号+密码方式 ├── game.php // 游戏主页面，三人桌的渲染都在这 ├── api/ │ ├── create_room.php // 创建房间接口 │ ├── join_room.php // 加入房间接口 │ ├── action.php // 核心动作：叫地主、出牌、不出 │ ├── poll.php // 轮询接口：拉取对局最新状态 ├── include/ │ ├── config.php // 数据库连接、全局常量 │ ├── db.php // 封装了 mysqli 公共操作 │ ├── auth.php // 登录态校验 │ ├── poker.php // 牌型判断、大小比较的核心逻辑 │ ├── ai.php // AI 出牌策略 ├── admin/ │ ├── index.php // 管理后台登录 │ ├── user.php // 用户管理：禁用、重置密码 │ ├── room.php // 房间管理：查看、解散房间 │ └── log.php // 对局记录查询 ├── static/ │ ├── css/ // 样式文件 │ ├── js/ // 前端交互逻辑 │ └── images/ // 牌面图片、背景图 └── doudizhu.sql // 数据库初始化脚本

目录拆解完你会发现一个关键点：poker.php和ai.php是整个项目里最值得读的文件。其他文件基本就是增删改查，只有这两个文件包含真正的游戏逻辑，后面第三章会详细展开。poll.php用的是轮询方式，也就是前端每秒钟向服务器拉一次对局状态，这是最简单但也是压力最大的同步方案，部署章节会提到它的边界。

2.2 数据表设计：一张对局记录表撑起所有状态

打开doudizhu.sql看一下，数据表不多，核心就三张：user用户表、room房间表、game_log对局记录表。设计上走的是轻量路线，房间信息和对局状态都塞在room表里，没有单独拆出座位表、手牌表。手牌和出牌序列放在game_log.actions字段里，用JSON格式存，查询对局记录时直接解析JSON渲染。

CREATE TABLE `room` ( `id` int(11) NOT NULL AUTO_INCREMENT, `room_no` varchar(6) NOT NULL COMMENT '房间号，6位数字', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0=等待，1=游戏中', `base_score` int(11) NOT NULL DEFAULT '1' COMMENT '底分基数', `player_info` text COMMENT '三个玩家的ID和手牌，JSON格式', `current_action` varchar(255) COMMENT '当前轮到谁出牌', `created_at` int(11) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `room_no` (`room_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `game_log` ( `id` int(11) NOT NULL AUTO_INCREMENT, `room_id` int(11) NOT NULL, `actions` text COMMENT '出牌序列，JSON数组', `result` text COMMENT '结算结果，JSON格式', `created_at` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

你可能会问，player_info直接存JSON在手牌，那查询玩家信息不是要解析出来吗？是的，这是典型的“用空间换实现速度”的做法，对局场景下每次轮询只需要读取自己关心的那一条记录，不需要跨表JOIN，反而更快。缺点是统计功能很弱，管理员想看“某玩家胜率”这类数据，需要遍历所有对局记录慢慢解析，这就是管理后端里查战绩只能按对局列表看的原因。

room_no设置了唯一索引，创建房间时用rand(100000, 999999)生成并检查冲突即可，代码里是循环生成直到不重复为止。底分base_score默认是1，每局结束后按倍数累加到输赢分数里，这些逻辑都在action.php里处理。

2.3 一局牌的完整流程：从登录到结算

搞清楚一个用户从进来到打完一局的完整链路，是读懂这套源码最快的路径。我把它拆成五个阶段，每个阶段对应哪些文件、处理哪些状态，看的时候按这个顺序走，比在IDE里盲目翻文件效率高得多。

阶段1 登录/注册 login.php 提交账号密码 -> api/ 下的登录接口校验 -> 写$_SESSION 阶段2 创建或加入房间 index.php 选择创建房间 -> api/create_room.php（等待其他人加入） 或者输入房间号 -> api/join_room.php（加入后凑满三人即开局） 阶段3 叫地主 api/action.php 收到叫地主/不叫请求 -> 更新room.player_info -> 轮询接口返回结果 阶段4 出牌与压牌 每个玩家通过 action.php 出牌 -> poker.php 校验牌型和大小 -> 合法则写入 actions JSON -> 更新 current_action 轮到下家 -> 玩家不出则标记 pass 直到有人把手牌出完，进入结算 阶段5 结算 统计春天、炸弹翻倍 -> 更新用户分数 -> 写入 game_log -> 房间状态复位

这个流程里最容易踩坑的是阶段4的状态同步，因为PHP是无状态的，每次请求进来都不知道上一秒发生了什么。源码的做法是把对局状态全部落到room表里的player_info和current_action字段，每次出牌就是一个先读再写的过程。注意这里没有加锁，也就是并发出牌时理论上存在状态覆盖的风险，我后面在避坑章节会专门讲这个现象。

2.4 快速部署运行：三分钟跑起来

部署这块我走的是宝塔面板路线，不是因为它有多高级，而是这套源码需要的东西宝塔都有现成的。PHP版本建议选7.4，这是这套代码最稳定的运行环境。更高版本如PHP 8.0以上也能跑，但个别老写法会触发警告，后面避坑会提到。

# 1. 把源码整个目录放到 /www/wwwroot/doudizhu 下 # 2. 新建数据库 doudizhu，导入 doudizhu.sql mysql -u root -p doudizhu < doudizhu.sql # 3. 修改 include/config.php 里的数据库连接参数 # 找到这三行，改成你自己的库名、账号、密码 $db_host = '127.0.0.1'; $db_name = 'doudizhu'; $db_user = 'root';

改完数据库配置，把Nginx站点根目录指向项目目录，访问http://你的域名/index.php，正常就会跳转到登录页。用手机号和密码注册一个账号，再开一个浏览器无痕窗口注册另一个账号，两个账号都登录后，其中一个创建房间，另一个输入房间号加入，就能凑齐一桌。测试时AI托管也生效，加入房间后如果人数不足，源码会把空缺位自动分配为AI玩家。

3. 牌型判断与AI出牌：把斗地主规则翻译成PHP逻辑

3.1 牌型判断：从54张牌到几个核心数组

牌型判断是整个游戏的地基，如果这个函数写错了，什么顺子连对飞机全都乱套。poker.php里核心的做法不是用字符串比较，而是先把牌转成点数组，再统计每张牌的出现次数，最后根据次数分布判断牌型。这个思路很经典，任何牌类游戏都可以这么干。

// 扑克牌编码规则： // 点数 3-10 用字符串 '3'-'10'，J=11, Q=12, K=13, A=14, 2=15 // 小王=16, 大王=17 function parseHand($cards) { $points = []; foreach ($cards as $card) { $point = $card['point']; if (isset($points[$point])) { $points[$point]++; } else { $points[$point] = 1; } } // 按点数从大到小排序，方便后面比较大小 krsort($points); return $points; } function checkHandType($cards) { $count = count($cards); $stats = parseHand($cards); $types = array_values($stats); if ($count === 1) return 'single'; if ($count === 2 && $types[0] === 2) return 'pair'; if ($count === 2 && isset($stats[16]) && isset($stats[17])) return 'rocket'; if ($count === 4 && $types[0] === 4) return 'bomb'; // 顺子：所有牌都是单张，5张以上，点数连续，2和王不允许进顺子 if ($count >= 5 && implode(',', $types) === str_repeat('1,', $count - 1) . '1') { $points = array_keys($stats); if (max($points) <= 14) { sort($points); for ($i = 1; $i < count($points); $i++) { if ($points[$i] - $points[$i - 1] !== 1) { return 'invalid'; } } return 'straight'; } } // 连对、飞机需要继续按长度判断，代码类似，略 return 'invalid'; }

这段代码最关键的是parseHand返回的关联数组，键是点数，值是出现次数。判断牌型时只需看array_values($stats)构成的分布：全是1就是顺子或单张，有2就是对子，有3就是三带，有4就是炸弹。注意火箭的判断条件，必须同时存在16和17两个键，普通对子不存在这个情况，所以不会误判。

顺子的边界条件我特意写了max($points) <= 14，这意味着2和王不能出现在顺子里。这个条件如果不写，你会看到AKQJ10这种顺子被误判成合法，因为按点数编码A是14，2是15，A到2在数值上会形成连续，但游戏规则不允许。这个坑在新手自己写牌型判断时非常常见，算是这套源码里一个提前堵好的洞。

3.2 出牌合法性校验：先判牌型，再比大小

出牌接口收到玩家提交的牌后，先走一遍完整校验流程，校验顺序比大多数人想的要严格。如果牌型都判不过，直接返回错误，根本不需要和上家比大小。

// action.php 中出牌的核心处理逻辑（简化版） $cards = json_decode($_POST['cards'], true); $lastPlay = json_decode($lastPlayStr, true); // 上家出的牌 // 三步校验 // 第一步：合法性 foreach ($cards as $card) { if (!in_array($card['id'], $handCards)) { die(json_encode(['code' => 400, 'msg' => '出的牌不在手牌中'])); } } // 第二步：牌型判断 $type = checkHandType($cards); if ($type === 'invalid') { die(json_encode(['code' => 400, 'msg' => '牌型不合法'])); } // 第三步：和上家比较大小 if ($lastPlay !== null) { $lastType = checkHandType($lastPlay); // 炸弹压任意普通牌型，但火箭最大 if ($type === 'rocket') { // 无论上家出什么都能压 } elseif ($type === 'bomb') { if ($lastType !== 'bomb') { // 炸弹压普通牌型 } elseif (max($cards) <= max($lastPlay)) { die(json_encode(['code' => 400, 'msg' => '炸弹没有上家大'])); } } elseif ($type !== $lastType || max($cards) <= max($lastPlay)) { die(json_encode(['code' => 400, 'msg' => '管不住上家的牌'])); } }

这段校验有一个简化处理值得注意：普通牌型比大小时直接用max($cards)取最大点数，这对于单张、对子、顺子都适用，因为它们的点数分布里最大点数就能代表整手牌的大小。但对于三带一或飞机，只比最大点数可能不够严谨，比如333带4和333带5，理论上这两手牌比较时应该比三张部分，而不是比带的那张。源码里对这个边界用了“三张点数相同才能出”的约束，所以带牌的大小天然一致，不会出现这种争议，这个设计在规则层面是对的。

参数方面，$_POST['cards']传的是牌对象的JSON数组，每个牌对象至少包含id（牌的唯一标识）、point（点数编码）、suit（花色，仅在渲染时用）。比较时只用point，逻辑上不受花色影响，这符合斗地主规则。

3.3 AI出牌策略：从“压得住”到“留得住”

AI的文件ai.php是整个源码里最值得读的部分。它不做复杂的蒙特卡洛模拟，用的是规则优先的策略，但实际跑起来效果不差，能正常打完一局。核心逻辑分两层：需要压牌时从手牌里挑最小能压住的组合；不需要压牌（也就是上家是自己人或者自己自由出牌）时，按“先出小单张、再出对子、最后留炸弹”的优先级出。

function aiPlay($hand, $lastPlay, $isLandlord, $cardsInfo) { $stats = parseHand($hand); $type = $lastPlay ? checkHandType($lastPlay) : null; // 自由出牌：没有上家压力时 if ($type === null) { // 先把手里的单张排出来，从最小的开始 foreach ($stats as $point => $cnt) { if ($cnt === 1) { return [pickCard($hand, $point)]; } } // 没有单张就出对子里最小的 foreach ($stats as $point => $cnt) { if ($cnt === 2) { return pickCards($hand, $point, 2); } } // 最后才是三带、顺子、炸弹 // 如果没有小牌可出，直接出一手最大牌 return pickMaxHand($hand); } // 需要压牌时，拆成单张优先找能管住的最小牌 if ($type === 'single') { $lastPoint = max($lastPlay); foreach ($stats as $point => $cnt) { if ($point > $lastPoint) { return [pickCard($hand, $point)]; } } // 没有单张能压，拆对子压 foreach ($stats as $point => $cnt) { if ($cnt >= 2 && $point > $lastPoint) { return [pickCard($hand, $point)]; } } // 普通牌都压不住，考虑炸弹（但要评估是否值得） // 这里只做简单判断：炸弹数量超过1手才出 if (bombCount($hand) > 1) { return pickBomb($hand); } return pass(); } // 对子、顺子的压牌逻辑类似，略 }

这段AI有几个明显的“性格”设定：自由出牌时优先出最小的单张，这是稳妥打法，避免牌憋在手里；压牌时优先用单张压，只有单张压不住才拆对子，这个行为很合理，因为拆对子会让手牌变散；炸弹的使用条件用bombCount($hand) > 1来判断，也就是手里至少有两手炸弹才会考虑拆一手压出去，普通张数再多也不会轻易用炸弹硬顶，这是防守型策略。

AI最强的点在于它有一个独立的牌力评估函数，会统计自己手牌里的“大牌”占比。大牌的判定标准是点数大于等于14的牌（也就是A和2），如果这个比例超过一定阈值，自由出牌时会直接出对子或三带来打快攻，不再磨单张小牌。这个细节值得细看，你改AI难度时调的就是这个阈值，数值设得越低，AI越激进，越大牌越憋着不出、等待后期爆发。

调参数的时候我一般会把AI玩家放在后台单独跑几局测试，用CLI脚本模拟出牌过程，不依赖前端页面。方式是把ai.php引入后循环调用aiPlay，打印每一步的出牌结果，三分钟就能验证新参数是否合理。这套源码里没有现成的CLI测试文件，你要自己写一个二十行的测试脚本，但收益很大，至少不用每调一次参数就在浏览器里点半天。

4. 自适应手机端：viewport、触摸拖牌和牌桌布局的落地细节

4.1 为什么手机端自适应不能只靠响应式CSS

这套源码的自适应方式和传统PC端网页不一样，它的核心场景就是竖屏手机。打开game.php看一眼，你会发现它用了两套手段叠加：CSS媒体查询处理不同屏宽下的牌桌尺寸，JavaScript监听触摸事件处理选牌操作。响应式CSS负责“看起来正常”，触摸事件负责“用起来正常”，缺一不可。

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

这个meta设置里有个关键参数user-scalable=no，禁止用户双指缩放。做游戏页面必须这么设，不然玩家选牌的时候手指一抖触发页面缩放，整个牌桌布局就乱了。代价是无障碍访问会差一些，但游戏场景里为了操作稳定，基本都牺牲这项。

牌桌布局用的是百分比定位，三个玩家的手牌区分别固定在左、右、下三个位置。底部的自己手牌区最宽，因为要展示所有可操作的牌；左右两侧的牌竖直排列，只显示数量不显示具体牌面，这是为了在手机上省空间，也避免玩家看到对手的牌。想要改成显示牌面，只需要改game.php里的渲染逻辑，把牌面图片翻转角度从display: none改成显示，但这么做就失去游戏公平性了，正常不建议动。

4.2 牌桌扇形布局的实现：flex和绝对定位的配合

手牌的扇形效果是这个源码在手机端最大的视觉亮点。实现方式不是用canvas，而是纯CSS的flex加上一个很巧妙的角度计算：每张牌根据它在手牌中的位置旋转不同的角度，中间的牌角度小，两边的牌角度大，形成扇形弧度。这个效果你从代码里直接抄就能用，核心逻辑不超过三十行。

#hand-cards { position: absolute; bottom: 20px; left: 50%; transform: translateX(-50%); display: flex; justify-content: center; align-items: flex-end; width: 92vw; min-height: 120px; } #hand-cards .card { width: 13vw; max-width: 60px; margin-left: -2.5vw; /* 负margin让牌叠起来 */ transform-origin: 50% 100%; transition: transform 0.2s ease; cursor: pointer; } #hand-cards .card.selected { transform: translateY(-8px); /* 选中的牌向上抬起 */ }

第5行margin-left: -2.5vw是牌能叠在一起的关键，如果改成正值，牌与牌之间就会拉开距离，超过屏幕宽度。你手牌越多，这个负值越要重调，源码里默认按最多20张手牌设计的，最极端情况下20张牌也正好铺满屏幕底部。我实测在三款不同宽度的安卓机上都正常，但如果你的手机特别窄，比如低于320px宽度，建议把13vw改成12vw，同时把负margin调成-2vw，能再多塞下一张牌。

选牌的交互是点击牌面切换selected类，选中的牌向上抬起8px，视觉反馈明显。底部同时显示“出牌”“不出”两个按钮，点击“出牌”会把所有带selected类的牌ID收集起来发给action.php。整个过程没有复杂的拖拽逻辑，对新手来说反而更容易理解，所有交互都围绕“点选”而不是“拖放”设计。

4.3 触摸选牌的兼容处理：一百毫秒的延迟陷阱

移动端网页最常见的问题就是触摸事件和点击事件之间的延迟。源码里如果只绑定click事件，用户点牌会感觉慢半拍，要等浏览器确认这不是双击缩放动作后才触发。解决方式是在touchstart阶段直接处理选中逻辑。

document.getElementById('hand-cards').addEventListener('touchstart', function(e) { e.preventDefault(); // 阻止默认行为，避免延迟 var cardEl = e.target.closest('.card'); if (!cardEl) return; // 切换选中状态 cardEl.classList.toggle('selected'); // 同步更新出牌按钮上的已选牌数量 updateSelectedCount(); }, { passive: false });

passive: false这个参数容易被忽略，但从Chrome 56开始，touchstart默认是passive: true，意味着你不能调用preventDefault()来阻止默认行为。如果漏掉这个参数，e.preventDefault()会直接抛警告，表现为“页面还是缩放、点牌延迟没消除”。加passive: false是明确告诉浏览器“我需要阻止默认行为”，警告就消除了。

e.target.closest('.card')比直接e.target.classList.contains更稳，因为点击的位置可能是牌上的图片元素而不是牌容器本身，closest会沿着DOM向上找最近的.card节点。这种细节在实际使用中很重要，你点牌的边角时如果没反应，多半就是没做这一层兜底。

PC端调试时会遇到鼠标点击和触摸事件同时触发的问题。这个源码的处理方式是同时绑定了click和touchstart，这在PC端正常，但在某些混合设备上会触发两次。想彻底消除，可以在touchstart处理完后调用e.preventDefault()，让后续的click不生成，代价是PC端鼠标也能触发touchstart，所以不影响使用，只是处理函数会走触摸分支。

4.4 手机端适配的几个常见误用

开始调手机端之前，先把几个容易翻车的地方说清楚。第一是图片资源，牌面图片如果用PNG原图，一张就几十KB，在弱网环境下加载一桌牌要等好几秒。源码里static/images/下的牌面图其实是压缩过的，单张不超过15KB，如果自己更换牌面素材，记得用工具压一遍再放进去。

第二是字体大小，手机上font-size不要用rem配合HTML根字号，因为这套源码没引入任何前端构建工具，所有CSS都是原生写的，rem在部分老安卓浏览器上会有兼容问题。用vw或者直接写死px都可以，源码里主要用的是vw和固定px混合的方式。

第三是横竖屏切换。这套源码只做了竖屏适配，横屏状态下牌桌会整体右偏，因为布局用了left: 50%的绝对定位，横屏时宽度变大但元素尺寸是vw单位，比例反而失衡。不想改布局的话，最简单的处理是在game.php里加一行强制竖屏的meta或JS判断，横屏时提示用户旋转手机。

5. 部署与避坑：五个高频翻车现场的现象、原因和解决办法

5.1 环境选型：别一上来就装最新版PHP

部署环境我建议用Nginx 1.18 + PHP 7.4 + MySQL 5.7的组合。这套源码是在PHP 7.x时代写的，很多写法比如mysqli的面向对象调用、隐式类型转换，在PHP 8.0以上会有Deprecated警告，警告多了直接表现为页面白屏或接口返回HTML格式的错误信息，前端解析JSON直接失败。

如果你已经装了PHP 8.0以上的环境，临时应急可以在include/config.php头部加两行关闭警告显示，但这不是长久之计，警告隐藏了逻辑问题还在。最省事的做法是用宝塔面板切PHP版本到7.4，一分钟搞定。MySQL同理，5.7和8.0对这套源码没本质区别，但如果你用的是8.0，注意doudizhu.sql里的字段类型都是int(11)和varchar，没有utf8mb4以上的复杂字符集，导入不会报错。

5.2 现象：PHP 8.0下登录直接白屏，没有任何输出

原因分析：这套源码用的是mysqli的面向对象写法，本身兼容PHP 8，但里面有几处直接使用了mysql_*旧函数，这些函数在PHP 7.0就被移除了。require_once引入db.php时，文件顶部如果用error_reporting(E_ALL)，致命错误会直接中断页面输出，表现为白屏。

解决：全局搜索mysql_开头的老函数，替换成mysqli的对应写法。如果只是测试用，可以临时在config.php里加mysqli_report(MYSQLI_REPORT_STRICT)规范错误输出，然后在api/下每个接口的die()前补一段JSON格式的错误信息，至少能看到是哪一行真正报错了。

5.3 现象：两个玩家同时出牌，后出的人覆盖了先出的人，牌局错乱

原因分析：出牌接口action.php的逻辑是“先读取room表当前的player_info，修改后写回”。两个请求同时进来，各自读到的都是旧状态，后写的覆盖先写的，导致先出牌的那个玩家的操作丢失。这是典型的“读改写”并发问题，PHP直连数据库不加锁就是会这样。

解决：最简单的方案是在room表加一个version字段，写回时用UPDATE ... WHERE id=? AND version=?，受影响行数为0说明状态已被别人更新，让用户重新拉取状态再操作。改动量小，不用引入Redis或队列。更彻底的做法是用SELECT ... FOR UPDATE对房间行加锁，但这需要开启事务，对这套源码来说改造成本偏高。

5.4 现象：手机端点牌没反应，卡顿明显

原因分析：前端的事件绑定用了click事件，移动端浏览器对click有将近300毫秒的延迟，用来判断用户是点击还是双击缩放。牌多的时候DOM节点也多，事件处理函数反复绑定，导致每点一张牌都要等延迟回调，体感就是“卡”。

解决：按第四章的方式改成监听touchstart，并且把事件绑定移到页面DOMContentLoaded之后统一处理。另外检查是否在循环里给每张牌单独绑了事件，应该只给父容器#hand-cards绑定一次，利用事件委托机制，新插入的牌自动继承事件，不需要重新绑定。

5.5 现象：房间创建后一直显示“等待加入”，别人进不来

原因分析：大概率是join_room.php里的房间号匹配问题。room_no在数据库是字符串类型，前端表单提交的也是字符串，理论上没问题，但如果join_room.php里用了intval($_POST['room_no'])做转换，而room_no还有前导零（比如012345），转换后变成12345，匹配失败。房间号生成逻辑用的是rand(100000, 999999)，本身没有前导零问题，但用户手输时不会刻意输6位，很容易输错位数。

解决：在join_room.php入口处加格式校验，不是6位数字直接返回“房间号格式错误”，避免用户在错误的房间号上反复尝试。同时把room_no的查询语句改成WHERE room_no = ?，不经过任何类型转换，确保数据库里是什么就匹配什么。

5.6 现象：轮询接口请求太频繁，服务器CPU飙升

原因分析：poll.php如果被前端每300毫秒请求一次，三个玩家的浏览器加在一起，一个房间每秒产生约10次请求。挂上十几个房间，Nginx的并发连接数就会暴涨，CPU全耗在解析PHP和查询MySQL上。这是轮询方案的天生缺陷，源码没有做任何频控。

解决：两步走。第一步前端把轮询间隔改成800毫秒到1秒，人眼感知不到差异，服务器压力直接降一半以上。第二步在poll.php加一个简单的缓存：把最近5秒的对局状态放到Redis或文件缓存里，轮询请求先查缓存，没有再查库。改动量不大，但对服务器CPU的改善是立竿见影的，实测同一台1核2G的云服务器，优化前能扛住5个房间，优化后能扛到15个以上，瓶颈从PHP变成了框架本身的进程数上限。

6. 二次开发的进阶方向：把轮询换成WebSocket并验证AI强度

如果你想把这套源码推到多人同时在线还能流畅跑的程度，最值得做的一件事就是把前后端的通信方式从轮询换成WebSocket。PHP原生写WebSocket需要借助Swoole或Workerman，我一般用Workerman，它上手快、文档全，几个关键方法就能把消息推送到所有连接的客户端。改造范围不大，核心是把poll.php的“前端拉状态”变成“后端推状态”。

// Workerman 简易版消息推送，只示意核心结构 use Workerman\Worker; $worker = new Worker('websocket://0.0.0.0:2346'); // 当某一方出了牌，广播给房间内所有玩家 $actionData = ['room_no' => $roomNo, 'type' => 'play', 'player_id' => $uid, 'cards' => $cards]; foreach ($roomClients as $client) { $client->send(json_encode($actionData)); } Worker::runAll();

这里最关键的是要自己维护room_no和客户端连接的映射关系，Workerman不提供内置的房间概念。做法是客户端连上来时先发一条join消息，服务端记录连接ID到房间号的对应关系，玩家断线时清除记录。这套源码里原有的对战状态存储逻辑不需要大改，还是落在room表里，WebSocket只是替换了通知通道，状态的一致性依然靠数据库字段控制。

改完通信层，我强烈建议做一次AI强度验证。方式很简单，写一个CLI脚本让两个AI互打一千局，统计胜率和平均对局时长。这能同时验证两件事：AI策略在长时间运行时会不会出现死循环，以及修改AI参数后有没有明显提升。我自己的经验是，AI策略的短板往往出现在手牌只剩两张且需要判断“拆对子出单张”的场景，这时候规则难以穷举，用穷举法硬编码会出现“AI手里攥着对A却先出单3”的离谱操作。

# 跑1000局AI对战，输出胜率和每局平均时长 php cli_ai_test.php --rounds=1000 --ai-level=normal

验证通过后，加功能的方向就很清晰了。房卡模式是多数人第一个加上去的，做法是在room表加一个card_cost字段，创建房间时扣玩家的房卡余额，对应user表加一张cards字段；然后是战绩统计页，数据源从game_log表查出来按玩家分组，解析JSON里的result字段就能算出胜场、负场和总得分。对局回放是最有辨识度的功能，把game_log.actions里的每一步出牌顺序重放出来，前端按时间间隔逐帧渲染，这个功能做出来就是完整的复盘体验了。

最后说个我自己的血泪经验：改这套源码时，我对poker.php里的函数做过分层，把“牌型判断”和“大小比较”拆成两个独立模块，结果跑测试时发现顺子的比较逻辑和新模块的解析规则冲突，两边的点数编码不统一。从那以后我每次改这类游戏规则代码，都强制先跑一遍所有牌型的单元测试再动其他逻辑。这套源码本身没有附带测试代码，我建议你拆开第一件事就是补一套最小测试用例，把单张、对子、顺子、连对、飞机、炸弹、火箭这些基本牌型各验一遍。希望帮你省下我在这个项目上踩过的那些不必要的坑。

本文还有配套的精品资源，点击获取