微信小程序+SpringBoot实现的麻将馆在线预约与后台管理全套源码-平芜编程栈

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

简介：直接可用的麻将馆预约系统源码，后端用SpringBoot开发，前端是微信小程序，数据库用MySQL，配套完整建表脚本mahjong.sql，含用户注册登录、门店列表展示、预约时段选择、订单生成与状态跟踪、管理员后台管理等核心功能。项目结构规范，包含标准Maven配置（pom.xml）、Spring Boot配置文件、分层Java业务代码（controller/service/mapper）、JUnit单元测试、Dockerfile容器化支持，SQL脚本已预置表结构和初始测试数据，导入即可运行。适合学生做毕业设计或课程大作业，也适合作为Java Web与小程序全栈开发的实操参考。附带零基础入门指南压缩包，覆盖JDK/Maven/IDEA/微信开发者工具环境搭建、小程序对接SpringBoot接口、MyBatis操作MySQL等关键步骤，所有代码经过本地调试验证，无需二次修改就能启动运行。

1. 这不是又一个“Hello World”项目：为什么麻将馆预约系统是全栈学习的黄金切口

你可能已经刷过几十个“SpringBoot+Vue图书管理系统”“SpringBoot+React在线商城”的教程，但真正能让你在简历上写“独立完成过生产级小程序后端”的项目，少之又少。而这个麻将馆预约系统，恰恰卡在了一个极微妙、极真实的平衡点上——它足够轻量，学生两天就能跑通；又足够完整，覆盖了从用户扫码进店、选时段、付定金、到店核销、管理员排班、数据看板的全业务闭环。我带过三届计算机专业毕设，每年都有至少5个学生选“预约类系统”，但90%的人卡在“怎么让小程序和后端真正连上”“怎么把数据库字段映射成前端可读的中文状态”“为什么明明写了拦截器，游客还是能访问订单页”这种细节里。这个项目之所以能“开箱即用”，不是因为删减了功能，而是把那些没人愿意写的“胶水代码”全给你焊死了：比如微信登录态如何安全透传给SpringBoot（不是简单存session，而是用JWT+Redis双校验），比如小程序里“上午/下午/晚上”三个时段，后端怎么对应到数据库里精确到分钟的时间段区间（start_time和end_time字段设计），再比如管理员后台导出Excel时，如何把订单状态码status=2自动翻译成“已到店”，而不是让前端硬编码一堆if-else。关键词里的“麻将馆预约”听着小众，实则是个极佳的领域建模训练场——它天然包含空间（门店）、时间（时段）、资源（包间）、角色（普通用户/店员/管理员）、状态流转（待支付→已预约→已到店→已完成）五大要素，比“图书借阅”更贴近真实商业逻辑。而“微信小程序”这个前端载体，逼你直面移动端特有的限制：没有cookie、本地存储上限30MB、网络请求必须HTTPS、用户身份强依赖微信OpenID。这些不是教科书里的概念，是你调试时看着控制台报错request:fail net::ERR_CONNECTION_REFUSED抓耳挠腮的真实战场。所以别被“麻将”二字劝退，它本质是一个经过高度提炼的“本地生活服务SaaS最小可行模型”，你学到的不是怎么开麻将馆，而是怎么用Java和小程序，把一个线下高频、低决策成本的服务，搬到线上并管起来。

2. 系统整体架构与设计思路拆解：为什么这样分层，而不是那样？

2.1 四层架构：从微信客户端到MySQL，每一层都踩过坑

