Spring Boot游泳馆管理系统毕业设计：从选题到答辩全流程指南-平芜编程栈

最近不少准备做毕业设计的同学来问我选题的事，软件工程、计算机科学与技术专业里，基于Spring Boot的管理系统几乎是每年雷打不动的热门方向。在这么多题目里，游泳馆管理系统属于挺有代表性的一个：业务场景不复杂，但覆盖了会员管理、预约排期、计费、权限设计这些管理系统通用的核心模型，做完之后不只是应付答辩，还能把Spring Boot的整套开发套路彻底捋顺。而且这类项目在网上能搜到一堆“源码+文档+远程调试”的打包方案，但说实话，很多同学拿到的源码质量参差不齐，文档跟代码对不上、数据库脚本缺失、跑起来一堆报错，反而更让人头大。

这篇文章我就以游泳馆管理系统为例，把从选题拆解、功能设计、数据库建模、核心接口实现，到远程调试和答辩准备的完整链路讲清楚。不管你是自己从零写，还是手头已有源码需要修正、增强，都能照着这份思路落地。我尽量把每一步“为什么这么做”也讲明白，不是光给代码，而是让你真正能讲得清楚、改得动、答得上。

1. 项目选题与整体设计思路拆解

1.1 游泳馆管理系统到底要解决什么问题

先想清楚一个事情：管理系统这类毕业设计，本质上是“数据库增删改查+业务流程+权限控制”的组合。游泳馆这个场景，核心业务可以拆成这么几块：

会员管理：游泳馆的客户基本都是办卡会员，有次卡、月卡、年卡、私教课等不同卡种，要管注册、充值、扣次、到期提醒。
场馆与泳道预约：游泳馆需要控制同一时段在场人数，泳道也要排班，用户可以选时间段、选泳道预约，管理员可以查看预约情况、做核销。
票务与计费：散客临时入场怎么计费，会员预约后未到场的扣费规则，储物柜租赁费用等。
运营管理：员工排班、教练课程安排、设备报修记录、营业数据统计。
系统管理：管理员、员工、会员不同角色的登录与权限，基础数据的配置。

这些需求合起来，就是一个标准的信息管理系统。把它拆细之后你会发现，它和图书管理系统、健身房管理系统、体育馆预约系统的本质是相通的。所以做完这个项目，之后面试时聊到“你做过什么项目”，你完全可以说自己掌握了一套完整的企业级管理系统开发方法，而不是只说“我写过一个游泳馆”。

1.2 技术选型：为什么是Spring Boot + MySQL + Vue

市面上的毕业设计题目大都限定Spring Boot，原因不只是教学大纲的安排，更因为这个技术栈在真实企业里也是绝对主流。我按分层把技术选型罗列一下，并说说每一步的理由。

后端：Spring Boot 2.x / 3.x

Spring Boot的核心价值是“约定优于配置”。它内置了Tomcat，只需要一个带main方法的入口类就能启动Web服务，省去了传统SSM项目里那些繁琐的XML配置。用2.7.x版本做毕业设计是比较稳的选择，网上资料最多、兼容性最好；如果选3.x，要注意JDK必须用17以上，且部分配置写法变了。

持久层：Spring Data JPA 或 MyBatis Plus

这两个选一个就行。我的建议是：如果你对SQL更熟，用MyBatis Plus，代码生成器可以一键生成单表的CRUD，开发效率极高，对毕设来说非常友好；如果你希望实体关系映射更自动，选Spring Data JPA，它能把外键关系、级联操作配置得明明白白。

数据库：MySQL 5.7 / 8.0

MySQL不用多说，免费、普及率最高，云服务器部署也方便。8.0以上在时间精度、JSON支持方面更强，但5.7也够用。

前端：Vue 2 / Vue 3 + Element UI / Element Plus

如果要求前后端分离，就用这个组合，接口走JSON。如果不想做前后端分离，直接用Thymeleaf模板引擎渲染页面，一个Spring Boot工程搞定，开发和部署都更简单。很多同学的毕设文档写的是“前后端分离”，但代码里却用Thymeleaf，这个自己心里要有数，答辩时被追问很容易露馅。

权限认证：Spring Security 或 Sa-Token 或 JWT + 拦截器

