简介：这是一套面向高校数据库与Java课程设计初学者的游泳馆管理系统实践项目，聚焦中小型场馆日常运营痛点，提供会员管理、在线预约、场地调度与收费记账四大核心功能模块，助力学生将ER建模、SQL设计、Java Swing/FX界面开发及事务处理等理论知识落地为完整可运行系统。资源包共1286个文件，含28个核心Java源码文件（如VIP.java、ManagerDao.java）、29个编译后class文件、1132个htm页面构成前端界面体系，辅以sql数据库脚本、js交互逻辑及gif/png界面资源，整体3.81MB，结构清晰、模块边界明确，便于分层学习与调试。已有1537人下载学习，读者可直接导入运行，获取完整MVC结构实现、预约冲突检测逻辑、多级会员权限控制代码及配套数据库（mdf/ldf）设计范例，是理解业务系统数据流与Java桌面应用开发的典型教学案例。
1. 游泳馆管理系统：不是做个登录页就叫“管理系统”，它得管得住排班、锁得住泳道、算得清每张计次卡的剩余次数
某高校课程设计答辩现场，A同学演示完“游泳馆管理系统”首页后，导师直接问：“会员买了10次卡，游了3次，系统怎么确保第4次刷卡时才扣减？如果同一张卡在两个闸机同时刷，会不会重复扣次？”——全场安静。这不是玄学，是真实业务里最基础的并发控制与状态一致性问题。这套游泳馆管理系统，面向的是中小型场馆的实际运营场景：前台需快速登记散客/会员、教练要实时查看带教排班、救生员依赖电子巡更打卡、财务月底要导出按泳道/时段/卡种分类的营收报表。它不追求炫酷大屏，但必须让前台阿姨三秒完成续费、让救生员手机端一键上报异常、让系统在断网30分钟内仍能离线验卡。技术栈锁定 Java（非 Spring Boot 全家桶堆砌，而是基于 Servlet + JDBC + JSP 的轻量可控组合），核心价值在于：可落地、可调试、可交接、可答辩。如果你正为毕设/课设卡在“功能堆砌却逻辑断裂”“代码能跑但不敢解释为什么这么写”，这份方案就是为你写的。
2. 需求拆解与模块划分：从“我要做个系统”到“这四个模块必须闭环”
做系统最怕一上来就敲代码。我带过三届学生做类似项目，血泪经验是：先用一张纸画清“谁在什么时间、对什么数据、执行什么操作、产生什么结果”。游泳馆不是孤立存在，它有明确的角色链、动作链和数据流。我们把需求压成四块硬骨头：会员生命周期管理、泳道资源调度、教练-学员-课程绑定、营收与对账闭环。每一块都必须能独立验证，且模块间只通过明确定义的数据接口通信，避免后期改一个按钮导致整个报表崩掉。
2.1 会员管理：不止是增删改查，关键是状态机驱动的卡务逻辑
会员表（member）不是简单存个姓名电话。它必须承载三种核心状态：NORMAL（正常可用）、FROZEN（冻结，如欠费或投诉中）、EXPIRED（过期）。而计次卡（card）是独立实体，与会员是一对多关系。关键设计点在于：卡次扣减必须原子化，且不可逆。我们不靠前端JS判断“还剩几次”，而是在数据库层用UPDATE card SET remaining_times = remaining_times - 1 WHERE id = ? AND remaining_times > 0加ROW_COUNT()检查影响行数。若返回0，说明已无次数，拒绝扣减——这是防止前端绕过校验的最后防线。
-- 创建计次卡表，含严格约束 CREATE TABLE card ( id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, card_type ENUM('TIMES', 'MONTHLY', 'SEASONAL') NOT NULL, total_times INT DEFAULT 0, -- 总次数（仅TIMES卡有效） remaining_times INT NOT NULL DEFAULT 0, start_date DATE NOT NULL, end_date DATE NOT NULL, status ENUM('ACTIVE', 'USED_UP', 'EXPIRED', 'CANCELLED') DEFAULT 'ACTIVE', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, CONSTRAINT chk_remaining_non_negative CHECK (remaining_times >= 0), CONSTRAINT chk_date_range CHECK (start_date <= end_date) );提示：
CHECK约束在 MySQL 8.0.16+ 才默认启用，低版本请用触发器替代。别省这一步，否则测试时出现remaining_times = -1会把你拖进排查黑洞。
2.2 泳道资源调度：用“时段-泳道-状态”三维矩阵解决抢道冲突
泳道不是静态资源，它是随时间动态变化的。传统做法是建个swimming_lane表加个status字段，但无法回答：“周三19:00-20:00，3号泳道是否被预订？” 我们采用时段切片预占模型：将一天划分为15分钟粒度（共96个时段），每个时段-泳道组合生成唯一记录（lane_schedule）。预订时，系统检查该时段内所有目标泳道的status是否为AVAILABLE；确认后批量更新为BOOKED。这样，前台选“3号泳道，今晚19:00”，后台实际执行的是：
-- 假设预订19:00-20:00（4个15分钟时段），泳道id=3 UPDATE lane_schedule SET status = 'BOOKED', booked_by = ? WHERE lane_id = 3 AND time_slot IN ('19:00', '19:15', '19:30', '19:45') AND status = 'AVAILABLE'; -- 必须检查 ROW_COUNT() == 4，否则部分失败需回滚这种设计让“临时加开一场培训”变得极简单：只需插入4条新记录，无需修改任何已有数据。比用start_time/end_time区间查询快一个数量级，也彻底规避了区间重叠计算的复杂度。
2.3 教练-学员-课程绑定：用“预约单”作为事实唯一来源
很多方案把“课程表”做成静态配置，结果教练调休时要手动改几十个学员的课表。我们反其道而行：不存“课程表”，只存“预约单”（appointment）。每张预约单关联一个教练、一个学员、一个泳道、一个起止时间。系统首页的“今日课表”是实时聚合appointment表生成的视图。当教练请假，只需将当天所有coach_id = ? AND date = CURDATE()的预约单status改为CANCELLED，学员端立刻看到“您的课程已取消”，后台自动触发短信通知。没有冗余数据，就没有同步不一致的风险。
2.4 营收与对账：每一笔收入必须可追溯到具体动作
财务最恨“系统说收了5万，但现金日记账只有4.8万”。我们的设计原则是：所有收入动作必须对应一条不可删除的流水（revenue_record）。散客扫码支付、会员卡续费、团课报名费，全部走同一张表：
CREATE TABLE revenue_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, trade_no VARCHAR(64) UNIQUE NOT NULL, -- 第三方支付单号或系统生成流水号 amount DECIMAL(10,2) NOT NULL, channel ENUM('CASH', 'WECHAT', 'ALIPAY', 'CARD_RECHARGE') NOT NULL, biz_type ENUM('TIMES_PURCHASE', 'MONTHLY_RENEW', 'GROUP_CLASS_FEE', 'PRIVATE_LESSON') NOT NULL, biz_ref_id BIGINT, -- 关联业务ID：card.id / appointment.id / class.id operator VARCHAR(32) NOT NULL, -- 操作员工号 created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, remark TEXT );月底对账时，财务导出revenue_record按channel和biz_type分组汇总，再与微信/支付宝后台账单逐条比对trade_no。哪怕某天网络抖动导致支付成功但系统未记账，只要查trade_no就能定位，而不是靠人肉翻日志猜。
3. 总体架构设计：三层结构与四个模块的职责划分
这套系统没上微服务，也没用Redis缓存热点数据——因为中小型场馆日活用户通常<200，MySQL单机完全扛得住。我们坚持Servlet + JDBC + JSP 的经典三层，但每一层都做了针对性加固，确保代码可读、可测、可维护。架构不是炫技，是让A同学三天内能看懂B同学写的排班模块，并能独立修复bug。
3.1 表现层（JSP + 自定义标签库）：拒绝脚本混杂，用标签封装重复逻辑
JSP里禁止写Java代码块（<% %>）。所有数据库查询、格式化、权限判断，全部封装进自定义JSP Tag。例如显示会员卡剩余次数：
<!-- 在 /WEB-INF/tags/cardStatus.tag --> <%@ tag description="显示会员卡状态" pageEncoding="UTF-8"%> <%@ attribute name="card" required="true" type="com.example.model.Card"%> <c:choose> <c:when test="${card.status == 'USED_UP'}"> <span class="badge bg-danger">已用完</span> </c:when> <c:when test="${card.status == 'EXPIRED'}"> <span class="badge bg-secondary">已过期</span> </c:when> <c:otherwise> <span class="badge bg-success">剩余${card.remainingTimes}次</span> </c:otherwise> </c:choose>使用时只需<my:cardStatus card="${memberCard}"/>。好处是什么？当产品说“过期卡要加个‘可续费’按钮”，你只改一个tag文件，全站生效。不用grep全项目找<%=card.getRemainingTimes()%>。
3.2 业务逻辑层（Service + Transaction Template）：用模板方法固化事务边界
所有Service方法必须以@Transactional开头（Spring管理）或手动控制Connection（原生JDBC）。我们采用后者，因为学生更容易理解“事务在哪开始、在哪提交、在哪回滚”。核心是TransactionTemplate工具类：
// TransactionTemplate.java public class TransactionTemplate { public static <T> T execute(ConnectionProvider provider, Function<Connection, T> action) throws SQLException { Connection conn = null; try { conn = provider.getConnection(); conn.setAutoCommit(false); // 关键！开启事务 T result = action.apply(conn); conn.commit(); // 成功则提交 return result; } catch (Exception e) { if (conn != null) { conn.rollback(); // 失败则回滚 } throw e; } finally { if (conn != null) conn.close(); } } }扣卡次的Service方法长这样：
public void consumeCardTimes(long cardId) throws SQLException { TransactionTemplate.execute(this::getConnection, conn -> { // 1. 查询并锁定卡记录（for update） String sql = "SELECT remaining_times, status FROM card WHERE id = ? FOR UPDATE"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setLong(1, cardId); ResultSet rs = ps.executeQuery(); if (!rs.next()) throw new IllegalArgumentException("卡不存在"); if (!"ACTIVE".equals(rs.getString("status"))) { throw new IllegalStateException("卡状态异常，不可扣次"); } int remaining = rs.getInt("remaining_times"); if (remaining <= 0) { throw new IllegalStateException("次数不足"); } // 2. 执行扣减 String updateSql = "UPDATE card SET remaining_times = remaining_times - 1 WHERE id = ?"; try (PreparedStatement ups = conn.prepareStatement(updateSql)) { ups.setLong(1, cardId); int affected = ups.executeUpdate(); if (affected != 1) { throw new SQLException("扣次失败：未更新到记录"); } } } return null; }); }注意：
FOR UPDATE是关键。它让数据库给这条记录加行锁，阻止其他线程同时读取并扣减同一张卡。没有它，并发场景下必然超扣。
3.3 数据访问层（DAO + PreparedStatement 预编译）：杜绝SQL注入，统一参数绑定
DAO层只做一件事：把Java对象转成SQL参数，把ResultSet转成Java对象。所有SQL都用PreparedStatement，绝不拼接字符串。例如查询某天所有预约：
public List<Appointment> findAppointmentsByDate(LocalDate date) throws SQLException { String sql = "SELECT * FROM appointment WHERE DATE(start_time) = ? ORDER BY start_time"; try (PreparedStatement ps = connection.prepareStatement(sql)) { ps.setDate(1, Date.valueOf(date)); // 自动类型转换，安全 ResultSet rs = ps.executeQuery(); return mapToAppointments(rs); } }学生常犯错误是WHERE start_time LIKE '+ date +%，这既是SQL注入入口，又因索引失效导致慢查询。用DATE()函数虽损失一点性能，但胜在语义清晰、可读性强，且对日活<200的场景无感知。
3.4 配置与工具层（Properties + 自定义Logger）：让环境切换和问题定位不靠猜
config.properties文件管理所有可变参数：
# 数据库 db.url=jdbc:mysql://localhost:3306/swimming?useSSL=false&serverTimezone=Asia/Shanghai db.username=root db.password=123456 # 日志 log.level=DEBUG log.file.path=/var/log/swimming/app.log # 业务 default.lane.count=8 max.times.per.card=100Logger不直接用System.out，而是封装：
public class AppLogger { private static final Logger logger = LoggerFactory.getLogger(AppLogger.class); public static void info(String msg, Object... args) { logger.info("[{}] {}", Thread.currentThread().getName(), String.format(msg, args)); } // 关键：记录操作员和请求ID，便于审计 public static void audit(String operator, String action, String detail) { logger.info("[AUDIT][{}][{}] {}", operator, action, detail); } }前台操作时，每笔扣卡都调用AppLogger.audit("frontdesk001", "CONSUME_TIMES", "cardId=12345, remaining=7");。出问题时，运维直接搜AUDIT关键字，5分钟定位到谁、什么时候、干了什么。
4. 核心功能实现：从“能用”到“敢交”的关键代码与设计说明
这一章不讲理论，只放真正答辩时会被追问的代码和设计理由。每段代码背后都有一个“为什么不能那样写”的故事。
4.1 会员注册与实名认证：身份证号校验不是摆设
很多方案用正则^\\d{17}[\\dXx]$就完事，但这是错的。18位身份证最后一位是校验码，需按国标GB11643-1999算法验证。我们封装了IdCardValidator：
public class IdCardValidator { private static final int[] WEIGHT = {7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2}; private static final char[] CHECK_CODE = {'1', '0', 'X', '9', '8', '7', '6', '5', '4', '3', '2'}; public static boolean isValid(String idCard) { if (idCard == null || idCard.length() != 18) return false; String body = idCard.substring(0, 17); char check = idCard.charAt(17); // 检查前17位是否全数字 if (!body.matches("\\d{17}")) return false; // 计算校验码 int sum = 0; for (int i = 0; i < 17; i++) { sum += (body.charAt(i) - '0') * WEIGHT[i]; } char expected = CHECK_CODE[sum % 11]; return Character.toUpperCase(check) == expected; } }避坑：曾有学生用第三方库校验，但打包时漏了依赖，上线后所有注册失败。自己实现20行代码，零依赖，永远可靠。
4.2 泳道智能推荐：根据水温、深度、空闲率动态排序
前台录入“我想游自由泳”，系统不该随机推荐泳道。我们按三个维度加权：
- 水温匹配度（权重40%）：
ABS(target_temp - current_temp)，越小越好 - 深度适配度（权重30%）：初学者推荐1.2m，高手推荐1.8m以上
- 空闲率（权重30%）：
1 - (booked_slots / total_slots)
最终得分 =40*(1-归一化温差) + 30*(1-归一化深度差) + 30*空闲率。代码实现用Stream排序：
public List<Lane> recommendLanes(String swimStyle, double waterTemp, double depth) { return laneDao.findAll().stream() .filter(lane -> lane.getStatus() == LaneStatus.AVAILABLE) .map(lane -> { double tempScore = 1.0 - Math.min(1.0, Math.abs(waterTemp - lane.getWaterTemp()) / 5.0); double depthScore = (swimStyle.equals("BEGINNER") && lane.getDepth() <= 1.3) || (swimStyle.equals("ADVANCED") && lane.getDepth() >= 1.6) ? 1.0 : 0.3; double freeRate = (double) lane.getFreeSlotsToday() / lane.getTotalSlots(); double score = 0.4 * tempScore + 0.3 * depthScore + 0.3 * freeRate; return new LaneWithScore(lane, score); }) .sorted((a, b) -> Double.compare(b.getScore(), a.getScore())) // 降序 .map(LaneWithScore::getLane) .limit(3) // 只推3个 .collect(Collectors.toList()); }4.3 教练排班冲突检测：用“时间槽位掩码”秒级判断
排班界面拖拽一个时间段，系统要实时提示“与XX教练已有课程冲突”。如果每次拖都查数据库，体验卡顿。我们用位运算掩码预计算：
- 一天96个15分钟时段 → 用一个
long（64位）不够，用两个long（128位）覆盖 - 每个教练的排班数据存为
long[] scheduleMask = new long[2] - 拖拽新时段
[start, end)时，计算其覆盖的bit位范围，用&运算检测是否与现有mask重叠
public class ScheduleMask { // 位图：第i位为1表示第i个15分钟时段被占用（0~95） private final long[] mask = new long[2]; // 0-63, 64-95 public void occupy(int startSlot, int endSlot) { for (int i = startSlot; i < endSlot; i++) { if (i < 64) { mask[0] |= (1L << i); } else { mask[1] |= (1L << (i - 64)); } } } public boolean hasConflict(int startSlot, int endSlot) { for (int i = startSlot; i < endSlot; i++) { long bit; if (i < 64) { bit = (1L << i) & mask[0]; } else { bit = (1L << (i - 64)) & mask[1]; } if (bit != 0) return true; } return false; } }前端传startSlot=72（18:00）、endSlot=76（19:00），后端毫秒级返回冲突结果。比查库快10倍，且无并发问题。
4.4 营收日报生成：用存储过程保证数据一致性
每天凌晨2点，系统自动生成昨日营收日报（daily_revenue_report）。如果用Java代码查一堆表再组装，一旦中途崩溃，日报就缺失。我们用MySQL存储过程，利用数据库事务保证原子性：
DELIMITER $$ CREATE PROCEDURE GenerateDailyReport(IN reportDate DATE) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; START TRANSACTION; -- 清空昨日报告（幂等） DELETE FROM daily_revenue_report WHERE report_date = reportDate; -- 插入汇总数据（一次SQL搞定） INSERT INTO daily_revenue_report ( report_date, cash_amount, wechat_amount, alipay_amount, times_card_revenue, monthly_card_revenue, group_class_revenue, private_lesson_revenue ) SELECT reportDate, COALESCE(SUM(CASE WHEN channel='CASH' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN channel='WECHAT' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN channel='ALIPAY' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN biz_type='TIMES_PURCHASE' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN biz_type='MONTHLY_RENEW' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN biz_type='GROUP_CLASS_FEE' THEN amount ELSE 0 END), 0), COALESCE(SUM(CASE WHEN biz_type='PRIVATE_LESSON' THEN amount ELSE 0 END), 0) FROM revenue_record WHERE DATE(created_at) = reportDate; COMMIT; END$$ DELIMITER ;Java端只需定时调用CALL GenerateDailyReport(DATE_SUB(CURDATE(), INTERVAL 1 DAY));。崩溃？数据库自动回滚，明天重试即可。
5. 常见问题排查与避坑指南：那些让你熬夜到三点的“灵异事件”
写代码最痛苦的不是不会写，而是写了半天发现是某个不起眼的细节在作祟。以下是我在多个项目中踩过的坑，按发生频率排序，每一条都附带真实现象、根因和解决方案。照着检查，能省你至少8小时debug时间。
5.1 现象：会员续费后，前台刷新页面，卡次数没变，但数据库里已更新
原因：JSP页面用了request.setAttribute("card", card)，但Service层更新后，Controller没重新查库赋值，导致页面显示旧对象。更隐蔽的是：某些IDE的热部署（HotSwap）会缓存JSP编译后的class，即使改了Java代码，页面仍渲染旧值。
解决：
- Controller中，所有涉及数据变更的操作后，必须重新调用DAO查询最新数据并
setAttribute - 禁用IDE热部署，改用
mvn compile+ 手动重启Tomcat（开发期效率损失可接受，胜过排查幻觉bug） - 在JSP顶部加
<% response.setHeader("Cache-Control", "no-cache"); %>强制不缓存
5.2 现象：泳道预订时，两个前台同事同时点“预订3号泳道”，结果系统生成两条重叠的预约单
原因：没加数据库行锁。SELECT * FROM lane_schedule WHERE lane_id=3 AND time_slot='19:00'返回空，两人同时执行INSERT，都成功。
解决：
- 预订逻辑必须用
SELECT ... FOR UPDATE锁定目标记录（见2.2节代码） - 或改用
INSERT ... ON DUPLICATE KEY UPDATE，前提是lane_id+time_slot有唯一索引 - 绝对不要用“先查再插”的逻辑处理并发写入
5.3 现象：导出Excel报表时，中文全是乱码（????），但数据库里显示正常
原因：JSP页面指定了charset=UTF-8，但POI生成Excel时未设置工作表编码，或Tomcat的URIEncoding未配为UTF-8，导致URL参数中的中文被截断。
解决：
- Tomcat
conf/server.xml中，<Connector>标签加URIEncoding="UTF-8" - POI生成时，显式设置单元格编码：
CellStyle style = workbook.createCellStyle(); Font font = workbook.createFont(); font.setCharset(Font.DEFAULT_CHARSET); // 关键！ style.setFont(font); - 导出接口的
Content-Disposition头必须用URLEncoder.encode(filename, "UTF-8")
5.4 现象：教练排班页面，拖拽一个时间段后，松手瞬间，时间条跳回原位置，像被“弹回”
原因：前端JavaScript监听了dragend事件，但AJAX请求是异步的。用户松手后，JS立即执行element.style.left = originalLeft，而此时后端响应还没回来，视觉上就是“弹回”。
解决：
- 拖拽开始时，禁用所有交互：
document.body.style.pointerEvents = 'none' - 拖拽结束，发起请求，收到成功响应后再恢复：
document.body.style.pointerEvents = 'auto' - 同时给拖拽元素加
transition: left 0.2s ease，让移动更平滑，掩盖网络延迟
5.5 现象：系统运行一周后，revenue_record表查询变慢，EXPLAIN显示没走索引
原因：created_at字段没建索引，而日报查询WHERE DATE(created_at) = ?无法使用索引（函数索引MySQL 5.7不支持）。
解决：
- 新增
report_date DATE字段，写入时同步填充DATE(created_at) - 在
report_date上建索引：CREATE INDEX idx_report_date ON revenue_record(report_date) - 查询改为
WHERE report_date = ?，秒级响应 - （额外建议）对大表定期归档，
INSERT INTO revenue_archive SELECT * FROM revenue_record WHERE report_date < DATE_SUB(CURDATE(), INTERVAL 1 YEAR); DELETE ...
6. 答辩与验收：用“三页纸”让老师当场点头的实战技巧
答辩不是背稿，是证明你真的懂这个系统。我带过的项目，凡用这套方法准备的，90%以上一次通过。核心就三点：讲清一个痛点、演示一个闭环、暴露一个思考。别试图展示所有功能，那会让老师觉得你在堆砌。
6.1 答辩PPT只做三页：痛点页、闭环页、思考页
第一页：痛点页（30秒讲完）
不要列“系统包含XX模块”。直接放一张图：某游泳馆前台手写登记表，密密麻麻写着“张三，19:00，3号道，10次卡，已扣3次”，旁边打个红叉。标题：“人工登记导致3大问题：① 卡次易算错（举实例：上月多扣27次）；② 泳道冲突频发（7月投诉12起）；③ 营收对账耗时4小时/天”。然后一行字：“本系统用数据库行锁+时段切片+不可删除流水，根治这三点”。第二页：闭环页（2分钟演示）
用录屏代替现场操作（防网络/环境问题）。演示一个完整业务流：
① 前台录入新会员“李四”，身份证号11010119900307231X→ 系统实时校验通过（停顿1秒，让老师看清校验码计算）
② 为其购买10次卡 → 页面显示“剩余10次”，数据库card表remaining_times=10
③ 预约今晚19:00-20:00的3号泳道 → 系统推荐“3号道（水温27.5℃，空闲率85%）”，点击确认
④ 刷卡机模拟扣次 → 页面刷新，“剩余9次”，同时revenue_record新增一条TIMES_PURCHASE流水
⑤ 打开数据库，SELECT * FROM lane_schedule WHERE lane_id=3 AND time_slot IN ('19:00','19:15','19:30','19:45')→ 全部status=BOOKED
这5步，环环相扣，证明你不是拼凑功能，而是构建了数据流。第三页：思考页（1分钟引发讨论）
放一个问题：“如果场馆要接入政府监管平台，需实时上报每笔消费，但当前网络不稳定，如何保证上报不丢？”
然后给出你的方案：
✅ 方案1（简单）：本地消息队列（如Apache ActiveMQ嵌入版），消费成功再删记录
✅ 方案2（推荐）：在revenue_record加upload_status ENUM('PENDING','SUCCESS','FAILED')，后台定时扫描PENDING记录重试，失败超3次发邮件告警
❌ 不选方案：直接HTTP上报，失败即丢弃（老师会追问“丢数据谁负责？”）
这一页不求完美，但展现你考虑了生产环境的真实约束。
6.2 老师必问的5个问题及应答策略
| 问题 | 应答策略 | 为什么有效 |
|---|---|---|
| “为什么不用Spring Boot？” | “课程要求体现JDBC底层原理。Spring Boot自动配置会隐藏连接池、事务管理等关键机制，不利于理解数据一致性保障手段。” | 把技术选型上升到教学目标，而非能力不足 |
| “并发扣卡怎么保证不超扣？” | 立刻打开代码，指出SELECT ... FOR UPDATE和ROW_COUNT()检查两处，并说：“这是数据库层面的最终保障，比应用层加锁更可靠。” | 用具体代码锚定回答，避免空谈“加锁” |
| “报表数据不准怎么办？” | “所有报表数据源只来自revenue_record单表，且每日凌晨用存储过程原子生成日报。若不准，只需查该表trade_no是否与微信后台一致——这是可验证的。” | 把模糊问题转化为可操作的验证步骤 |
| “系统安全性怎么考虑？” | “密码用BCrypt加密存储；所有用户输入经PreparedStatement防注入；管理员后台需二次短信验证；敏感操作（如删除）全部留审计日志。” | 用分层防御思路，覆盖存储、传输、操作三环节 |
| “如果我要加人脸识别入场，怎么改？” | “只需新增face_recognition_log表，记录识别时间、人员ID、闸机编号；在验卡流程中，增加调用人脸API的Service方法，成功则继续扣次，失败则拦截。所有改动集中在CheckInService一个类。” | 展示架构的可扩展性，且定位到具体类名，显得真实 |
6.3 验收清单：交作业前，强制走一遍这10项检查
别信“我测试过了”。用这张表逐项打钩，少一项，答辩时可能被当场卡住：
| 序号 | 检查项 | 检查方法 | 不通过后果 |
|---|---|---|---|
| 1 | 会员注册时，输入错误身份证号，系统是否提示“身份证校验失败” | 手动输110101199003072311（末位错） | 老师质疑基础功能不完整 |
| 2 | 两张卡同时刷同一闸机，是否只扣一次 | 开两个浏览器，用同一张卡连续点“验卡”按钮 | 并发问题直接判逻辑缺陷 |
| 3 | 泳道预订后，数据库lane_schedule对应记录status是否为BOOKED | SELECT * FROM lane_schedule WHERE lane_id=1 AND time_slot='19:00' | 证明你真懂数据落地，不是假大空 |
| 4 | 删除会员，其名下所有卡是否自动失效（status=CANCELLED） | 查card表，member_id对应记录status | 关系完整性是数据库设计基本功 |
| 5 | 修改教练排班，其名下学员课程表是否实时更新 | 查appointment表，coach_id变更后，status是否仍为CONFIRMED | 验证你理解“预约单”是唯一事实源 |
| 6 | 导出Excel，打开后中文是否正常显示 | 用WPS/Excel双端打开 | 看似小事，但乱码是硬伤 |
| 7 | 断网状态下，前台能否继续验卡（离线模式） | 拔网线，尝试刷一张已下载到本地的卡 | 体现你考虑了真实运营环境 |
| 8 | 营收日报生成后，daily_revenue_report表是否有数据 | SELECT COUNT(*) FROM daily_revenue_report WHERE report_date = CURDATE() | 证明定时任务真实有效 |
| 9 | 管理员修改价格，历史订单价格是否保持不变 | 查一笔昨天的revenue_record，对比amount与当前价目表 | 价格变更的幂等性是财务底线 |
| 10 | 所有SQL是否都用PreparedStatement | grep -r "Statement.*execute" src/ | grep -v "PreparedStatement" | 防SQL注入是安全红线 |
从那以后我每次带学生做项目，都强制他们交作业前打印这张表，逐项手写“√”并签名。不是为了形式，是让每个人亲手触摸到“完成”的质感——系统不是写完就结束，是经得起这10个问题的拷问才算真正落地。希望帮到你。
本文还有配套的精品资源，点击获取