这个项目的物理结构非常清晰，src目录下是标准的SpringBoot分层：controller（接口门面）、service（业务逻辑）、mapper（数据库操作）、entity（数据模型）。但真正决定它能否“不改代码就运行”的，是这四层之间数据契约的设计哲学。举个最典型的例子：小程序前端展示一个预约卡片，需要显示“XX店 · 3号包间 · 明天下午2点-4点 · ¥88”。这个信息横跨了三张表：store（门店）、room（包间）、appointment（预约）。如果按新手惯性思维，controller里直接new三个mapper去查，再手动组装VO对象，那代码会迅速变成意大利面条。而本项目采用的是DTO驱动的聚合查询：在AppointmentMapper.xml里写了一个复杂的<select>，用LEFT JOIN一次性拉取所有关联字段，并通过<resultMap>精准映射到AppointmentDetailDTO这个专门给前端用的传输对象。你看pom.xml里MyBatis版本是3.4.6，没用最新版，就是因为这个版本对嵌套<collection>的支持最稳定，避免了高版本里常见的N+1查询陷阱。再看service层，所有方法都加了@Transactional，但关键在于@Transactional(rollbackFor = Exception.class)——这是血泪教训。早期测试时发现，用户预约成功但支付回调失败，订单状态卡在“待支付”，而包间已被锁定，导致其他用户无法预约。后来排查发现，Spring默认只对RuntimeException回滚，而微信支付SDK抛出的是IOException，属于checked exception，必须显式声明。这种细节，文档里不会写，只有真刀真枪调过支付接口的人才懂。

2.2 微信生态的深度绑定：不是简单调API，而是理解它的规则

小程序前端和SpringBoot后端的通信，绝不是“发个POST请求就完事”。这个项目在config包里专门建了WechatConfig.java，里面配置了appId、appSecret、mchId（商户号）、apiKey（API密钥）四大核心参数。但更重要的是WechatUtil.java里的两个关键方法：getOpenIdByCode(String code)和unifiedOrder(Map<String, String> params)。前者处理登录，后者处理支付。很多人以为拿到code就能换openId，其实微信有严格校验：code只能用一次，且5分钟内有效；而getOpenIdByCode内部做了双重缓存——先查Redis（key为wechat:openid:${code}），命中则直接返回；未命中则调用微信接口，成功后将openId以wechat:openid:${openId}为key存入Redis，有效期72小时。为什么这么设计？因为小程序用户频繁切换页面时，会反复触发登录，如果每次都调微信接口，不仅慢（平均耗时800ms），还可能触发微信的频率限制。而支付环节更复杂，unifiedOrder生成预支付交易单后，返回的paySign签名必须用特定算法（HMAC-SHA256）计算，且参数顺序必须严格按字典序排列，漏一个空格都会签名失败。项目里PaySignUtil.java的注释里甚至写了“此处顺序不可更改，否则微信返回‘invalid sign’”，这就是实操中抄错一行代码付出的代价。

2.3 数据库设计的务实主义：为什么不用UUID，而用自增主键？

打开mahjong.sql，第一眼看到CREATE TABLE user (id BIGINT PRIMARY KEY AUTO_INCREMENT, ...)，你可能会疑惑：现在不是都流行UUID做主键吗？为什么这里用自增？答案很现实：性能与可读性。这个系统里，user表最大也就几千条记录（一家麻将馆的常客），appointment表日均最多几百单。用BIGINT自增，插入性能碾压UUID（UUID是随机写，导致B+树频繁分裂），而且id作为外键出现在appointment.user_id、order.user_id等字段时，数据库索引效率极高。更重要的是，调试时太方便了——你在后台看到订单id=127，直接去数据库SELECT * FROM appointment WHERE id=127，秒出结果；换成UUID，你得复制一长串a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8，手抖一个字符就查不到。mahjong.sql里另一个精妙设计是appointment表的status字段，类型是TINYINT UNSIGNED，取值范围0-255，但只定义了5个状态：0（待支付）、1（已预约）、2（已到店）、3（已完成）、4（已取消）。为什么不用ENUM？因为ENUM在MySQL里修改枚举值要锁表，而业务迭代中状态很可能增加（比如未来加“爽约扣款中”），TINYINT配合@Enumerated(EnumType.ORDINAL)在Java里映射，扩展性极强。sql目录下还有个init_data.sql，里面预置了3家门店、5个包间、10条测试预约数据，连store_id和room_id的关联关系都配好了，你导入后打开小程序，首页立刻能看到真实数据，而不是一片空白的“暂无数据”。

3. 核心模块实现详解：从登录到核销，每一步都是经验结晶

3.1 用户体系：微信登录不是终点，而是风控起点

小程序端点击“授权登录”，触发wx.login()获取code，然后调用后端/api/user/login接口。这个接口在UserController.java里，核心逻辑是：