完整度高的方案是Spring Security整合JWT，但Spring Security的门槛偏高，很多同学配一遍就崩。我更推荐Sa-Token或自研JWT拦截器，代码量小、逻辑直观，答辩时也容易讲清楚。

1.3 数据库表设计与核心关系

数据库设计是答辩的高频考点，也是后期改需求时最容易踩坑的地方。我直接给出一套完整的表结构设计，照着建表就能跑通核心业务。

核心表清单

表名	用途	关键字段
`member`	会员信息	id、name、phone、id_card、member_type_id、balance、points、status、create_time
`member_card_type`	卡种定义	id、card_name、duration_days、total_count、price、description
`member_card`	会员办卡记录	id、member_id、card_type_id、start_date、end_date、remain_count、status
`venue`	场馆/泳池	id、venue_name、address、total_lanes、capacity、open_time、close_time、status
`lane`	泳道	id、venue_id、lane_no、status
`appointment`	预约记录	id、member_id、venue_id、lane_id、appointment_date、start_time、end_time、status、amount、create_time
`course`	课程/私教课	id、course_name、coach_id、venue_id、price、start_date、end_date
`course_order`	课程报名记录	id、course_id、member_id、order_time、amount、status
`employee`	员工	id、name、phone、position、salary、status、create_time
`equipment_repair`	设备报修	id、equipment_name、venue_id、report_time、repair_status、repair_desc
`system_user`	系统用户(登录)	id、username、password、role、status、last_login_time
`operation_log`	操作日志	id、user_id、operation、method、params、ip、time

这些表的关系也比较清晰：

member_card多对一关联member和member_card_type，一张会员卡只属于一个会员，一个卡种可以被多张卡使用。
appointment关联member、venue、lane，每次预约至少要明确“谁在哪个泳池的哪条泳道什么时间游”，这是预约冲突检测的核心依据。
course_order关联course和member，一张订单只能对一门课程。

建表的时候要注意两个地方：一是时间字段类型统一，建议直接用datetime，避免timestamp在2038年出问题；二是金额字段用decimal(10,2)，不要用float/double，否则浮点运算会出现 0.1+0.2=0.30000000000000004 这种尴尬精度问题。

2. 核心功能模块与业务逻辑详解

2.1 会员管理模块：从办卡到扣费的完整链路

会员管理是游泳馆系统里最基础的闭环。我以“会员线下办卡-绑定卡种-到场扣次/扣费-到期提醒”这个完整链路来拆解设计逻辑。

办卡流程

会员第一次到店时，前台操作员录入会员基础信息，选择卡种生成会员卡。这里要处理一个关键点：卡种的计费模式。常见的是三种：

次卡：办卡后获得若干次入场次数，每次入场扣减一次，不限具体日期。
期限卡（月卡/季卡/年卡）：办卡后在有效期内不限次数入场。
储值卡：预存金额，每次入场按散客价扣费。

对应的表结构就是member_card_type中设计了total_count和duration_days两个字段，用“次数+天数”的组合来覆盖这三种模式。次卡duration_days=0、total_count=n；期限卡duration_days=n、total_count=0；混合卡两者都有。

入场扣费的Service代码

我这里写一段入场签到并自动扣次/扣费的Service代码，这是整个项目里业务逻辑最集中的地方之一。

