棋牌游戏搭建教程

去年帮朋友搭过一个地方麻将app，棋牌后端用Go写房间逻辑，游戏前端用Cocos Creator。搭建上线三个月，教程日活稳定在两千左右。棋牌棋牌游戏的游戏技术栈没那么神秘，但坑确实不少。搭建下面把搭建过程拆开说，教程能跑通的棋牌最小闭环其实就四块：房间管理、状态同步、游戏断线重连、搭建防作弊。教程

先定通信模型，棋牌别急着写业务

棋牌和普通实时游戏不一样，游戏它的搭建操作是低频的——出牌、碰、杠，间隔几秒甚至几十秒。用WebSocket做长连接足够，没必要上UDP。我见过有人拿Photon做斗地主，延迟是低，但服务器成本翻了三倍，不值。

消息格式用JSON就行。Protobuf省的那点带宽，在棋牌场景里几乎感知不到。真正要花心思的是消息的幂等设计。玩家点“出牌”按钮，网络抖动导致重发，服务端必须能识别这是同一次操作。做法很简单：客户端每条指令带一个自增seq，服务端对每个玩家维护lastSeq，小于等于的直接丢弃。

房间逻辑的核心是状态机

一个房间从创建到销毁，经历等待、开局、进行中、结算四个阶段。每个阶段的合法操作不同。等待阶段只能加入或退出，进行中只能出牌或过。用状态模式写，别用一堆if-else堆在消息处理函数里。

我习惯把房间状态存Redis，key是roomId，value是一个JSON结构，包含玩家列表、当前轮到谁、牌堆剩余、每人手牌。每次操作先读Redis，在内存里跑规则校验，通过后写回。这样服务端可以无状态水平扩展，房间和网关分离。

有个细节：牌堆洗牌要在服务端做。客户端只负责展示。用crypto/rand生成种子，Fisher-Yates洗牌。别用math/rand，那玩意可预测。

断线重连比想象中麻烦

玩家地铁里掉线是常态。重连时客户端带token请求，服务端要恢复完整视图：手牌、桌面牌、当前操作倒计时。这里容易漏的是“操作历史”——比如上家刚打了一张三万，重连的玩家得能看到。所以服务端要维护一个最近N条操作的环形缓冲区，重连时一并下发。

倒计时用服务端时间戳，客户端只做展示。别信客户端本地计时，改个系统时间就能作弊。服务端每500ms广播一次剩余秒数，或者干脆只发截止时间戳，客户端自己算。

防作弊是底线

棋牌游戏最怕合伙人开黑。两个玩家坐同一张桌子，用语音通牌。纯技术手段很难100%识别，但可以做几件事：记录每个玩家的出牌序列，用简单统计模型检测异常——比如某两人互相喂牌的频率显著高于随机。再就是IP和设备指纹，同IP进同一房间直接拒绝。

另外，客户端别下发其他玩家的手牌。哪怕加密了也别发。服务端只告诉客户端“谁出了什么”，手牌数据永远留在服务端。我见过一个斗地主项目，为了做“记牌器”功能把所有人手牌同步到客户端，结果被逆向后直接看穿。

部署和成本

一台4核8G的云服务器，跑一个网关进程加两个房间进程，撑两千日活没问题。带宽是主要开销，WebSocket长连接每个约5KB内存，消息频率低，月流量几十G。数据库用MySQL存用户和战绩，Redis存房间和会话。别上Kafka，这个量级用不上。

最后说个观察：棋牌游戏的难点不在技术，在运营合规。技术方案再优雅，资质不全照样下架。搭建之前先把版号、文网文这些弄清楚，比调代码重要得多。