★ FEATURED ARTICLE 简介面向福州永泰麻将微信小程序的后端工程基于Java开发适用于毕业设计、课程大作业以及小程序后端入门实践。压缩包共25个文件核心为17个Java源码另含properties与XML配置、JAR依赖、Maven构建脚本mvnw、cmd及gitignore等整体仅83KB体量小巧却覆盖完整工程骨架。目前已有80人学习/下载尤其适合希望快速上手微信小程序后端开发的学生开发者。工程采用标准Maven布局src/main与src/test拆分明确便于观察后端分层、接口定义与测试写法pom.xml集中管理依赖mvnw脚本可脱离本地环境快速构建适合作为棋牌类小程序后端从零搭建的参考模板。对于希望理解Spring Boot等经典Java后端技术栈与微信小程序对接方式的开发者这份代码能提供直接的阅读样本也可作为课设答辩时讲解后端设计思路的辅助素材。1. 麻将小程序后端不是“写接口”是“管牌局状态”拿到一个「福州永泰麻将微信小程序后端.zip」这样的交付包很多人第一反应是解压、npm install、跑起来就能对接小程序了。实际做一次棋牌类小程序后端就会发现真正的工作量不在 CRUD 接口而在房间状态机、回合流转、积分结算和微信生态的登录对接。永泰麻将这种地方棋牌玩法又带“金”的特殊牌型状态管理比普通斗地主复杂一截。这篇按我从解压源码到部署上线的完整路径写先拆透技术选型和项目骨架再落房间管理和微信登录的实现最后是上线时最容易翻车的几个现场。适合手里拿到棋牌后端源码、想快速跑通并部署的开发者也适合准备自研微信小程序棋牌后端的技术负责人参考。2. 从压缩包到跑通的项目骨架技术选型与三件启动前要确认的事2.1 福州永泰麻将后端为什么常见 Java Spring Boot 而不是 PHP棋牌类微信小程序后端的技术选型首先要看业务形态房间制、长连接、低延迟、强一致。搜索热词里出现“php后端框架”说明不少外包项目仍用 PHP 交付但就我做过的棋牌后端来看Java Spring Boot 才是这个场景下的主流选择原因就三条。第一是状态管理。一个房间四个人每个玩家的手牌、碰杠状态、当前轮次都是服务器端状态。Spring Boot 的 Controller 天然按 url 路由配合 Redis 做房间缓存状态读写非常直接。PHP 写业务快但长连接和状态管理要么靠 Swoole 补要么引入额外组件复杂度不减反增。第二是事务一致性。每局结束的积分结算涉及房间表、玩家表、流水表三处更新Spring 的Transactional注解一条事务搞定对比 PHP 手写事务回滚出错率低得多。第三是生态成熟度。MyBatis-Plus、Spring Security、Redis 客户端这些组件在棋牌后端场景都已经过大量验证遇到的问题在社区都能搜到解决方案。如果你手里的压缩包是 PHP 写的也别急着换后面章节讲的房间状态机和微信登录逻辑是业务层设计换语言只是重写一层壳。2.2 拿到压缩包先别急着跑目录结构与配置文件检查清单解压一个「福州永泰麻将微信小程序后端.zip」后不要上来就mvn spring-boot:run。血泪经验是先花十分钟检查目录结构和配置文件这十分钟能省下后面一整天的排错时间。一个规范的棋牌后端压缩包内部结构通常是 maven 父子工程或单模块工程以下文件是判断项目是否完整的标尺pom.xml或build.gradle构建文件先确认依赖来源是阿里云镜像还是 Maven 中央仓库application.yml核心配置确认数据库连接串、Redis 地址、微信小程序 appid 和 secret 是否已填src/main/resources/mapper/MyBatis 的 XML 文件缺失会导致启动报 Mapper 未绑定sql/目录或schema.sql建表脚本没有这个文件基本可以确定项目跑不起来README.md部署说明注意看它写的端口和上下文路径检查时要特别注意application.yml里几个关键项的配置位置。spring.datasource.url的时区参数必须带serverTimezoneAsia/Shanghai否则 MySQL 8 连接直接报错spring.redis.host不能写成localhost因为小程序后端部署在云服务器Redis 一般单独装在同一台或其他机器上。还有wx.appid和wx.secret这两个配置项后端需要拿它们调微信接口换 openid如果压缩包里是占位符联调时记得替换成自己在微信公众平台申请的小程序凭证。2.3 从零初始化项目骨架pom.xml 与启动类如果压缩包里的项目结构不完整或者你准备自己搭一个同样的后端下面这份最小骨架可以直接抄作业。创建 maven 工程后先配pom.xmlparent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.2/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies提示Spring Boot 版本我习惯锁 2.7.x因为 3.x 的javax.servlet改成jakarta.servlet很多老项目里的拦截器和过滤器代码要改包名实测升级成本不低。棋牌后端追求稳定不用追新。依赖里选了 MyBatis-Plus 和 Redis这两个分别是数据库操作和房间状态缓存的核心。MyBatis-Plus 简化了单表 CRUD避免手写大量重复 XMLRedis 负责房间实时状态和登录 token 的存取。启动类写法如下SpringBootApplication MapperScan(com.yongtai.mj.mapper) public class MjBackendApplication { public static void main(String[] args) { SpringApplication.run(MjBackendApplication.class, args); } }MapperScan指向的是 mapper 接口所在的包这个包路径必须和实际代码位置一致。启动后如果报 “Invalid mapper interface” 或 “Property sqlSessionFactory or sqlSessionTemplate are required”第一先查MapperScan的包路径第二查application.yml里mybatis.mapper-locations配的 XML 路径是否真实存在。这两个问题在压缩包交付的项目里出现频率极高。3. 核心战场房间、牌局状态机与微信登录3.1 三张表定乾坤房间表、玩家表、操作流水表棋牌后端的数据表设计比普通业务系统简单得多核心就三张表。第一张room记录房间维度的信息第二张room_player记录玩家在房间里的状态和分数第三张game_log记录每一手牌的操作流水用于对账和纠纷仲裁。建表 SQL 如下CREATE TABLE room ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, room_no VARCHAR(10) NOT NULL COMMENT 房间号, owner_id BIGINT NOT NULL COMMENT 房主玩家ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0等待中 1对局中 2已结算, round_total INT NOT NULL DEFAULT 4 COMMENT 总局数, round_current INT NOT NULL DEFAULT 0 COMMENT 当前局数, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_room_no (room_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房间表; CREATE TABLE room_player ( id BIGINT NOT NULL AUTO_INCREMENT, room_id BIGINT NOT NULL, player_id BIGINT NOT NULL COMMENT 玩家ID, seat_no TINYINT NOT NULL COMMENT 座位号 0-3, score INT NOT NULL DEFAULT 0 COMMENT 本房间累计积分, is_ready TINYINT NOT NULL DEFAULT 0 COMMENT 0未准备 1已准备, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_room_seat (room_id, seat_no), KEY idx_player_id (player_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房间玩家表; CREATE TABLE game_log ( id BIGINT NOT NULL AUTO_INCREMENT, room_id BIGINT NOT NULL, round_no INT NOT NULL COMMENT 局数序号, player_id BIGINT NOT NULL, action VARCHAR(20) NOT NULL COMMENT 出牌/碰/杠/胡, detail VARCHAR(500) DEFAULT NULL COMMENT 操作详情JSON, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_round (room_id, round_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT牌局操作流水;表设计里有两个细节需要重点说明。room_no是玩家输入的房间号必须唯一且短实战中一般生成 6 位数字避免和真实房间号冲突。game_log的detail字段存 JSON 字符串比如“胡”的操作要记录胡的是哪张牌、含哪些番型、从谁那儿胡的这些信息在结算对账时全靠它。注意game_log的idx_room_round联合索引这是查询对账时最常用的检索路径。没有这个索引复盘一个房间四局牌要全表扫描数据量上去后查询耗时能到秒级这在线上完全不可接受。3.2 牌局状态机从 WAITING 到 SETTLED 的流转控制麻将后端的核心难点不在数据表而在状态流转。我和很多同行聊过大家都认同一个观点棋牌后端做得好不好状态机设计占七成。永泰麻将的状态机可以抽象为三个状态等待中、对局中、已结算。状态定义用枚举写在代码里方便类型校验public enum RoomStatus { WAITING(0, 等待中), PLAYING(1, 对局中), SETTLED(2, 已结算); private final int code; private final String desc; RoomStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } }状态流转的控制逻辑单独抽一个类避免 Controller 里到处都是if (room.getStatus() 0)这种魔法判断。核心是两步准备阶段和结算阶段。准备阶段的状态校验放在startGame方法里public Result startGame(Long roomId) { Room room roomMapper.selectById(roomId); // 只有 WAITING 状态才能开始对局 if (room.getStatus() ! RoomStatus.WAITING.getCode()) { return Result.error(房间当前状态不可开始对局); } // 检查人数和准备状态 ListRoomPlayer players roomPlayerMapper.selectList( new LambdaQueryWrapperRoomPlayer() .eq(RoomPlayer::getRoomId, roomId)); if (players.size() ! 4) { return Result.error(需要4名玩家才能开局); } for (RoomPlayer p : players) { if (p.getIsReady() ! 1) { return Result.error(存在未准备玩家); } } // 状态推进到 PLAYING room.setStatus(RoomStatus.PLAYING.getCode()); roomMapper.updateById(room); return Result.ok(null); }这段代码里状态校验必须放在前置检查之前这是防止并发请求把房间推进到错误状态的手段。LambdaQueryWrapper是 MyBatis-Plus 的链式查询写法比手写 XML 清爽也避免了字符串字段名写错的风险。永泰麻将的“金”设定在这里有一个落点发牌时后端会把哪张牌作为“金”标记写入 Redis 缓存同时广播给四个客户端。实操时要注意“金”牌本身不参与牌墙是额外翻出的这个逻辑写在发牌初始化方法里错误位置会导致整局牌的“金”判定全部错位。结算阶段的状态推进要配合事务一起做防止积分更新一半崩溃导致房间锁死。用Transactional把房间状态更新、四个玩家的积分变更和game_log的结算流水写入绑在一个事务里。这一步是全网棋牌后端最容易出 bug 的地方后面避坑章节详细展开。3.3 微信登录 code2session 与 token 缓存小程序前端调用wx.login()拿到一个临时 code后端拿这个 code 去微信的jscode2session接口换 openid。这个流程是微信小程序后端接入的必备环节代码本身不复杂但有几个参数必须确认清楚。RestController RequestMapping(/api/auth) public class AuthController { Value(${wx.appid}) private String appId; Value(${wx.secret}) private String appSecret; Autowired private RestTemplate restTemplate; Autowired private StringRedisTemplate redisTemplate; Autowired private PlayerMapper playerMapper; PostMapping(/login) public Result login(RequestBody LoginRequest req) { String code req.getCode(); if (code null || code.length() 0) { return Result.error(code不能为空); } String url https://api.weixin.qq.com/sns/jscode2session?appid appId secret appSecret js_code code grant_typeauthorization_code; MapString, Object wxResp restTemplate.getForObject(url, Map.class); String openid (String) wxResp.get(openid); String errCode String.valueOf(wxResp.get(errcode)); if (errCode ! null !null.equals(errCode)) { return Result.error(微信登录失败: wxResp.get(errmsg)); } // openid 作为玩家唯一标识首次登录自动创建账号 Player player playerMapper.findByOpenId(openid); if (player null) { player new Player(); player.setOpenId(openid); player.setNickName(微信用户); player.setCreateTime(new Date()); playerMapper.insert(player); } // 生成自定义 token 并写入 Redis有效期 2 小时 String token UUID.randomUUID().toString().replace(-, ); redisTemplate.opsForValue().set(login:token: token, String.valueOf(player.getId()), 2, TimeUnit.HOURS); LoginVO vo new LoginVO(); vo.setToken(token); vo.setPlayerId(player.getId()); return Result.ok(vo); } }这段代码的关键点有三个。第一wx.secret是微信小程序密钥属于最高敏感级配置绝对不能硬编码在代码里必须从application.yml注入而且这个配置文件在部署到服务器时要设为只有部署账号可读。第二token 用 UUID 生成后存在 Redis不要用微信返回的session_key直接当登录态session_key属于微信侧机密数据用来解密手机号和用户信息不适合做业务侧登录凭证。第三Redis 的过期时间必须和前端请求的频率匹配2 小时适合日常棋牌局如果做赛事模式可以延长到 6 小时但要定期清理过期的 key防止 Redis 内存持续增长。提示RestTemplate需要自己实例化Spring Boot 不自动注入。常见做法是在启动类或配置类中加一个Bean RestTemplate restTemplate() { return new RestTemplate(); }否则运行时直接报空指针。微信登录接口的异常处理也要注意。jscode2session接口返回的 JSON 里openid字段只有成功时才存在失败时返回errcode和errmsg。上面代码先取openid再判断errcode顺序上要先判断错误再取字段实战中我踩过这个坑前端传了过期 code后端拿到errcode40029但因为先取openid拿到 null没有走到错误分支最后返回给前端的是一个 openid 为 null 的“成功”响应前端拿着 null 继续请求房间列表全部 500。4. 前后端联调接口规范、跨域与抓包排查4.1 统一返回体与前端请求封装对齐前后端分离项目实战中接口规范是联调效率的第一道保障。棋牌小程序后端的前端是微信小程序原生框架或 uni-app两种情况下前端团队都要求后端返回结构稳定可预测。业界通用的统一返回体是code msg data三层结构Data public class ResultT { private int code; private String msg; private T data; public static T ResultT ok(T data) { ResultT r new Result(); r.code 0; r.msg ok; r.data data; return r; } public static T ResultT error(String msg) { ResultT r new Result(); r.code -1; r.msg msg; r.data null; return r; } public static T ResultT error(int code, String msg) { ResultT r new Result(); r.code code; r.msg msg; r.data null; return r; } }这里有一个约定code0代表成功code-1代表业务失败code401代表 token 失效。前端请求封装里会优先判断code字段不是 HTTP 状态码因为后端业务校验失败时 HTTP 状态码仍然是 200只有网络层错误才会走 HTTP 非 200 分支。前端请求封装的常见写法是抽一个request.js统一注入 token 和处理响应// utils/request.js const BASE_URL https://mj.example.com/api; function request(path, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method: method, data: data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, success(res) { if (res.data.code 0) { resolve(res.data.data); } else if (res.data.code 401) { // token 失效重新登录 wx.navigateTo({ url: /pages/login/login }); reject(res.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); } module.exports { request };这段代码是前端侧工作但后端必须理解前端会这么写回来约束自己的接口设计。比如data字段必须是对象或数组不能是字符串裸值错误消息msg要写人能看懂的中文不能天天返回 “ERR_SYSTEM_ERROR” 这类黑匣子式错误码。后端写接口时就要想清楚前端拿到msg是直接showToast弹给玩家看的。4.2 跨域配置与代理dev 环境怎么联调跨域问题是前后端分离项目实战里第一个拦路虎。微信小程序开发工具里wx.request默认不允许请求非 https 域名不过开发者工具有一项「不校验合法域名」的开关本地联调时打开即可。但就算域名校验过了后端不配跨域浏览器里的 H5 调试页面照样被拦截。后端全局跨域配置如下Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }allowedOriginPatterns(*)用的是 pattern 而不是allowedOrigins(*)原因在于allowCredentials(true)搭配allowedOrigins(*)在 Spring 里会直接抛异常这是 Spring 的安全策略。改成 pattern 后任意来源的请求都能带上 Cookie 和 Authorization 头适合微信小程序和后台管理 web 双端共用同一个后端。预检请求OPTIONS也必须放行allowedMethods里明确写上了。不写的话小程序端请求带自定义 header比如Authorization会先发一个 OPTIONS 探路后端不响应直接 403前端报 “Provisional headers are shown” 一脸懵。这是跨域排查里最常见的现象。4.3 真机调试用抓包工具看小程序真实请求联调阶段最头疼的问题是“前端说请求发出去了后端说没收到”。这种时候不要靠口嗨直接把请求从黑匣子里捞出来看。抓包工具有多种选择Charles 和 Fiddler 是 PC 端最常用的两类配置方式差异不大核心原理都是把手机或小程序的请求代理到 PC 上。微信小程序真机调试的抓包步骤大致是PC 端 Charles 开启 SSL Proxying手机 Wi-Fi 代理指向 PC 的 IP 和 8888 端口安装 Charles 证书然后微信开发者工具里勾选「真机调试」手机上操作小程序PC 端 Charles 里就能看到每条请求的 URL、header、请求体和响应体。抓包主要看三样东西。第一是实际请求的 URL常见坑是前端 baseUrl 配错多了一个/api或少了一个/api后端控制台没打任何日志。第二是 Authorization 头确认 token 有没有传上去。后端拦截器逻辑是 token 为空直接返回 401如果抓包看到 token 为空问题一定在登录流程或本地缓存不在后端。第三是响应体的code字段如果后端返回code-1而前端表现是白屏问题在后端业务逻辑让后端拿具体msg去排查。提示抓包配置属于开发调试的常规手段切记在受控环境和自己的小程序项目里进行。不要抓取他人小程序的生产流量这既不合规也涉及他人数据安全。5. 部署上线的 5 个翻车现场与避坑记录5.1 先把部署架子搭起来nginx 反代与 HTTPS 证书微信小程序正式环境强制要求所有请求 URL 是 HTTPS 且域名已完成 ICP 备案这在微信公众平台「开发管理 → 服务器域名」里配置。开发阶段可以临时不校验但审核上线前必须改过来这不是后端单方面能决定的前端和后端要一起在提审前完成域名替换。我常用的部署结构是一台云服务器nginx 监听 443 做终结后端 Spring Boot 跑在 8080 端口。nginx 配置里两个关键 location一个转发/api到后端服务一个转发/ws到 WebSocketserver { listen 443 ssl; server_name mj.example.com; ssl_certificate /etc/nginx/ssl/mj.pem; ssl_certificate_key /etc/nginx/ssl/mj.key; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }location /ws/这段是 WebSocket 的关键proxy_set_header Connection upgrade必须显式写否则 nginx 默认用 keep-alive 和上游通信WebSocket 握手直接失败。小程序端wx.connectSocket连上后 3 秒内掉线第一个要查的就是这里。另外注意proxy_pass后面有没有带/带不带斜杠转发的路径拼接规则不同配错会 404这是 nginx 老生常谈的坑。5.2 踩坑一request 合法域名不认 IP 和端口表现象小程序开发工具里打开「不校验合法域名」能正常跑通真机预览一请求就报 “url not in domain list”。原因微信小程序真机环境下wx.request会强制校验域名白名单。开发阶段勾选的「不校验合法域名」只对开发者工具生效真机不认。而且白名单只允许填 ICP 备案过的域名不能填 IP 或带端口号的地址。压缩包交付的项目里前后端联调时常常用的是http://192.168.1.100:8080这种地址正式部署时忘了替换。解决申请域名并备案配置 HTTPS 证书然后在微信公众平台里把https://mj.example.com加入 request 合法域名。WebSocket 地址要填在 socket 合法域名里。改完后切记让前端清缓存重新编译微信开发者工具对域名配置有缓存不清缓存会继续报同样的错误。5.3 踩坑二服务器时钟漂移导致 JWT 直接失效现象本地环境登录正常部署到服务器后同一个 JWT token 立刻提示过期偶发但高频。原因服务器系统时间和真实时间相差数分钟甚至更久。JWT 签发时用new Date()取当前时间写进exp字段服务器时钟慢了 5 分钟签发出来的 token 实际有效期就被吃掉了 5 分钟。我的项目里出现过极端情况服务器 NTP 服务未启动时间偏差半小时所有 token 签发即过期前端表现为“登录成功但下一秒就掉线”。解决部署后第一件事执行date -R看服务器时间和本机对比偏差超过 1 分钟就开启 NTP 同步。Linux 上用timedatectl set-ntp true开启自动同步或者安装 chrony 做时间校准。这个问题出现频率不高但一出现就是全量掉线属于最让人无语的“玄学故障”。5.4 踩坑三静态资源上传被后缀校验卡死现象小程序的图片上传接口在开发环境正常部署后提示文件格式不支持而且只对某些特殊文件名报错。原因压缩包项目里常见一套“上传漏洞”加固方案后端对上传文件做白名单后缀校验但只校验了文件名的最后一个扩展名。前端上传头像时文件名类似avatar.20240101.jpg这没问题但当用户上传的是profile.v1.php.jpg这种多次后缀的文件时某些老代码用File.getName().endsWith(.jpg)判断能通过而规范代码用Arrays.asList(ext.split(\\.)).contains(jpg)就会因中间多出php段而拒绝。Apache 这类中间件还会把1.php.jpg按后一个扩展名识别导致客户端和服务端校验不一致。解决文件名后缀校验规则前后端必须一致统一用最后一个.后面的字符串做白名单比对。服务端改成FilenameUtils.getExtension(fileName).toLowerCase()取扩展名再进白名单集合判断。同时不要信任文件名上传后重命名为 UUID 白名单内扩展名彻底消除多后缀绕过风险。5.5 踩坑四房间并发操作用了共享变量现象两个房间同时开局其中一个房间的玩家出现在另一个房间的通知里或者分数错乱。原因开发时为了赶进度把房间状态写在了一个静态HashMapInteger, Room里key 是房间号。Java 的 HashMap 线程不安全多线程并发 put 时可能丢数据更隐蔽的是开发机单核低并发测不出来一上服务器多核跑满就现原形。这是棋牌后端最常见的并发事故。解决房间实时状态全部迁到 Redis用room:{roomId}做 keyHash 结构存状态、轮次、四个玩家的座位信息。Redis 单线程模型天然解决并发写冲突而且重启后端不丢房间数据。如果项目必须保持内存态就把 HashMap 换成ConcurrentHashMap并且所有写操作加synchronized(roomId.intern())锁但这是过渡方案生产环境我建议直接上 Redis。5.6 踩坑五日志不分级线上问题靠猜现象线上用户反馈胡牌后积分不对后端日志全是log.info一秒钟几千条根本找不到出事那条。原因项目里所有日志都用System.out.println或者统一用log.info没分级没 traceId。一旦要排查某个房间某局牌的问题没有检索维度只能全量日志里 grep 房间号慢且漏。解决接入 Logback 配置按级别输出到不同文件error单独一个文件warn和info分文件日志格式里带时间、线程号、级别。排查问题时先看 error 文件再看对应时间段的 info。具体配置下一章展开这里给一个核心点日志里必须把roomId和roundNo打进去这是棋牌后端排查的第一维度。6. 给后端上“显微镜”traceId 贯穿与最小压测方案最后一招是对后端做一次“体检”让线上问题不再依赖大海捞针。最有效的手段是给每个请求注入 traceId并贯穿日志输出。写一个OncePerRequestFilter在请求进来时生成或透传 traceId放进 MDCComponent public class TraceIdFilter extends OncePerRequestFilter { private static final String TRACE_ID_HEADER X-Trace-Id; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { String traceId request.getHeader(TRACE_ID_HEADER); if (traceId null || traceId.isEmpty()) { traceId UUID.randomUUID().toString().replace(-, ).substring(0, 16); } MDC.put(traceId, traceId); response.setHeader(TRACE_ID_HEADER, traceId); try { chain.doFilter(request, response); } finally { MDC.remove(traceId); } } }然后在 logback 的 pattern 里加上[%X{traceId}]日志就从2024-01-01 10:00:00,123 INFO变成带 traceId 的形式[a3f9c2d1e4b8a7c6]。前端请求出错时把响应头里的 traceId 发给你后端一条grep a3f9c2d1e4b8a7c6 app.log就能拉出整个调用链的日志完全不需要用户复现操作。压测方面棋牌后端不需要整套 JMeter 负载平台一个 wrk 就能测透核心接口。写一个 Lua 脚本模拟登录请求-- post.lua wrk.method POST wrk.headers[Content-Type] application/json wrk.body {code:test_code_001}压测命令wrk -t4 -c100 -d30s -s post.lua http://localhost:8080/api/auth/login这个命令模拟 100 个并发连接持续打 30 秒重点看两个指标Requests/sec 和 Latency 的 p99。登录接口是最典型的 DB Redis 读写场景请求量能到 500 req/s 以上基本算及格。如果 p99 超过 500ms优先查数据库连接池配置和 Redis 连接是否复用。做完整套体检后我的习惯是跑一遍“四局最小闭环”四个模拟客户端完成建房、拉人、开局、出牌、胡牌、结算的全流程中途没有任何报错这个后端才敢推到外网环境。复盘自己经手的几个棋牌后端项目最大的共同教训就是“状态机设计时省下的功夫一定会在上线后加倍还回来”。这个顺序反过来做先圈定状态流转再填业务代码能省掉大量返工。希望这篇笔记能帮你少走几步弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