@PostMapping("/login") public Result login(@RequestBody Map<String, String> params) { String code = params.get("code"); String encryptedData = params.get("encryptedData"); String iv = params.get("iv"); // 1. 换openId String openId = wechatUtil.getOpenIdByCode(code); // 2. 解密用户敏感信息（昵称、头像） JSONObject userInfo = wechatUtil.decryptUserInfo(encryptedData, iv, openId); // 3. 查询或创建用户 User user = userService.findOrCreateByOpenId(openId, userInfo); // 4. 生成JWT令牌 String token = jwtUtil.generateToken(user.getId(), user.getOpenId()); return Result.success(token); }

这里藏着三个关键点：第一，decryptUserInfo方法里，encryptedData必须是base64解码后的字节数组，很多新手直接传原始字符串导致解密失败；第二，findOrCreateByOpenId不是简单SELECT * FROM user WHERE open_id=?，而是先查，查不到再INSERT，且INSERT语句用了ON DUPLICATE KEY UPDATE（open_id字段加了唯一索引），避免并发时重复插入；第三，JWT的payload里只放了userId和openId，绝不放手机号、身份证号等敏感信息，token本身只是会话凭证，敏感数据永远存在数据库里，由后续接口按需查询。application.yml里JWT配置了expireTime: 7200000（2小时），refreshTime: 3600000（1小时），意思是token过期前1小时可以静默刷新，用户无感。这个刷新逻辑在JwtAuthenticationFilter.java里实现，它拦截所有带Authorization: Bearer xxx的请求，解析token，检查是否快过期，是则生成新token并写入响应头X-Auth-Token，小程序端只需监听这个header更新本地存储即可。

3.2 门店与时段管理：时间不是数字，而是业务规则

StoreController.java的/api/store/list接口返回门店列表，但真正的难点在/api/store/{storeId}/timeslots——获取某个门店某天的可预约时段。这个接口的SQL在StoreMapper.xml里：

<select id="selectAvailableTimeSlots" resultType="com.mahjong.dto.TimeSlotDTO"> SELECT t.id AS timeSlotId, t.start_time AS startTime, t.end_time AS endTime, CASE WHEN COUNT(a.id) > 0 THEN 0 -- 已被预约 ELSE 1 -- 可预约 END AS available FROM time_slot t LEFT JOIN appointment a ON t.id = a.time_slot_id AND a.store_id = #{storeId} AND DATE(a.appointment_date) = #{date} AND a.status IN (0, 1, 2) -- 待支付、已预约、已到店都算占用 WHERE t.store_id = #{storeId} GROUP BY t.id, t.start_time, t.end_time </select>

注意a.status IN (0, 1, 2)这个条件：为什么“已到店”（status=2）也算占用？因为麻将馆的包间是物理资源，用户到店后，即使还没开始打，包间也已被占用，不能让下一个用户预约同一时段。而GROUP BY后用COUNT(a.id) > 0判断是否被占，比写EXISTS子查询更易读，且MySQL优化器对这种写法更友好。TimeSlotDTO里有个available字段，小程序端用它控制按钮禁用状态：available=1时显示“预约”，=0时显示“已满”。mahjong.sql里time_slot表的start_time和end_time是TIME类型，不是DATETIME，因为时段是固定模板（如“14:00-16:00”），与具体日期无关，日期由appointment_date字段单独存储，这样设计查询更高效，也方便门店统一管理时段模板。

3.3 预约与订单：状态机驱动的业务核心

预约流程的精髓，在于AppointmentService.java里的createAppointment方法。它不是一个简单的INSERT，而是一个分布式事务的简化模拟：

@Transactional(rollbackFor = Exception.class) public Result createAppointment(Long userId, Long storeId, Long roomId, Long timeSlotId, Date appointmentDate) { // 1. 校验时段是否可用（双重检查：DB查+内存锁） if (!timeSlotService.isAvailable(timeSlotId, storeId, appointmentDate)) { return Result.fail("该时段已被预约，请选择其他时段"); } // 2. 加分布式锁（Redis SETNX） String lockKey = "lock:appointment:" + storeId + ":" + timeSlotId + ":" + appointmentDate; Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS); if (!locked) { return Result.fail("预约冲突，请稍后重试"); } try { // 3. 再次校验（防止锁期间被抢占） if (!timeSlotService.isAvailable(timeSlotId, storeId, appointmentDate)) { return Result.fail("该时段已被预约，请选择其他时段"); } // 4. 创建预约记录 Appointment appointment = new Appointment(); appointment.setUserId(userId); appointment.setStoreId(storeId); appointment.setRoomId(roomId); appointment.setTimeSlotId(timeSlotId); appointment.setAppointmentDate(appointmentDate); appointment.setStatus(0); // 待支付 appointmentMapper.insert(appointment); // 5. 生成订单（关联预约） Order order = orderService.createOrderFromAppointment(appointment); return Result.success(order.getId()); } finally { redisTemplate.delete(lockKey); // 必须释放锁 } }

这里用了经典的“双重检查+Redis分布式锁”模式。为什么需要锁？因为高并发下，两个用户几乎同时点击预约同一时段，数据库唯一索引（UNIQUE KEY uk_store_time_date (store_id, time_slot_id, appointment_date)）虽然能保证最终一致性，但用户体验极差——第二个用户会看到“服务器错误”，而不是友好的“已满”提示。Redis锁把竞争控制在应用层，让用户感知更平滑。orderService.createOrderFromAppointment方法里，订单金额不是写死的，而是根据store_id查store.price_per_hour，再乘以时段时长（TIMESTAMPDIFF(MINUTE, start_time, end_time)/60），确保不同门店、不同时段价格灵活可配。

3.4 后台管理：不只是CRUD，更是业务指挥中心

管理员后台（/admin路径）的StoreAdminController.java提供了/list、/add、/update、/delete全套接口，但最有价值的是/api/admin/appointment/statistics——数据统计。它返回近7天的预约趋势图数据，SQL如下：

SELECT DATE(appointment_date) as date, COUNT(*) as total, SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) as booked, SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) as arrived, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) as completed FROM appointment WHERE appointment_date >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY DATE(appointment_date) ORDER BY date;

