简介：这是一份基于C语言与Socket套接字编程的Linux斗地主课程设计项目，内含完整源代码、头文件、Makefile构建脚本与系统部署文档，面向计算机相关专业学生在课程设计、期末作业或项目初期演示中使用，也适合希望学习网络编程和Linux应用开发的入门者参考。项目源码已在实际环境跑通，并获导师认可、答辩评审95分，功能完整，具备较好的参考与扩展价值。压缩包共19个文件，主要包含5个C源文件、5个目标文件、2个头文件、2个Makefile以及可执行程序server/client和部署说明Markdown文档，包体仅49KB，结构紧凑、层级清晰，便于快速对照阅读和二次开发。目前已有173人学习下载。读者拿到后可结合部署文档直接编译运行，也能通过阅读源码理解Socket通信、多线程或状态机等经典网络编程实现思路，在此基础上修改功能或完善界面，都能省去大量从零搭建的时间。
1. 一个“会玩斗地主”的服务端，才是这门课设计的核心
如果你拿到的题目是“Linux 课程设计：基于 C 语言和 socket 的斗地主”，恭喜你，它考察的并不是你写游戏逻辑的水平，而是你在 Linux 下把“多进程/多线程 + 网络通信 + 协议设计 + 资源管理”串起来的能力。换句话说，你交上去的源码要能同时做到三件事：一是斗地主规则不被玩坏，二是多个客户端能稳定收发数据，三是程序不会因为内存泄漏、僵尸进程或端口占用被老师当场扣分。
这篇文章不是某个开源包的使用说明书，而是把这类“高分项目”背后的实现套路和验证方法拆给你看。从架构选型到协议字段设计，从规则状态机的边界到部署脚本，每一步都给出可以直接抄作业的代码和参数。适合正在做课程设计的学生，也适合想快速搭一个局域网棋牌服务端练手的开发者。先给结论：这个项目的重点不在牌桌动画，而在“网络层与游戏层如何解耦”这件事上，谁能把这一层理清楚，谁就是高分。
2. socket 通信骨架：先让三个玩家能坐下，再谈出牌规则
2.1 为什么选 TCP 而不是 UDP：棋牌协议不允许丢牌
斗地主的每一次发牌、出牌、抢地主都是强状态变更，任何一条消息丢失都会导致三端牌局不一致。UDP 虽然省了连接管理，但你需要自己在应用层做序号、重传和状态校验，这在课程设计的时间范围内几乎等于把一个网络协议栈重新发明一遍。所以实战中普遍的选择是socket(AF_INET, SOCK_STREAM, 0)，也就是 TCP 流式套接字。
服务器端我建议用 IO 多路复用而不是“一个客户端一个线程”。用select或poll管理两三个客户端连接时，代码量比 pthread 版本少一半，而且天然规避了共享牌桌数据的加锁问题。很多高分项目的评语里都有同一句话：“代码结构清晰，未发现明显并发安全隐患。”这通常就是指采用了单线程事件循环把游戏状态全部收拢到一个地方处理。
2.2 服务端骨架：bind、listen、accept 与 select 的组合
以下是一个最小但完整的服务端骨架，支持最多 3 个客户端接入，并把每个连接对应到玩家编号。先跑通这个，再往里面填斗地主规则。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <sys/select.h> #define PORT 8888 #define MAX_CLIENTS 3 int main() { int listen_fd, conn_fd; struct sockaddr_in server_addr; int client_fds[MAX_CLIENTS]; int i; for (i = 0; i < MAX_CLIENTS; i++) { client_fds[i] = -1; } listen_fd = socket(AF_INET, SOCK_STREAM, 0); int opt = 1; // 解决 TIME_WAIT 状态下端口无法立即复用的问题 setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(PORT); bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)); listen(listen_fd, 5); printf("Server listening on port %d, waiting for %d players...\n", PORT, MAX_CLIENTS); fd_set read_set; int max_fd = listen_fd; while (1) { FD_ZERO(&read_set); FD_SET(listen_fd, &read_set); for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] != -1) { FD_SET(client_fds[i], &read_set); if (client_fds[i] > max_fd) max_fd = client_fds[i]; } } int ready = select(max_fd + 1, &read_set, NULL, NULL, NULL); if (ready < 0) { perror("select error"); break; } // 新连接到达 if (FD_ISSET(listen_fd, &read_set)) { struct sockaddr_in client_addr; socklen_t addr_len = sizeof(client_addr); conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &addr_len); int slot = -1; for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] == -1) { slot = i; break; } } if (slot == -1) { printf("Room is full, reject %s\n", inet_ntoa(client_addr.sin_addr)); close(conn_fd); } else { client_fds[slot] = conn_fd; printf("Player %d joined from %s\n", slot + 1, inet_ntoa(client_addr.sin_addr)); } } // 处理每个客户端的输入 for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] != -1 && FD_ISSET(client_fds[i], &read_set)) { char buf[512]; int n = recv(client_fds[i], buf, sizeof(buf) - 1, 0); if (n > 0) { buf[n] = '\0'; printf("From player %d: %s\n", i + 1, buf); // 这里暂时原样回显，后续替换为游戏协议处理 send(client_fds[i], buf, n, 0); } else if (n == 0) { printf("Player %d disconnected\n", i + 1); close(client_fds[i]); client_fds[i] = -1; } else { perror("recv error"); close(client_fds[i]); client_fds[i] = -1; } } } } for (i = 0; i < MAX_CLIENTS; i++) { if (client_fds[i] != -1) close(client_fds[i]); } close(listen_fd); return 0; }这段代码有三个关键参数需要你理解而不是照抄。第一，MAX_CLIENTS固定为 3 是因为斗地主只有 3 个座位，但这个常量必须单独定义，不能在斗地主模块里直接写3。第二，select的第一个参数是“所有监听描述符的最大值加 1”，这里每次循环都重新计算max_fd，就是为了防止某客户端退出后max_fd失效。第三，SO_REUSEADDR不是可选项，而是必需品——否则你 Ctrl+C 杀掉服务端后立刻重启，会报“Address already in use”，这在课程设计答辩演示时是极度尴尬的翻车现场。
当你编译运行这段代码后，可以用 Linux 自带的nc命令模拟客户端连接：
gcc server.c -o server ./server & # 另开三个终端窗口，分别执行： nc 127.0.0.1 8888在nc窗口里输入任意字符串，服务端会原样返回，这就说明 TCP 通路已经打通。注意nc默认会在 EOF 时断开连接，你需要保持窗口不关闭，也就是不要按 Ctrl+D，否则服务端会打印 “Player x disconnected”。这一步能跑通，说明你的 Linux 网络编程环境没有问题，接下来的所有工作都建立在它之上。
2.3 客户端最小实现：连接、收发、退出三条路径
服务端只负责转发和裁决，真正的出牌选择由客户端完成。课程设计里的客户端一般有“字符终端版”和“带图形界面版”两种，图形界面通常用 Qt 或 GTK，但核心网络模块完全一致。这里给出字符终端版的最小客户端。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #define SERVER_PORT 8888 int main(int argc, char *argv[]) { if (argc != 2) { fprintf(stderr, "Usage: %s <server_ip>\n", argv[0]); exit(1); } int sock = socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in server_addr; memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_port = htons(SERVER_PORT); inet_pton(AF_INET, argv[1], &server_addr.sin_addr); if (connect(sock, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { perror("connect failed"); exit(1); } printf("Connected to server. Type 'quit' to exit.\n"); char buf[512]; fd_set read_set; while (1) { FD_ZERO(&read_set); FD_SET(STDIN_FILENO, &read_set); FD_SET(sock, &read_set); select(sock + 1, &read_set, NULL, NULL, NULL); if (FD_ISSET(STDIN_FILENO, &read_set)) { if (fgets(buf, sizeof(buf), stdin) == NULL) break; buf[strcspn(buf, "\n")] = '\0'; if (strcmp(buf, "quit") == 0) break; send(sock, buf, strlen(buf), 0); } if (FD_ISSET(sock, &read_set)) { int n = recv(sock, buf, sizeof(buf) - 1, 0); if (n <= 0) { printf("Server closed connection.\n"); break; } buf[n] = '\0'; printf("Server: %s\n", buf); } } close(sock); return 0; }这里用select同时监听标准输入和 socket 描述符，是字符终端客户端的标准写法。如果你不用select而用两个线程分别读写，那就要处理线程退出时的资源回收，对课程设计来说属于不必要的复杂度。strcspn(buf, "\n")用来去掉fgets读进来的换行符，因为协议字段里换行符有特殊含义，不能混入数据。运行方式是在三个不同终端分别执行：
gcc client.c -o client ./client 127.0.0.1此时 A 终端输入的文字，服务端会打印并转发回 A 终端自身。之所以能收到自己的回显，是因为上面的服务端骨架是“收到谁的消息就原样回给谁”。在后续完整版里，这里会改成广播给其他玩家。
3. 游戏协议与状态机：让三个玩家按斗地主规则轮流行动
3.1 消息格式定成“行协议”，别用二进制结构体
很多初学者上来就用struct直接send，这在同一台机器上自娱自乐没问题，但一旦客户端编译时的字节对齐方式和服务器不一致，或者两端架构不同，数据就读不对了。更稳妥的做法是定义简单的文本行协议，每条消息用换行符结尾，字段用空格或逗号分隔。这样做的好处有三个：一是方便用nc或telnet手工调试协议，二是代码里不需要处理字节序，三是老师审查代码时一眼就能看懂协议定义。
一个实战中常用的协议草案如下：
LOGIN <player_name> READY DEAL <card1> <card2> ... <card17> BID <score> PLAY <card1> <card2> ... PASS NOTIFY <message>每条消息以\n结尾。DEAL里的牌面用花色+点数编码，例如S-A表示黑桃 A，H-10表示红桃 10，C-K表示梅花 K。为什么要用这种编码而不是数字编号？因为服务端在出牌校验时需要判定“同花顺”“连对”“飞机”等组合，文本形式可以直接比较点数字符串的序列关系，省去一层映射转换。当然你也可以用纯数字 0-53 表示 54 张牌（包括大小王），然后在协议解析函数里转换。
3.2 状态机设计：等待登录 → 叫分 → 出牌 → 结算
斗地主的服务端核心是一台有限状态机。我强烈建议你把所有状态转移写在一个函数里，不要分散到各个消息处理分支中。原因很直接：出牌合法性校验和状态转移是整个项目里最容易出 bug 的地方，集中在同一文件里方便你调试，也方便老师在代码审查时看到你的设计思路。
状态定义用枚举：
typedef enum { WAITING_LOGIN, // 等待 3 个玩家登录 BIDDING, // 叫分/抢地主阶段 PLAYING, // 出牌阶段 GAME_OVER // 一局结束，等待下一局 } GameState;BIDDING到PLAYING的转移条件是：当前叫分玩家选择不叫或最高分锁定。PLAYING到GAME_OVER的转移条件是：某玩家手牌数为 0。这里最容易忘的是GAME_OVER状态下客户端可能还会继续发消息，比如玩家在结算界面手滑按了回车，服务端必须对非当前状态的消息一律丢弃或返回NOTIFY invalid_action，否则会出现上一局的残留消息干扰下一局开局的黑匣子问题。
下面给出叫分阶段的核心逻辑，这是状态机的第一个关键节点：
int bid_score[MAX_CLIENTS] = {0}; // 每个玩家的叫分，-1表示不叫 int current_bidder = 0; // 当前叫分玩家下标 int highest_bid = 0; // 当前最高分 int highest_bidder = -1; // 当前最高分玩家 int pass_count = 0; // 连续不叫的人数 void handle_bid(int player_idx, int score) { if (score > 0 && score <= 3 && score > highest_bid) { highest_bid = score; highest_bidder = player_idx; pass_count = 0; } else if (score == 0) { // 0 表示不叫 pass_count++; } else { // 叫分无效：低于当前最高分或超出范围 send_message(player_idx, "NOTIFY invalid bid"); return; } if (pass_count >= 2 && highest_bidder >= 0) { // 已有两个人不叫，叫分最高者成为地主 current_state = PLAYING; // 这里需要把地主底牌发给最高分玩家 send_cards(highest_bidder, lord_extra_cards); start_play_round(highest_bidder); return; } if (highest_bid == 3) { // 有人叫 3 分，直接成为地主 current_state = PLAYING; send_cards(highest_bidder, lord_extra_cards); start_play_round(highest_bidder); return; } current_bidder = (current_bidder + 1) % MAX_CLIENTS; send_message(current_bidder, "NOTIFY your turn to bid"); }这段逻辑有个隐蔽的边界情况：如果三个玩家全都选择不叫，highest_bidder仍然是 -1。实战中的处理方式是重新发牌并重新叫分，而不是让游戏卡死在 BIDDING 状态。很多资料里的代码都漏了这层判断，导致三人都点了“不叫”后程序就原地不动了——这是课程设计答辩时最典型的“规则没写完”扣分点。
出牌阶段的校验逻辑比叫分复杂得多。你需要实现牌组解析函数：把玩家发来的PLAY S-A H-A D-A C-A解析成牌型结构体，再判断是否大于上一手牌。判断优先级从高到低为：炸弹 > 火箭 > 普通牌型。这里给一个牌型判断的框架，完整代码因为篇幅不再展开：
typedef struct { int type; // 0=单张,1=对子,2=三张,3=顺子,4=连对,5=三带一,6=炸弹,7=飞机,8=火箭 int main_val; // 主牌的点数 int length; // 牌的数量 } CardPattern; CardPattern parse_pattern(const char *cards_str) { // 将 "PLAY S-A H-A D-A C-A" 拆成牌面数组 // 统计每个点数的出现次数 // 根据出现次数分布判断牌型 // 同时检查是否满足顺子/连对的连续性要求 // 返回识别结果 }判断顺子时注意一个常见巨坑：A 既可以作为A-2-3-4-5的最小数，也可以作为10-J-Q-K-A的最大数。编程时通常把 A 映射为 14 或 1 两种值分别尝试，否则会漏判这两种特殊顺子。另外，2 和王不能出现在顺子或连对中，这是斗地主的硬性规则，必须在校验函数里显式排除。
3.3 用脚本自动测试规则，别手动一局局玩
规则逻辑写完以后，建议立刻写一个测试脚本，用本地管道把命令序列灌给服务端，验证场景包括：同花顺能压普通顺子、4 个 A 组成的炸弹能压任何牌型、两个王组成的火箭能压炸弹、上一手牌是 PASS 后下一手可以出任意合法牌型。一个最简单的冒烟测试方式是在服务器代码里加一个--selftest参数，启动后读取预先写好的测试用例文件，不走 socket，直接调用parse_pattern和can_beat函数。这样做能把游戏逻辑和网络层完全剥离开来调试。网络问题看网络，规则问题看规则，不要混在一起找。
4. 把项目包装成高分交付物：文档、Makefile 与一键部署
4.1 目录结构如何组织，让老师一眼看到你用了心思
高分项目和低分项目在源码组织上的差距是肉眼可见的。低分项目通常把所有代码堆在main.c里，而高分项目至少在根目录下有这几个部分：
dou_di_zhu/ # 项目根目录 ├── src/ # 源码目录，按模块分文件 │ ├── server.c │ ├── client.c │ ├── game_logic.c │ ├── game_logic.h │ ├── protocol.c │ └── protocol.h ├── include/ # 公共头文件（可选） ├── docs/ # 项目文档 │ ├── 部署文档.md │ ├── 设计说明书.md │ └── 测试报告.md ├── Makefile └── README.mdgame_logic.c里放和 socket 无关的纯规则函数，包括牌型判断、大小比较、发牌洗牌。protocol.c里放消息编码、解码、转发逻辑。server.c里只保留 accept、select 和调用上层函数的循环。这样分层之后，你甚至可以写单元测试直接链接game_logic.c，不需要启动任何网络服务就能测试 54 张牌的所有组合。老师在代码审查时会先看头文件里的函数声明，如果发现game_logic.h里没有出现任何#include <sys/socket.h>，观感会好非常多。
4.2 Makefile 这样写，编译一次只要三秒
很多同学在 Linux 课程设计里还在用gcc *.c -o server一条命令编译，但那样的问题在于：改了任何一个文件都要全部重新编译，且没有头文件依赖关系。一份可复现的 Makefile 至少要支持make、make clean和make rebuild三个目标。这里给一个经过实战验证的版本：
CC = gcc CFLAGS = -Wall -Wextra -g -std=c11 TARGET_SERVER = server TARGET_CLIENT = client SRC_COMMON = src/game_logic.c src/protocol.c SRC_SERVER = src/server.c $(SRC_COMMON) SRC_CLIENT = src/client.c $(SRC_COMMON) OBJ_DIR = build all: $(TARGET_SERVER) $(TARGET_CLIENT) $(TARGET_SERVER): $(SRC_SERVER) | $(OBJ_DIR) $(CC) $(CFLAGS) $^ -o $@ $(TARGET_CLIENT): $(SRC_CLIENT) | $(OBJ_DIR) $(CC) $(CFLAGS) $^ -o $@ $(OBJ_DIR): mkdir -p $@ clean: rm -rf $(OBJ_DIR) $(TARGET_SERVER) $(TARGET_CLIENT) rebuild: clean all .PHONY: all clean rebuild注意这里用-std=c11而不是默认的 gnu 标准，目的是强制自己写出可移植的代码。如果使用了strdup之类的函数，编译加-D_POSIX_C_SOURCE=200809L可以避免隐式声明的警告。-g保留调试信息，让你在 gdb 里能直接查看变量。课程设计答辩前一天，请务必运行一次make clean && make rebuild确认无警告输出。一个带着两个 warning 的代码在老师眼里相当于脸上写着“我没测试过”。
4.3 部署文档里必须写清楚的四个问题
部署文档是老师评分的重要依据，但绝大多数人把它写成了软件安装教程。真正有价值的部署文档应该回答：第一，在什么 Linux 发行版和内核版本上验证过，我用的是 Ubuntu 22.04 和自带的 gcc 11.2，文档里就如实写这一条，不要写“兼容所有 Linux”；第二，服务器 IP 和端口从哪里配置，我一般约定端口写死在 server.c 顶部#define SERVER_PORT 8888，客户端通过命令行参数传 IP，这样最简单；第三，如何验证部署成功，也就是三个客户端各自登录后出现“Waiting for players”提示并成功进入叫分阶段；第四，如果启动失败，按什么顺序排查，最常见的原因就是端口被占用，用ss -lntp | grep 8888就能看到残留进程。
这里想强调一个细节：文档里配图比配文字有用得多。用gnome-screenshot截一张三个终端窗口分别跑./client 127.0.0.1的图，比写一百字“系统运行正常”更有说服力。截图里要能看到服务端窗口打印了三条 "Player 1/2/3 joined" 日志，这条日志是专门写给答辩老师看的。
5. 避坑指南：socket 编程和高分项目的五个经典深坑
5.1 坑一：服务端重启报 “Address already in use”
现象：Ctrl+C 杀掉服务端进程后立刻重新执行./server，启动失败。原因：TCP 连接处于TIME_WAIT状态，端口还被内核占用，默认需要等待 60 秒才能重新绑定。解决：在bind前调用setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt))。注意这里的opt是int类型，值为 1，不要传 NULL，也不要把这个错误地和线程复用混为一谈。它不会让你监听到重复端口，只允许绑定处于 TIME_WAIT 状态的端口。
5.2 坑二：数据粘包导致牌面解析错乱
现象：玩家一次打出PLAY D-A D-K D-Q，服务端偶尔能解析对，偶尔只能收到半条指令。原因：TCP 是流式协议，没有“消息边界”。recv可能一次只收到部分数据，也可能把两条NOTIFY消息拼在一起返回。解决：必须自己做消息边界切分。常见做法是维护一个循环缓冲区，每次recv后把数据追加到缓冲区，然后按\n拆分完整行。拆分后如果剩余数据不完整，保留到下一次recv继续处理。千万不要指望recv返回的字节数就正好是一条完整消息。
下面是一个消息边界处理的参考逻辑：
char recv_buf[4096]; char line_buf[1024]; int line_len = 0; int process_incoming(int fd) { int n = recv(fd, recv_buf, sizeof(recv_buf), 0); if (n <= 0) return n; for (int i = 0; i < n; i++) { if (recv_buf[i] == '\n') { line_buf[line_len] = '\0'; handle_line(fd, line_buf); // 把完整一条协议交给上层处理 line_len = 0; } else { if (line_len < (int)sizeof(line_buf) - 1) { line_buf[line_len++] = recv_buf[i]; } else { // 行过长，说明协议异常，丢弃这一行 line_len = 0; } } } return 1; }这段代码的核心价值在于：无论recv返回多少字节，都能正确切分出以\n结尾的完整行。如果不用这个机制，你会遇到“发三张牌显示两张”这种极难复现的玄学 bug，而且越到答辩前越频发。
5.3 坑三：客户端断线后服务器 CPU 飙到 100%
现象：某个客户端直接关掉终端，服务端进程 CPU 占用率飙升，游戏卡死。原因：服务端对recv返回 0 的情况没有处理，仍然把这个描述符留在select的监听集合里，而一个已经关闭的 socket 会让select立即返回可读并再次触发recv，形成忙循环。解决：在recv返回 0 时执行close(fd)，并把对应的client_fds[i]置为 -1，同时要从fd_set里清除该描述符。更完善的方案是把断线事件广播给其他还在线的玩家，告知“某某玩家已掉线，本局作废”。
5.4 坑四：父进程退出但端口仍然被占用
现象：服务端以./server &方式后台运行，退出后用ps -ef | grep server查不到进程，但启动新服务端仍然失败。原因：服务端 fork 出的子进程继承并持有了监听描述符，父进程退出后，子进程还活着。解决：调试时用lsof -i :8888查看具体哪个 PID 占用了端口，确认不是自己的残留进程后直接kill -9。更彻底的做法是在程序里为 SIGPIPE 设置忽略信号，因为向关闭连接的客户端 socket 写入数据会触发 SIGPIPE，默认行为是直接终止整个进程，这会让服务端没有任何预兆地退出。
5.5 坑五：发牌随机数不随机，每局牌面都一样
现象：每次 restart 服务端后发牌结果完全相同。原因：rand()没有调用srand(time(NULL))设置随机种子，或者srand放在循环内被反复调用。解决：在main()开头且整个进程只调用一次srand((unsigned int)time(NULL))。洗牌算法用 Fisher-Yates，从数组末尾开始向前遍历，每次与随机下标交换：
void shuffle_cards(int *cards, int n) { for (int i = n - 1; i > 0; i--) { int j = rand() % (i + 1); int tmp = cards[i]; cards[i] = cards[j]; cards[j] = tmp; } }不要用“每次和固定位置交换”的简化版洗牌，那会导致某些牌序出现概率更高，而实战中如果你用rand() % n配合多次洗牌甚至会得到完全相同的序列。这里还有一个进阶细节：真正的斗地主开发通常用random()或getrandom()替代rand()，因为课程设计环境下如果连续快速启动两个新游戏，time(NULL)返回值相同会导致两次发牌完全一致。最稳妥的办法是把time(NULL)和 PID 异或后作为种子。
6. 高分答辩的最后一公里：用自动化脚本演示完整对局
到这一步，你的代码已经可以三端联机玩一整局，但如果答辩现场开三个终端手动输入命令，很容易因为紧张点错按键而翻车。我强烈建议你写一个自动化演示脚本，让服务端自动模拟三个 AI 玩家的行为，把“网络层正常、协议正确、状态机完整”一次性展示完。这个脚本不需要多复杂，核心是给每个客户端发送一条测试指令序列。
实际做法有两种。第一种是用命名管道配合nc：写一个 Bash 脚本按时间点向三个nc进程分别发送指令，模拟出牌节奏。第二种更直接，在game_logic.c里实现一个auto_play()函数，当检测到客户端非人类输入（比如发送AUTO指令）时，服务器自动替这个玩家出牌，牌型策略就是“能压就压，有最小单张就先出小单张”。
上面这个AUTO功能的意义不只是答辩演示。它也是你自测游戏规则完整性时的必备工具。你可以启动三个终端都发AUTO，然后观察服务端能否走到GAME_OVER并打印本局结果。如果中间卡住，在 gdb 里打断点看状态机的哪一步没有匹配的转移条件。这个过程比对着代码一行行查效率高得多。
最后，作为一门 Linux 课程设计，还有两件事值得单独提一下。一是练习用 gdb 调试而不是到处插printf。遇到服务端段错误时，启动方式为：
gdb ./server (gdb) run (gdb) btbt打印的调用栈会直接告诉你崩溃发生在哪一行。你会在game_logic.c里看到类似parse_pattern中访问数组下标越界的线索。二是保存好每个阶段的 git commit。不需要推送到远程仓库，本地git init && git add . && git commit就够了。万一改坏了规则逻辑，一条git checkout -- src/game_logic.c就能拿到后悔药，不至于在答辩前一晚重写整个文件。
我从第一届用 select 写聊天室做到现在，最大的教训就是：网络程序的问题从来不会只出现在网络层，规则逻辑的点数映射错误、数组越界、随机种子不随机，这些都会在满员对局时才暴露。写斗地主课程设计，本质上是在训练一种能力：把一层层的假设都变成可验证的检查点。先有骨架，再填规则，再做边界处理，最后用自动化方式证明。希望这篇笔记能帮你在答辩时少踩几个坑，把这个项目真正变成你自己的作品。
本文还有配套的精品资源，点击获取
