简介一份基于Java的游泳馆管理系统课程设计项目主要面向数据库原理与Java编程初学者以及需要完成课程设计的在校生。系统围绕游泳馆日常运营场景实现了会员信息管理、在线预约、场地调度和收费记账等核心模块可帮助理解从需求分析到数据库建模再到界面开发的完整流程。rar压缩包共1286个文件约3.81MB以htm网页、java源码及class字节码为主同时包含SQL数据库脚本、JS交互逻辑、配置文件与项目工程文件目录结构较完整便于直接导入开发环境查看运行效果。资源覆盖会员消费记录跟踪、预约冲突处理、场地状态维护、多支付方式计费等典型业务既适合用于毕业设计或课程设计参考也适合自学数据库设计与Java桌面应用开发目前已有1535人学习说明该资源在同类课程设计资料中具备一定参考价值。1. 游泳馆管理系统从 Excel 台账到会员、场次、营收一套逻辑某游泳馆的店长每天最头疼的事不是水质是账。办卡、续卡、团课预约、私教扣次、更衣柜押金、日场夜场人次全靠前台拿 Excel 记。月底对账对出好几处差额少一次扣次、多一节课、漏一个押金谁也说不清。这套游泳馆管理系统就是用 Java 把这些零散动作收拢成一套可追溯的流程会员从办卡到入场、从预约到扣次、从收银到报表都在一个工程里闭环。对于刚入行的开发者来说它是一个非常标准的 Spring Boot MyBatis 单体项目能直接对照着学事务、权限、报表导出对于小场馆它又能替代 Excel 台账把「谁游了、游了几次、花了多少钱」变成按时间可查的记录。如果你是接手这类管理系统的人先别急着加功能把会员卡、场次、预约这三张表之间的关系吃透整个项目就已经跑通了一半。2. 架构与数据设计Spring Boot MyBatis 的单体工程骨架这类场馆管理系统的业务量不大并发峰值可能就集中在晚场时段。选型我没上微服务而是老老实实用一个 Spring Boot 单体工程MySQL 做持久化MyBatis 管理 SQLRedis 只用来放登录 token 和部分热点缓存。这样的好处是事务边界清楚一次扣次、一次预约就是本地事务不需要分布式协调出问题也好排查。下面先把功能模块和数据模型铺开看清楚这个系统到底在管什么。2.1 功能模块梳理从会员办卡到场地排期的业务闭环这个系统常见的功能可以拆成八个模块它们不是孤立页面而是围绕「一张会员卡怎么从售卖到消耗」形成闭环。模块核心职责关键数据会员管理办卡、资料维护、挂失、到期提醒member会员卡管理次卡/月卡/年卡、充次、扣次、过期member_card场次管理早场/日场/晚场、容量、价格venue_session预约管理线上/前台预约、取消、核销appointment课程管理团课/私教排课、教练绑定、扣次course、course_order收银管理办卡收款、续费、退费、流水payment报表中心人次、营收、课程出勤、卡余量聚合查询系统管理用户、角色、登录日志sys_user、sys_role站在二次开发的角度会员卡是主数据场次和预约是业务入口支付流水是最终结果。如果只做简单开放把这三块跑通再补报表就够了。2.2 技术栈与工程分层为什么用单体而不是微服务项目里我用的是 Java 8 配合 Spring Boot 2.7MyBatis 写 XML SQLMySQL 5.7/8.0 都兼容Redis 保存会话前端是 Vue 3 Element Plus报表导出用 EasyExcel。没有引入 Spring Cloud也没有拆服务原因很现实场馆收银、预约、会员卡这些功能之间强依赖同一个会员卡状态拆开反而要处理分布式事务工程复杂度远大于收益。工程目录我习惯按 controller、service、mapper、entity、dto、interceptor、config 分层每个包只干一件事。swimming-pool/ ├── pom.xml └── src/main/ ├── java/com/pool/ │ ├── controller/ # REST接口层只做参数接收和响应 │ ├── service/ # 业务事务层扣次、预约的核心逻辑 │ ├── mapper/ # MyBatis接口对应XML里的SQL │ ├── entity/ # 数据库表实体字段和列一一对应 │ ├── dto/ # 出入参对象避免把Entity暴露给前端 │ ├── interceptor/ # 登录拦截、权限校验 │ ├── config/ # WebMvc、跨域、Redis等配置 │ └── common/ # 统一返回体、业务异常、工具类 └── resources/ ├── mapper/ # SQL XML复杂查询都放这里 ├── templates/ # Excel导出模板 └── application.ymlservice 层是核心所有扣次、预约、退款逻辑都要有 Transactionalmapper 层只做数据的读写不在接口里写业务判断controller 层只处理 HTTP 请求和参数校验。这样改一个页面流程时不用追着 SQL 到处跑。2.3 数据库设计核心表结构与关系数据库里最重要的四张表是 member、member_card、venue_session、appointment。member 和 member_card 是一对多一张会员卡属于一个会员member_card 和 appointment 也是一对多一次预约消耗一张卡的时间和次数venue_session 是场馆的固定场次定义比如 08:00-10:00 早场。CREATE TABLE member ( id BIGINT PRIMARY KEY AUTO_INCREMENT, real_name VARCHAR(50) NOT NULL, phone VARCHAR(20) NOT NULL UNIQUE, gender TINYINT DEFAULT 0, photo_url VARCHAR(200), status TINYINT DEFAULT 1, remark VARCHAR(255), created_at DATETIME, updated_at DATETIME ); CREATE TABLE member_card ( id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, card_no VARCHAR(32) NOT NULL UNIQUE, card_type TINYINT NOT NULL, total_times INT DEFAULT 0, remain_times INT DEFAULT 0, start_date DATE, end_date DATE, status TINYINT DEFAULT 1, KEY idx_member (member_id) ); CREATE TABLE venue_session ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_name VARCHAR(20) NOT NULL, start_time TIME NOT NULL, end_time TIME NOT NULL, capacity INT DEFAULT 0, price DECIMAL(10,2) DEFAULT 0 ); CREATE TABLE appointment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, appoint_no VARCHAR(32) NOT NULL, member_id BIGINT NOT NULL, card_id BIGINT NOT NULL, session_id BIGINT NOT NULL, appoint_date DATE NOT NULL, status TINYINT DEFAULT 0, source TINYINT DEFAULT 1, created_at DATETIME, UNIQUE KEY uk_appoint (appoint_date, session_id, member_id) );appointment 表上的唯一索引很关键。很多项目一开始没加这个索引结果同一个会员同一天同场次预约了两条数据后面的报表和扣次全乱了。到二次开发阶段凡是业务上要求「同一个约束」的关系都要先在建表时用唯一索引兜底。3. 核心模块拆解会员卡扣次与场馆预约的完整链路这段是整个系统最值得看的实现。我把「登录拿身份 → 预约场次 → 扣会员卡次数」串成一条链路每一步都明确事务边界和并发处理方式。3.1 登录鉴权与权限控制拦截器加 token 的最小实现这个系统没有做复杂的 OAuth而是用 token 方案登录成功后在 Redis 里生成一个 token存 userId 和过期时间后续请求通过拦截器校验。Redis 用不上也没关系把 token 存数据库也一样只是每次请求多一次查询。核心拦截器代码不复杂但要注意 token 为空、token 失效、用户被禁用三种情况都要分别返回 401 还是 403否则前端很难定位。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(token); if (StringUtils.isBlank(token)) { response.setStatus(401); return false; } UserInfo user userService.getByToken(token); if (user null) { response.setStatus(401); return false; } if (user.getStatus() ! 1) { response.setStatus(403); return false; } UserContext.set(user); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }代码逻辑很简单从 header 拿 token查用户权限通过后放到 ThreadLocal 类型的 UserContext 里请求结束清理。这里要重点记得 afterCompletion 里必须 clear否则 Tomcat 线程池复用时会串用户身份。拦截器注册时通常放行登录接口和验证码接口把所有 /api/** 拦起来。Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/login, /api/auth/captcha); } }Controller 里用 UserContext.get() 拿到当前用户避免每个接口都传 userId。这样改起来也方便以后要加角色权限在拦截器里多判断一个角色 key 就行。3.2 会员卡扣次事务边界和并发控制扣次的难点不是 SQL而是并发。如果用户快速点击两次预约两个请求同时读到剩余次数为 2两个都判断成功最后只扣一次库存就错了。我这里的做法是扣次前先对会员卡行加行级锁再检查剩余次数。Transactional(rollbackFor Exception.class) public UseResult deductTimes(DeductRequest request) { MemberCard card cardMapper.selectByIdForUpdate(request.getCardId()); if (card null) { throw new BizException(会员卡不存在); } if (card.getStatus() ! 1) { throw new BizException(会员卡已停用); } if (card.getRemainTimes() request.getUseTimes()) { throw new BizException(剩余次数不足); } int updated cardMapper.reduceTimes( request.getCardId(), request.getUseTimes()); if (updated ! 1) { throw new BizException(扣次失败请重试); } appointmentMapper.insertAppointment(request); return UseResult.ok(card); }selectByIdForUpdate 对应 SQL 里的SELECT ... FOR UPDATE在事务提交前其他事务对这个会员卡行只能等待。reduceTimes 是带余额条件的更新UPDATE member_card SET remain_times remain_times - #{times} WHERE id#{id} AND remain_times #{times}更新行数不等于 1 就说明并发冲突或余额不足。这个方案能解决大部分场景但注意不能锁范围太大。如果直接把整张表锁住晚场高峰期所有预约排队体验会很差。所以只锁会员卡行预约记录本身靠唯一索引兜底整体性能是够的。3.3 场次预约与冲突检测预约逻辑要同时检查两个东西场次是否还在有效时间窗口内、当前预约人数是否达到 capacity。这里最容易踩的坑是「先查 count 再 insert」两个请求同时查出 count 20capacity 2021 个都进来了。我的做法是拿场次行锁把 count 查询放在锁内。Transactional(rollbackFor Exception.class) public boolean bookSession(BookingReq req) { VenueSession session sessionMapper.selectByIdForUpdate(req.getSessionId()); if (session null) { throw new BizException(场次不存在); } int current appointmentMapper.countByDateAndSession( req.getAppointDate(), req.getSessionId()); if (current session.getCapacity()) { throw new BizException(该场次已约满); } int inserted appointmentMapper.insertAppointment(req); if (inserted 0) { throw new BizException(请勿重复预约); } return true; }对应的 SQL 查询用了一个简单的 countselect idcountByDateAndSession resultTypeint SELECT COUNT(*) FROM appointment WHERE appoint_date #{appointDate} AND session_id #{sessionId} AND status 1 /select参数说明appointDate 是预约日期sessionId 是场次 IDstatus 1 表示有效预约。如果这里不加 status 条件已取消的预约也会占名额用户取消后场次仍然「约满」。插入时靠uk_appoint(appoint_date, session_id, member_id)唯一索引拦截重复预约insert 返回 0 就抛业务异常。整套逻辑下来预约页面的秒开体验不会有问题真正的高峰期也只是少数请求短暂锁等。4. 看板统计与报表导出把散落的运营数据拼成一张表场馆老板要的不是接口调通而是「今天卖了多少、来了多少人、哪个时段最闲」。这部分我做成看板接口和 Excel 导出两个能力。4.1 看板接口按天和按月聚合的思路看板数据不需要实时到秒按天聚合就能满足日常决策。数据库层面用 GROUP BY 按日期分组服务端再套一层缓存避免前端每刷新一次就重查全表。select iddailyRevenue resultTypemap SELECT DATE_FORMAT(created_at, %Y-%m-%d) AS day, COUNT(*) AS order_count, IFNULL(SUM(amount), 0) AS amount FROM payment WHERE created_at gt; #{begin} AND created_at lt; #{end} GROUP BY DATE_FORMAT(created_at, %Y-%m-%d) ORDER BY day /select这里要特别注意created_at #{end}用的是开区间。如果把 end 传成 2025-01-31MySQL 会当作 2025-01-31 00:00:00当天下午的记录就全部漏掉。所以传参时在 service 层把 end 加一天或者直接传2025-02-01。这个细节后面章节还会提到。看板接口返回的数据结构我习惯统一成ListMapString, Object前端拿 key 直接渲染避免为每个图表单独建 DTO。如果字段多了再收敛成固定 VO否则前端和后端改起来都很累。4.2 报表导出用 EasyExcel 配合模板生成报表导出用 EasyExcel 比 POI 少写很多样板代码而且对内存优化更好。这里我做一个「每日营收明细」导出接口直接把聚合查询结果写进响应流。public void exportDailyRevenue(HttpServletResponse response, String begin, String end) { ListMapString, Object rows paymentMapper.dailyRevenue(begin, end); ListListString head Arrays.asList( Arrays.asList(日期), Arrays.asList(订单数), Arrays.asList(营收金额) ); response.setContentType(application/vnd.openxmlformats-officedocument.spreadsheetml.sheet); response.setCharacterEncoding(utf-8); response.setHeader(Content-Disposition, attachment;filenamedaily_revenue.xlsx); EasyExcel.write(response.getOutputStream()) .head(head) .sheet(营收日报) .doWrite(rows); }EasyExcel 写 map 数据时会按 head 里第一行数据的顺序取值。要注意的是用 List 作为表头下载的文件里没有字段映射所以 map 的 key 顺序和 head 对齐才能正确显示。更稳妥的做法是建一个 ExportDailyRevenueDTO用注解定义列名和顺序后续要加「现金」「微信」「支付宝」分渠道列也只是扩展字段的问题。5. 常见问题与避坑记录开发期间踩过的五个典型坑这套系统开发周期不长但坑一个没少踩。我把印象最深的五个写下来每条都按「现象 → 原因 → 解决」还原现场。5.1 日期区间查询总是少最后一天现象报表页面选「2024-12-01 到 2024-12-31」结果只有 12 月 1 日到 30 日的数据31 日单子永远出不来。原因前端传的 end 是日期字符串2024-12-31MyBatis 会按2024-12-31 00:00:00解析。SQL 写成created_at BETWEEN #{begin} AND #{end}就是到 31 号零点当天后面的数据全被排除。解决所有时间区间查询统一改用created_at #{begin} AND created_at #{nextDay}在 service 层用LocalDate.parse(end).plusDays(1)计算 nextDay。从那以后凡是接口文档里出现 startDate、endDate我第一反应就是确认 end 是否要加一天。5.2 事务方法在同一个类里自调用扣次异常不回滚现象service 里有个 public 方法处理预约在这个方法内部直接调用了同类里的 deductTimes()结果 deductTimes 抛异常预约数据已经插进去了扣次却没回滚。原因Spring 的 Transactional 是基于代理实现的同类内部this.deductTimes()调用不会经过代理对象事务注解自然失效。这个问题非常隐蔽不是每调用必炸只有抛异常时才会发现。解决把扣次逻辑放到另一个 service Bean 里比如cardService.deductTimes()注入进来调用或者用编程式事务 TransactionTemplate 手动 commit/rollback。我在这个项目里直接拆了一个 CardService顺手把职责也理清了。5.3 LocalDateTime 返回给前端变成了带 T 的字符串现象预约列表接口返回的 createTime 是2024-12-18T15:30:00前端直接显示在表格里很丑有些前端用new Date()解析 ISO 字符串在 Safari 下直接显示 Invalid Date。原因Jackson 默认对 Java 8 时间类型序列化时会使用 ISO-8601 格式JavaScript 对 ISO 兼容性还好但在部分移动端 WebView 里解析有问题。解决application.yml 里给全局配置一个格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8同时也要给 LocalDateTime 字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)两者配合前端拿到的就是可直接展示的格式。要是只有 Date 类型没有 LocalDateTime那 date-format 就够用但项目用了 Java 8 时间 API必须两个都配。5.4 晚场高峰期并发预约明明没约满却超售了现象压力测试里 capacity 设为 20同一个秒杀接口发 50 个并发请求最终预约成功 22 条超过容量。原因我当时先SELECT COUNT(*)判断有没有满再执行 insert。两个请求同时查到 count 19都认为还有空位于是都插入成功。这个问题等于把判断和操作分成了两个事务步骤之间没有任何锁。解决见 3.3 里的方案预约前先SELECT ... FOR UPDATE锁住 venue_session 那一行把 count 和 insert 放到同一个事务里。如果还不放心就在 appointment 表的唯一索引之外再加一个针对场次容量的计数查询配合业务异常处理。加锁会牺牲一点吞吐但预约这种场景正确性优先。5.5 MyBatis 插入后主键没回填订单号拼不完整现象insert appointment 之后需要拿自增主键拼业务单号 appoint_no结果 id 一直是 null。原因XML 里 insert 语句没有写useGeneratedKeystrue keyPropertyidMyBatis 默认不会把数据库自增主键写回实体对象。解决在 insert 标签上补上主键回填insert idinsertAppointment parameterTypecom.pool.entity.Appointment useGeneratedKeystrue keyPropertyid INSERT INTO appointment (...) VALUES (...) /insert使用 useGeneratedKeys 后插入完成就能从 appointment.getId() 拿到自增 ID。注意 keyProperty 要和实体主键字段名一致写错的话 MyBatis 不会报错但 id 依旧是 null排查起来很蛋疼。6. 二次开发指南从改字段到加一个私教课预约模块如果要在现有系统上加一个「私教课预约」功能我不会另起一张大而全的表而是照旧沿用会员卡扣次逻辑。第一步建私教课和预约两张表第二步在 CardService 下面新增一个bookPrivateLesson方法复用 deductTimes 做次数扣除第三步在 controller 里暴露预约接口最后在前端加页面和路由。最关键的是业务上复用同一张 member_card而不是新开一份私教课时长包否则报表统计时会员卡消耗会出现两种口径。Transactional(rollbackFor Exception.class) public LessonOrder bookPrivateLesson(LessonBookingReq req) { MemberCard card cardService.deductTimes( req.getMemberId(), req.getCardId(), 1); LessonOrder order new LessonOrder(); order.setMemberId(req.getMemberId()); order.setCardId(req.getCardId()); order.setCoachId(req.getCoachId()); order.setLessonTime(req.getLessonTime()); order.setStatus(LessonStatus.BOOKED.getCode()); lessonOrderMapper.insert(order); return order; }改造前我习惯先画一张「扣次 插入业务记录」的事务时序图确认两件事先扣次还是先建订单如果建单失败扣次能不能回滚。这里把 deductTimes 和 insert 放在同一个事务里就能保证要么两个都成功要么都回滚。验证方法也简单写一个单元测试分别测正常扣次、余额不足、教练时间冲突三种情况检查 appointment 和 member_card 的最终状态。从那以后我每次加新的预约类型都强制走一遍「画表 → 定接口 → 写单测 → 连前端」的顺序宁可多花半天也不让接口裸奔。希望帮到你。本文还有配套的精品资源点击获取