这个查询用CASE WHEN做行转列，比用5个子查询效率高得多。后端返回的JSON里，booked、arrived、completed是三个独立数组，前端ECharts直接渲染折线图。mahjong.sql里还预置了管理员账号：username='admin'，password='$2a$10$...'（BCrypt加密），密码是123456，你可以在UserMapper.xml里看到<select id="findByUsername">的SQL，它用BCryptPasswordEncoder.matches()校验密码，这是Spring Security的标准做法，比自己写MD5盐值安全得多。管理员后台的“核销”功能（/api/admin/appointment/verify）更体现设计功力：它不是简单把status从1改成2，而是先检查appointment_date是否是今天（DATE(appointment_date) = CURDATE()），再检查status=1（必须是已预约状态），最后才更新，并记录verified_at时间戳。这样设计，杜绝了店员误核销昨天订单的可能。

4. 实操部署与避坑指南：从零开始跑通的完整路径

4.1 环境准备：避开JDK和Maven的版本陷阱

第一步永远是环境。项目pom.xml里<java.version>是11，这意味着你必须装JDK 11，而不是你电脑里默认的JDK 8或17。为什么？因为spring-boot-starter-web2.3.x系列对JDK 11做了深度优化，而JDK 17的--illegal-access=deny参数会让某些反射调用直接崩溃。安装JDK 11后，mvn -v检查Maven版本，必须是3.6.3或更高。很多同学用IDEA自带的Maven（3.5.4），编译时报错Could not resolve placeholder 'spring.profiles.active'，就是因为旧版Maven不支持Spring Boot 2.3的属性解析机制。解决方案：下载Maven 3.8.6，解压后在IDEA的Settings > Build > Build Tools > Maven里，把Maven home path指向新解压的目录。application.yml里数据库配置是：

spring: datasource: url: jdbc:mysql://localhost:3306/mahjong?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai username: root password: 123456

注意serverTimezone=Asia/Shanghai，这是MySQL 8.0+的强制要求，漏掉会导致java.sql.SQLException: The server time zone value 'XXX' is unrecognized。如果你用的是MySQL 5.7，可以删掉这个参数，但强烈建议升级到8.0，因为mahjong.sql里用了JSON类型字段（store.config存营业时间配置），5.7不支持。

4.2 数据库导入：三步走，拒绝“表不存在”错误