@Service public class MemberCheckinService { @Autowired private MemberCardMapper memberCardMapper; @Autowired private MemberConsumeLogMapper consumeLogMapper; @Transactional(rollbackFor = Exception.class) public Result checkin(Long memberId, Long venueId) { // 1. 查询会员当前有效的卡片 MemberCard card = memberCardMapper.findValidCardByMemberId(memberId); // 2. 没有有效卡，按散客处理，提示先购票 if (card == null) { return Result.error("会员卡不存在或已过期，请先购票"); } // 3. 判断卡型：次卡优先减次数，期限卡检查有效期，储值卡检查金额 if (card.getRemainCount() != null && card.getRemainCount() > 0) { card.setRemainCount(card.getRemainCount() - 1); memberCardMapper.updateById(card); } else if (card.getEndDate() != null && card.getEndDate().isAfter(LocalDate.now())) { // 期限内，免费入场 } else if (card.getBalance() != null && card.getBalance().compareTo(BigDecimal.ZERO) > 0) { // 储值卡扣费逻辑，按次扣除 } else { return Result.error("卡片余额不足，请充值"); } // 4. 记录消费日志 MemberConsumeLog log = new MemberConsumeLog(); log.setMemberId(memberId); log.setVenueId(venueId); log.setConsumeType("入场签到"); log.setConsumeTime(LocalDateTime.now()); consumeLogMapper.insert(log); return Result.success("签到成功"); } }

这段逻辑的要点在于：

@Transactional保证扣费操作和消费日志要么都成功，要么都失败，不会出现“次数扣了但日志没记”的数据不一致情况。
次卡、期限卡、储值卡的判断顺序很重要，实际业务中“卡种优先级”是有讲究的，一般是先判断过期，再判断次数/余额。
代码里用BigDecimal比较余额，而不是double。

到期提醒

不要写到代码里天天查表，用Spring Boot的@Scheduled注解就能做定时任务。每天凌晨扫描一次member_card表，把未来7天内到期的会员找出来，生成短信/站内通知记录。

@Component public class CardExpireTask { @Scheduled(cron = "0 0 2 * * ?") public void expireRemind() { // 查询7天内到期且未发送过提醒的卡片 // 生成提醒记录 } }

这虽然是个小功能，但在答辩时属于亮点。你可以主动讲“项目接入了定时任务模块，实现了会员到期自动提醒”，面试官或答辩老师的印象分会明显高一些。

2.2 场馆与泳道预约：冲突检测与计费规则

预约是游泳馆系统里技术上最有价值的一个模块，因为它涉及并发场景下的数据一致性和冲突检测。如果只是简单地insert一条预约记录，那么两个会员同时预约同一条泳道时会互相覆盖，这在实际场景中是绝对不允许的。

预约的业务约束

一个会员同一时间段只能有一个有效预约。
一个泳道同一时间段只能被一个会员预约。
场馆有开放时间限制，例如 9:00-22:00。
预约可以设定提前24小时取消，取消后释放泳道。

冲突检测的两种实现方式

方式一：应用层校验（查询-判断-插入）

public synchronized Result createAppointment(Appointment appointment) { // 1. 校验会员是否已有同日同时段的预约 Integer count = appointmentMapper .selectCountByMemberAndTime(appointment.getMemberId(), appointment.getAppointmentDate(), appointment.getStartTime(), appointment.getEndTime()); if (count > 0) { return Result.error("您在该时间段已有预约"); } // 2. 校验泳道是否已被占用 Integer laneCount = appointmentMapper .selectCountByLaneAndTime(appointment.getLaneId(), appointment.getAppointmentDate(), appointment.getStartTime(), appointment.getEndTime()); if (laneCount > 0) { return Result.error("该泳道已被预约"); } // 3. 插入预约 appointmentMapper.insert(appointment); return Result.success(); }

这种方式简单直观，但要注意：synchronized在单机多线程下能保证同一JVM内有序，如果是多实例部署，它无能为力。毕业设计不至于做分布式，所以够用了，但你在答辩时如果能主动说出“这个方案在单机环境下没问题，若要真正应对高并发需要引入数据库锁或Redis分布式锁”，会体现出你有深度。

方式二：数据库唯一索引防重

这是更推荐的做法。在appointment表上建立联合唯一索引，从数据库层面直接拦住冲突：

ALTER TABLE appointment ADD UNIQUE KEY uk_lane_time (lane_id, appointment_date, start_time, end_time);

这样即使代码里有并发问题，数据库也能兜底，第二条重复插入会直接抛DuplicateKeyException，代码里捕获后转成友好的错误提示即可。

计费规则

预约行为的计费有两种常见设计：

预约时锁定价格，到场核销时扣费，适用于散客、临时预约。
预约时不收费，但设置“爽约金”，未到场且未取消则扣对应费用，适用于对会员的规范管理。

在appointment表里设计amount字段，预约时计算预扣金额，核销时确认实际消费。取消预约时，按规则决定是否退还金额。

核销操作

用户到场后，前台根据预约码/会员手机号进行核销，核销时将预约状态从待入场改为已完成，并触发会员卡扣次。核销接口要确保预约不能被重复核销。

2.3 权限控制与安全设计

管理系统必须有权限区分，这是所有毕设答辩几乎必问的问题。游泳馆系统的角色可以分三类：

管理员：全局管理，能看所有功能，能配置系统参数。
员工（前台/教练）：能办卡、预约、核销、查看统计，但不能修改系统配置、不能删除会员。
会员：小程序/网页端自助预约、查看自己的卡包和消费记录。

实现方案：JWT + 拦截器

我推荐在Spring Boot里用自研JWT+拦截器的方式做权限控制，代码量不大但逻辑清晰。核心思路：

登录成功后，后端签发一个包含用户id、角色、过期时间的JWT token。
前端将token放在请求头的Authorization字段。
后端写一个拦截器，在进入Controller之前解析token，校验签名和过期时间。
校验通过后，将用户信息放入ThreadLocal或RequestContext，后续代码直接取当前用户。
对需要特定角色的接口，再通过注解或拦截器做二级校验。

JWT生成与校验工具类大致长这样：

public class JwtUtils { private static final String SECRET = "your-secret-key"; public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 12 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

有一个坑要提醒：JWT的密钥不要写死在代码里，毕业设计可以简化，但我建议至少放在application.yml配置里，通过@Value注入。这不仅更规范，也方便在不同环境切换。

3. 实操过程：从环境搭建到运行调试

3.1 开发环境准备与项目初始化

开始写代码之前，先把环境统一了，避免后面出现“我本地能跑你本地跑不了”的尴尬。

推荐环境组合

工具	版本建议	说明
JDK	1.8（Spring Boot 2.x）	如果用JDK17，就配Spring Boot 3.x
Maven	3.8.x	不要用太老的3.2版本，拉依赖容易出问题
MySQL	5.7 或 8.0	8.0需要把驱动设置为`com.mysql.cj.jdbc.Driver`
IDEA	2022+	社区版也够用，Ultimate对Spring Boot支持更完整
Navicat / DBeaver	任一	建议用DBeaver，免费且跨平台

创建Spring Boot工程的两种方式

方式一（最简单）：在IDEA里New Project -> Spring Initializr，选择Java版本、Spring Boot版本，勾选 Web、MySQL Driver、MyBatis Plus（在依赖搜索框输入“mybatis-plus”）、Lombok。

方式二：去 start.spring.io 网页生成后，IDEA打开。

注意：国内网络环境下从Maven中央仓库拉取依赖可能很慢，可以在settings.xml里配置阿里云镜像。

application.yml 核心配置

server: port: 8080 servlet: context-path: /api spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/swim?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里有个非常关键但又容易忽略的小点：url里一定要加serverTimezone=Asia/Shanghai和characterEncoding=utf8。不加时区的话，MySQL 8.0经常报The server time zone value 'ÖÐ¹ú±ê×¼Ê±¼ä' is unrecognized的错；不加字符集的话，数据库中中文大概率变乱码。

3.2 核心接口实现要点

以预约模块为例，一个完整的接口要包含Controller、Service、Mapper三层。这里把Controller和Service的关键代码写出来。

Controller层

@RestController @RequestMapping("/appointment") public class AppointmentController { @Autowired private AppointmentService appointmentService; @PostMapping("/create") public Result create(@RequestBody AppointmentCreateDTO dto) { // 从当前登录上下文获取会员id Long memberId = UserContext.getUserId(); return appointmentService.createAppointment(dto, memberId); } @GetMapping("/my") public Result myAppointments(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size) { Long memberId = UserContext.getUserId(); return appointmentService.pageMyAppointments(memberId, page, size); } }

这里我特别提到UserContext.getUserId()，意思是用拦截器解析token后，把用户信息存到当前请求上下文中。这样Controller不用每次都从token里解析用户，代码干净很多。

Service层的核心代码

@Service public class AppointmentService { @Transactional(rollbackFor = Exception.class) public Result createAppointment(AppointmentCreateDTO dto, Long memberId) { // 1. 校验时间范围是否在场馆营业时间内 if (dto.getStartTime().isBefore(dto.getEndTime()) == false) { return Result.error("结束时间必须晚于开始时间"); } // 2. 校验场馆开放时间（这里简化，营业时间从venue表读取） LocalTime openTime = venueMapper.selectOpenTime(dto.getVenueId()); LocalTime closeTime = venueMapper.selectCloseTime(dto.getVenueId()); if (dto.getStartTime().isBefore(openTime) || dto.getEndTime().isAfter(closeTime)) { return Result.error("预约时间不在场馆开放时间内"); } // 3. 查询会员当前持有的有效卡种 MemberCard card = memberCardMapper.findValidCardByMemberId(memberId); if (card == null) { return Result.error("无有效会员卡，请先办卡"); } // 4. 计算需要锁定多少金额（某些场景预收保证金） BigDecimal appointmentAmount = calcAppointmentAmount(card, dto); // 5. 做冲突检测（数据库唯一索引兜底 + 应用层友好提示） try { Appointment appointment = new Appointment(); appointment.setMemberId(memberId); appointment.setVenueId(dto.getVenueId()); appointment.setLaneId(dto.getLaneId()); appointment.setAppointmentDate(dto.getAppointmentDate()); appointment.setStartTime(dto.getStartTime()); appointment.setEndTime(dto.getEndTime()); appointment.setAmount(appointmentAmount); appointment.setStatus("待入场"); appointment.setCreateTime(LocalDateTime.now()); appointmentMapper.insert(appointment); } catch (DuplicateKeyException e) { return Result.error("该泳道在该时间段已被预约，请更换时间"); } return Result.success("预约成功"); } }

核销接口注意幂等

核销要保证同一个预约只能被核销一次。一种做法是在核销SQL里带条件更新：

int updated = appointmentMapper.updateStatusByIdAndOldStatus(appointmentId, "待入场", "已完成"); if (updated == 0) { return Result.error("预约状态已变更，请勿重复核销"); }

通过SQL的条件更新，而不是先查后改，能够在并发情况下也能兜住。

3.3 代码生成器的使用

我强烈建议项目里集成MyBatis Plus的代码生成器，尤其是时间紧张的时候。代码生成器可以根据数据库表自动生成entity、mapper、service、controller四层代码，单表CRUD几乎零手写。

一个极简的生成器配置大致如下：

public class CodeGenerator { public static void main(String[] args) { FastAutoGenerator.create("jdbc:mysql://localhost:3306/swim?useSSL=false", "root", "123456") .globalConfig(builder -> builder.author("your-name") .outputDir("D:/project/swim/src/main/java")) .packageConfig(builder -> builder.parent("com.example.swim") .entity("entity").mapper("mapper") .service("service").serviceImpl("service.impl") .controller("controller")) .strategyConfig(builder -> builder.addInclude("appointment") .addTablePrefix("")) .execute(); } }

生成完后，你只需要在Service里补充业务逻辑，不用再手写Mapper XML里的基础增删改查。注意：代码生成器生成的Controller是空的{}，你需要自己补业务接口，不要直接把生成的代码原封不动交上去。

3.4 远程调试：确保在别人的电脑上能跑起来

很多同学的毕设源码找别人要过来之后，最大的问题不是看不懂逻辑，而是根本跑不起来。远程调试这个词在毕设服务里特别常见，但本质上就是要确保项目换一台机器、换一套数据库之后还能正常运行。我总结三类最常见的调试问题。

第一类：数据库配置不对

拿到源码后，先看application.yml里的数据库名、用户名、密码。很多源码自带的建表脚本是swim.sql，你要先手动在MySQL里创建一个同名数据库，再导入SQL：

mysql -u root -p create database swim default character set utf8mb4; exit; mysql -u root -p swim < swim.sql

导入成功后，用查询语句验证一下表是否存在：show tables;。

第二类：Maven依赖无法下载

pom.xml里如果引入了私服依赖或版本冲突，很容易在install阶段报红。最常见的处理方式是：

检查Maven的settings.xml有没有配置阿里云镜像；
在IDEA右侧Maven面板执行clean -> compile，看具体报错；
如果依赖下载不完整，删除本地仓库对应文件夹重新拉取。

第三类：端口被占用或前端跨域

启动时如果报Port 8080 is already in use，要么改server.port，要么关掉占用进程。前后端分离项目最常见的是跨域报错，后端写一个CorsConfig即可：

@Bean注册CorsFilter，允许所有来源跨域。

远程调试这个“服务”的本质，其实就是帮对方把项目调通到“双击启动就能看效果”的状态。我上面这三类问题，覆盖了80%以上跑不起来的原因，你按顺序排查基本都能解决。

4. 常见问题与排查技巧实录

4.1 数据库中文乱码与时间问题

乱码是毕设里最经典的问题。如果数据库中表和数据都是utf8mb4，连接URL也带了characterEncoding=utf8mb4，但页面还是乱码，大概率是以下两种原因：

MySQL 服务器端默认字符集不是 utf8mb4，需要在my.cnf里设置character-set-server=utf8mb4。
前端页面没有声明编码，HTML/JS的<head>中缺少<meta charset="utf-8">。

时间问题也很常见。前端传进来的"2024-06-15 09:00:00"在后端被反序列化时提示格式不对，这时可以在DTO字段上单独加格式注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime startTime;

还有一类很隐蔽的问题：JavaLocalDateTime与 MySQL 的datetime类型转换时，如果实体字段类型写成了Date而数据库是datetime，有时会出现日期正常但时分秒为 00:00:00 的情况，建议统一使用LocalDateTime。

4.2 预约冲突检测失效

如果数据库唯一索引建好了，但两端同时请求还能插入重复预约，先检查索引是不是没生效。用show index from appointment;查看。还有一个容易被忽视的点：唯一索引的NULL值。如果lane_id在部分旧数据里是NULL，MySQL会认为NULL != NULL，多个同一个泳道的NULL记录不会触发唯一冲突。解决办法是把能加NOT NULL的字段都加上默认值。

应用层冲突检测也有一个常见的逻辑bug：很多同学判断时间段冲突时只做了startTime相等校验，其实真正的冲突是交叉重叠。两个预约只要满足newStart < oldEnd && newEnd > oldStart就算是冲突了，这个边界条件一定要写对。

4.3 前端联调跨域与token丢失

前后端分离联调时，跨域是绕不开的。如果后端是8080，前端是5173（Vite默认端口），前端请求后端就直接跨域了。除了后端配置CORS，还可以用Vite代理来解决：

// vite.config.js server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/login，会被代理转发到后端的http://localhost:8080/api/login，浏览器感觉不出来跨域，效果很好。

token丢失的问题也经常被问到。前端把token存到localStorage后，刷新页面要保持登录状态，需要在路由守卫里读取token并放到请求拦截器的header中。很多同学只做了“发请求时带token”，刷新时没有恢复，导致刷新瞬间报401。

4.4 答辩时最容易被问的5个问题

毕业设计做到最后，代码能不能跑反而是其次，答辩时你要能讲清楚设计。根据我这几年看学生答辩的经验，下面5个问题出现频率最高，提前准备好回答思路：

为什么选择Spring Boot而不选SSH/SSM？重点答：简化配置、内置服务器、自动装配、生态完整、便于部署。
数据库表之间关系如何设计？把上面表结构的关系讲清楚，能现场画出ER图更好。
如何防止预约冲突？答数据库唯一索引+应用层校验双保险，能讲清楚条件更新幂等更佳。
权限控制怎么实现的？答JWT+拦截器，登录发token、请求带token、拦截器校验角色。
项目有哪些难点？是怎么解决的？主动说预约冲突、金额精度、定时任务这三个点，这属于加分项。

答辩时间通常5-10分钟，一定要控制住节奏。不要照着PPT念，要像讲故事一样把“我做了什么、为什么这样做、遇到什么问题、怎么解决”串起来。

5. 个人经验总结与后续扩展建议

做了这么多管理系统相关的毕设辅导和代码debug，我想说一个很实际的心得：毕业设计不是写完代码就结束了，真正拉开差距的是你对系统的理解深度和表达清晰度。

如果把“基于Spring Boot的游泳馆管理系统”这个项目做好，你拿到的不只是一份能答辩通过的作品，而是一整套可以复用的能力。系统里会员管理、预约、计费、权限、定时任务、日志处理这些模块，换一个业务场景就能变成健身房系统、图书馆座位预约系统、实验室设备管理系统，内核都是通的。

最后给你一个实操层面的建议：不要过度依赖外卖版的源码和文档。你可以把别人给的代码当作参考和基础，但一定要自己完整地改一遍，至少自己动手加一个功能、改一个接口、补充一个表。因为答辩时老师问的每一个细节，只有你自己写过才能在几秒内组织出清楚的答案。代码可以调试，但能力不能调试，它只能靠你亲手一行行敲出来。