导入mahjong.sql不是双击就完事。正确步骤：
1.新建数据库：用MySQL客户端（如Navicat或命令行）执行CREATE DATABASE mahjong CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。必须用utf8mb4，因为小程序用户昵称可能含emoji（如“张三😄”），utf8不支持。
2.设置时区：执行SET GLOBAL time_zone = '+8:00';，否则appointment_date字段可能存成UTC时间，导致查询错乱。
3.导入脚本：在mahjong库下执行source /path/to/mahjong.sql;。如果报错Error Code: 1067. Invalid default value for 'create_time'，说明你的MySQL严格模式开启，需要临时关闭：SET SQL_MODE='';后再导入。

导入成功后，用SELECT * FROM user LIMIT 5;确认有测试数据。你会发现open_id字段全是oAbcDefGhiJklMnoPqrStUvWxyZ这样的格式，这是微信测试号生成的模拟openId，小程序真机调试时会自动替换为真实值。

4.3 小程序端配置：五个必须改的文件

微信开发者工具打开小程序项目（fyqa5Hynf3O9caEIuly4-master-...目录），必须修改以下文件：
-project.config.json：把appid改成你自己的小程序AppID（在微信公众平台获取）。
-utils/config.js：修改baseUrl为你的后端地址，如https://your-domain.com/api。如果是本地调试，填http://localhost:8080/api，但必须在微信开发者工具的详情 > 本地开发 > 不校验合法域名打勾。
-app.js：onLaunch里wx.login()后调用的接口URL，要和config.js一致。
-pages/index/index.js：onLoad里请求门店列表的URL，也要同步。
-project.config.json里的setting.minified设为false，否则压缩后调试困难。

最关键的一步：在微信公众平台，进入“开发管理 > 开发者工具”，把你的本机IP（如192.168.1.100）添加到“服务器域名”里的request合法域名。否则wx.request会直接被微信拦截，控制台只显示fail net::ERR_CONNECTION_REFUSED，根本看不到后端日志。

4.4 启动与验证：如何确认每一步都走对了

启动顺序严格遵循依赖关系：
1.先启MySQL：确保mysql -u root -p能登录，且SHOW DATABASES;能看到mahjong。
2.再启后端：在IDEA里右键MahjongApplication.java→Run。观察控制台，出现Started MahjongApplication in X.XXX seconds且无ERROR，表示SpringBoot启动成功。此时访问http://localhost:8080/swagger-ui.html（项目集成了Swagger），能看到所有API文档。
3.最后启小程序：微信开发者工具里点击“编译”，看控制台是否输出[INFO] 登录成功，token: eyJhb...。如果没有，检查config.js的baseUrl和网络配置。

验证点清单：
- ✅ 小程序首页显示3家门店（/api/store/list返回数据非空）
- ✅ 点击某门店，跳转到时段页，显示“14:00-16:00”等时段（/api/store/{id}/timeslots返回available=1）
- ✅ 选择时段，点击预约，弹出支付窗口（后端/api/order/create返回payParams）
- ✅ 管理员后台登录admin/123456，能看到今日预约列表（/api/admin/appointment/today）

如果卡在某一步，优先看后端控制台日志。比如小程序显示“网络错误”，而后端没任何日志，说明请求根本没到后端——90%是域名配置问题；如果后端有404日志，说明config.js的baseUrl路径错了；如果后端报500且日志有NullPointerException，大概率是application.yml里数据库密码错了。

5. 常见问题与实战排查技巧：那些文档里不会写的真相

5.1 “小程序白屏”问题：90%源于这3个配置

小程序启动后一片白，控制台无报错？别急着重装开发者工具，按顺序检查：
1.检查app.json的pages数组：项目里pages是["pages/index/index", "pages/store/store", ...]，如果你删过某个页面，但没从app.json里移除，微信会找不到入口文件，直接白屏。解决方案：打开app.json，确认第一个路径pages/index/index对应的index.wxml文件存在且无语法错误（比如多了一个</view>闭合标签）。
2.检查project.config.json的miniprogramRoot：这个字段必须是./（当前目录），如果被改成./miniprogram/，而你的代码就在根目录，微信会去./miniprogram/pages/index/index.wxml找文件，自然找不到。解决方案：用文本编辑器打开project.config.json，搜索miniprogramRoot，确保其值为"./"。
3.检查utils/request.js的拦截器：项目里request.js有全局错误拦截：

if (res.statusCode >= 400) { wx.showToast({title: '请求失败', icon: 'none'}); return Promise.reject(res); }

如果后端返回401 Unauthorized，这个拦截器会弹窗，但如果你在onLoad里没catch，页面就会卡住。解决方案：在调用API的地方加上.catch(err => console.error(err))，或者在拦截器里加console.log('API Error:', res)，把错误打出来。

5.2 “支付失败”排查：微信的沉默比报错更可怕

小程序调起支付后，一直转圈，最后提示“支付失败”。这不是代码问题，而是微信的“静默失败”机制。排查步骤：
-第一步，看后端日志：支付接口/api/order/pay是否被调用？如果没日志，说明小程序没发请求——检查pages/order/order.js里wx.requestPayment的success回调里，是否漏写了that.setData({paying: false})，导致loading状态一直挂着。
-第二步，看微信商户平台：登录https://pay.weixin.qq.com，进入“交易中心 > 交易查询”，用订单号搜索。如果查不到，说明unifiedOrder接口根本没调通；如果状态是“支付中”，说明用户没完成支付；如果是“已关闭”，说明预支付单超时（2小时）。
-第三步，看PaySignUtil.java：重点检查sign计算的参数列表，必须包含appId、timeStamp（字符串，不是数字）、nonceStr、package、signType，且顺序必须字典序。项目里用TreeMap自动排序，但如果你手写HashMap，顺序错一个，签名就无效。一个快速验证法：把PaySignUtil.java里生成的sign，和微信官方签名工具（https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=20_1）计算的结果对比，必须完全一致。

5.3 Docker部署踩坑：镜像体积与端口映射

Dockerfile内容简洁：

FROM openjdk:11-jre-slim VOLUME /tmp ARG JAR_FILE=target/mahjong-0.0.1-SNAPSHOT.jar COPY ${JAR_FILE} app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

但实际部署时常见两个坑：
-镜像体积爆炸：openjdk:11-jre-slim基础镜像约200MB，加上jar包50MB，最终镜像300MB+。如果服务器带宽小，推送慢。解决方案：改用eclipse-jetty:jre11-slim，体积仅120MB，且内置Jetty，启动更快。
-端口映射失败：docker run -p 8080:8080 mahjong后，访问http://localhost:8080超时。原因：SpringBoot默认绑定localhost，容器内localhost是容器自身，外部无法访问。解决方案：在application.yml里加server.address: 0.0.0.0，或启动时加参数-Dserver.address=0.0.0.0。

5.4 毕业设计答辩加分项：三个可立即落地的扩展点

如果你要用这个项目做毕设，光跑通远远不够。评委最爱问“你做了哪些创新或改进”，以下是三个零成本、高价值的扩展，5分钟就能加进去：
-增加短信通知：在AppointmentService.createAppointment末尾，加一行smsService.send("您的预约已成功，时间：${date}")。用阿里云短信SDK（aliyun-java-sdk-dysmsapi），pom.xml加依赖，application.yml配accessKeyId和accessKeySecret，10行代码搞定。答辩时说：“我集成了短信通知，提升用户履约率”，瞬间拉开差距。
-增加预约提醒：用Quartz定时任务，每天9点扫描appointment_date = tomorrow且status=1的订单，调用微信模板消息API推送提醒。pom.xml加spring-boot-starter-quartz，写个@Scheduled(cron="0 0 0 9 * ?")方法，30行代码。
-增加数据看板：在管理员后台加/api/admin/dashboard接口，SQL用SELECT COUNT(DISTINCT user_id) FROM appointment WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)统计月活，配合ECharts画饼图。评委看到“用户活跃度分析”，眼睛会亮。

最后分享一个个人体会：去年指导一个学生，他花三天跑通项目，又花两周加了短信和提醒，答辩时演示了从用户预约、收短信、到店扫码核销的全流程，评委当场问“这个核销码是怎么生成的”，他答“用Hutool的SecureUtil.md5(userId + appointmentId + timestamp)”，评委点点头说“安全意识不错”。你看，技术深度不在多，而在准——抓住一个点，把它做透，比泛泛而谈十个功能更有说服力。这个麻将馆系统，就是你证明自己“真懂全栈”的最佳证物。

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