企业官网建设流程全解析

这个项目我太熟了，做毕设选体育馆管理系统的人这几年特别多，每年都能在答辩现场看到好几款类似的作品。但说实话，大部分都停留在"能跑"的阶段——登录注册、场地列表、提交预约，然后就没有然后了。真正能拿高分的作品，通常在业务深度和工程规范上明显高出一截。这篇就以百胜体育馆管理系统为壳，把这个项目的完整拆解思路、技术选型逻辑、核心难点实现和我在实际开发里踩过的坑一次性讲透，让你拿到的不是一份流水账代码，而是一个可以讲清楚、扛得住问、改得动功能的毕设框架。

1. 项目到底在解决什么问题

1.1 需求痛点拆解

体育馆管理系统表面上是"管理场馆信息"，但毕业设计要想做得有说服力，你得先想清楚一个前置问题：线下体育馆平时最让管理员头疼的是什么？

我自己接触过的实际场馆运营场景里，痛点基本集中在四类：

• 场地预约靠人工登记，电话、微信、现场三套记录经常对不上，时间冲突是家常便饭。
• 会员信息散落在Excel和纸质表里，办卡、续费、扣次全凭管理员脑子和本子，月底对账想哭。
• 课程和私教安排靠群里喊，学员来没来、教练排没排、场地够不够用，全靠现场协调。
• 经营数据一团模糊，哪个场地利用率最高、哪个时段最空闲、会员流失什么原因，完全无据可查。

你把这个痛点清单列出来，再对照百胜体育馆管理系统这类的题目要求，就会发现整个系统的功能边界其实是被这些问题天然划定的。所以做系统设计的第一步，不是急着建SpringBoot工程，而是先把"业务闭环"画出来：场地预约、会员管理、课程管理、设备管理、订单流水、统计报表，这几块串起来，才是体育馆的日常运营全貌。

1.2 核心功能范围界定

明确了痛点，功能模块就水到渠成了。以一个合格的毕设体量来看，下面这些模块是最低配，做好了就是加分项：

有同学会问，是不是要加个支付功能？我的建议是：线上支付可以做，但不要强制，用"模拟支付"或"余额扣减"代替真实支付通道，既能完整走通业务流程，又不用去申请商户号，避免卡在资质环节干着急。你要知道，毕设评审老师关心的是你业务逻辑能不能闭环，而不是你真接了微信支付。

2. 技术选型的事后复盘

2.1 为什么是SpringBoot

这个题目挂在SpringBoot下面是有道理的。SpringBoot在毕设里的统治力，主要来自三个层面。

第一，开发效率。起步依赖直接帮你把Spring MVC、内嵌Tomcat、Jackson序列化这些基础组件全部配好，你不用像当年用SSH（Spring MVC + Spring + Hibernate）那样写一堆XML配置文件。我见过不少同学用SSM框架老项目改造，光配置文件就调试了两三天，而SpringBoot项目基本clone下来改个数据库密码就能启动接口服务。

第二，生态成熟度。SpringBoot几乎能无缝对接毕设里用到的所有主流组件：MyBatis-Plus、Redis、JWT、Spring Security、Swagger/Knife4j，全都有官方或社区starter，遇到问题搜解决方案也容易，因为用的人太多了。

第三，分层清晰。Controller、Service、Mapper这三层结构配合Spring的依赖注入，写出来的代码天然规整，答辩的时候也容易讲清楚"请求是怎么一层层处理下去的"。

选型上我建议SpringBoot 2.7.x系列，这是市面上资料最多、兼容性最稳的版本段。别一上来就追SpringBoot 3.x，它基于Jakarta EE改名了一套包名，JDK要求也升到了17，很多老教程里的代码直接粘过来会报错。我在5.1节会专门说这个坑。

2.2 MyBatis-Plus和MyBatis怎么选

持久层框架这关，我强烈建议用MyBatis-Plus，而不是裸写MyBatis。理由很实在：

• 单表CRUD不用写SQL。BaseMapper内置了insert、updateById、selectList这些方法，你只需要定义实体类，Mapper接口继承BaseMapper ，增删改查就全有了。这对于场馆、课程、公告这类常规表来说，能省下大量的重复代码。
• 条件构造器好用。LambdaQueryWrapper能实现动态条件查询，比如"查今天空闲的羽毛球场地"，就是wrapper.eq(status, 1).eq(type, "羽毛球")的事，不用手动拼接SQL字符串。
• 分页插件成熟。PaginationInnerInterceptor插上后，page对象直接返回total和records，做列表页分页太方便了。
• 和SpringBoot配合零折腾。引入mybatis-plus-boot-starter，application.yml里配好数据源和mapper-locations就能跑。

我这里给一个典型配置，你自己项目里可以直接借鉴：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/gym_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.baisheng.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里有个细节，logic-delete-field配置的是逻辑删除字段，意思是数据不真删，只打标记。预约记录、订单流水这类数据尽量别物理删除，否则以后统计报表日期缺角，查数据也不好追溯。逻辑删除是你在答辩时能主动讲出来的加分点，体现你有数据安全意识。

2.3 前端与部署方案

前端的选型，我推荐两种路线，看你的基础。

路线一：Vue3 + Element Plus + Vite。这是目前的主流组合，组件库美观度足够，表格、表单、弹窗都有现成的，做管理后台效率很高。配合Axios做请求封装，前端也按下标、场馆、预约几个页面去组织，和后台接口一一对应，结构很清晰。

路线二：如果前端基础薄弱，可以考虑服务端渲染的Thymeleaf加Bootstrap，一套Spring Boot工程直接搞定，不用前后端分离。优点是部署简单，一个jar包跑起来所有页面都在，缺点是页面交互性弱一些，复杂的状态切换体验差些。

关于部署，毕设阶段我不建议花钱买服务器折腾Nginx和Docker，就用最朴素的方案：本机打包mvn clean package，把生成的jar文件用java -jar启动，浏览器访问localhost:8080演示。如果想在手机上演示给老师看，局域网模式启动时在application.yml里把地址配成0.0.0.0，手机连同一个WiFi就能访问。

3. 数据库设计与核心表规划

3.1 实体关系梳理

数据库设计是决定项目上限的一环，很多同学表建得很随意，后面做统计报表时痛苦到怀疑人生。先梳理核心实体关系，再动手建库，顺序不能反。

体育馆项目核心实体包括：用户（会员）、管理员、场馆、场馆类型、预约订单、课程、课程安排、教练、会员卡、充值/消费流水、公告。实体之间的关系大概是：

• 用户与预约订单：一对多，一个用户可以有多个预约订单。
• 场馆与预约订单：一对多，一个场馆在多个时间段被不同订单占用。
• 课程与教练：多对一，一个教练可以带多门课程。
• 用户与会员卡：一对一，一个会员当前持有一张有效卡（也可以记录历史换卡）。
• 订单与流水：一对多，一次预约可能涉及下单、退款等多条流水记录。

3.2 关键表结构细节

下面我把最重要的几张表拿出来拆解，这张字段清单基本可以直接当建表参考。

场馆表venue：

CREATE TABLE venue ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '场馆名称', type VARCHAR(50) NOT NULL COMMENT '类型：篮球/羽毛球/游泳等', capacity INT DEFAULT 1 COMMENT '容纳人数', price DECIMAL(10,2) NOT NULL COMMENT '每小时价格', status TINYINT DEFAULT 0 COMMENT '状态：0空闲 1占用 2维护', description VARCHAR(500), deleted TINYINT DEFAULT 0 COMMENT '逻辑删除标记', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

预约订单表booking_order：

CREATE TABLE booking_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单号，全局唯一', user_id BIGINT NOT NULL COMMENT '预约用户id', venue_id BIGINT NOT NULL COMMENT '场馆id', booking_date DATE NOT NULL COMMENT '预约日期', start_time TIME NOT NULL COMMENT '开始时间', end_time TIME NOT NULL COMMENT '结束时间', amount DECIMAL(10,2) NOT NULL COMMENT '订单金额', status TINYINT NOT NULL COMMENT '订单状态：0待支付 1已支付 2已取消 3已完成', remark VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 );

这个表里我特意要强调两个字段设计。

订单号order_no必须唯一。千万别用自增id直接当订单号暴露给前端，因为自增id能暴露出你的订单总量，也容易被遍历。简单做法是日期加随机数：

String orderNo = "BK" + LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss")) + String.format("%04d", ThreadLocalRandom.current().nextInt(10000));

booking_date、start_time、end_time三个字段分开存也是故意的。有同学图省事存一个booking_time的datetime字段，结果按"查某天上午10点到12点有哪些空闲场地"这种需求做筛选时，SQL长得能绕地球一圈。拆开存，查询、排序、冲突判断都简单，这是典型的"设计时多花一分钟，实现时省一小时"。

会员卡表member_card：

CREATE TABLE member_card ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, card_type TINYINT NOT NULL COMMENT '卡类型：1次卡 2月卡 3季卡 4年卡', total_count INT DEFAULT 0 COMMENT '总次数（次卡用）', remain_count INT DEFAULT 0 COMMENT '剩余次数', balance DECIMAL(10,2) DEFAULT 0 COMMENT '余额（储值卡用）', valid_start DATE, valid_end DATE, status TINYINT DEFAULT 1 COMMENT '状态：1生效 0失效', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

卡类型为什么分次卡、月卡、年卡？因为计费模型不一样。次卡按次数扣，月卡年卡按时间区间判断有效性，储值卡按余额扣。你用一个card_type字段区分计费策略，Service层写一个策略分发逻辑，既不混乱，也算一个设计模式的实际应用——这个在答辩时讲"策略模式"绝对能引起老师兴趣。

3.3 时间冲突与约束设计

预约系统最核心的校验是时间冲突。业务规则：同一场地的预约时间段不能重叠，否则两个人同时占了一个场地，线下就炸了。

冲突判断的逻辑是这样：给定一个venueId，再给定bookingDate、startTime、endTime，查询是否存在"已支付或待支付状态、日期相同、开始时间小于新结束时间、结束时间大于新开始时间"的订单。用SQL表达就是：

SELECT COUNT(*) FROM booking_order WHERE venue_id = #{venueId} AND booking_date = #{bookingDate} AND status IN (0, 1) AND deleted = 0 AND start_time < #{endTime} AND end_time > #{startTime}

这个条件为什么是"开始时间小于新结束时间"且"结束时间大于新开始时间"？这是区间重叠判断的标准写法，覆盖了四种重叠情况：新预约完全包含已有、已被包含、左相交、右相交。凡是重合的，两边都会满足这两个不等条件；只有完全不搭界——新开始时间大于等于已有结束时间，或新结束时间小于等于已有开始时间——才查不出来。这个逻辑我建议你亲手推导一遍，理解它比背下来重要，因为防的就是边界case，比如别人约到11:59，你约12:00，刚好不冲突。

另外，为了扛并发，请在booking_date、venue_id、status上建联合索引，并配合数据库层面的约束思路。毕设阶段不要求上分布式锁那么重的东西，但如果你用了MySQL的悲观锁SELECT ... FOR UPDATE来锁订单行再校验，这是一个很好的加分项，说明你考虑过并发场景。

4. 核心业务实现细节

4.1 场地预约的完整流程

预约操作是系统的核心主链路，流程设计要清晰：查场地、选时段、校验冲突、创建订单、扣余额或模拟支付、更新场地状态。

Controller层建议只做参数接收，Service层做业务编排，这样节奏清爽。核心Service方法的伪代码如下：

@Transactional(rollbackFor = Exception.class) public BookingResult createBooking(BookingRequest request) { // 1. 校验用户存在且会员状态正常 User user = userService.getById(request.getUserId()); // 2. 校验场地存在且未处于维护状态 Venue venue = venueService.getById(request.getVenueId()); if (venue.getStatus() == 2) { throw new BizException("场地维护中，暂不可预约"); } // 3. 校验时间段是否冲突 long conflictCount = bookingOrderMapper .selectCount(new LambdaQueryWrapper<BookingOrder>() .eq(BookingOrder::getVenueId, request.getVenueId()) .eq(BookingOrder::getBookingDate, request.getBookingDate()) .in(BookingOrder::getStatus, Arrays.asList(0, 1)) .eq(BookingOrder::getDeleted, 0) .lt(BookingOrder::getStartTime, request.getEndTime()) .gt(BookingOrder::getEndTime, request.getStartTime())); if (conflictCount > 0) { throw new BizException("该时段已被预约，请选择其他时间"); } // 4. 计算金额，按次卡优先扣次 BigDecimal amount = venue.getPrice() .multiply(BigDecimal.valueOf(calcHourDuration(request))); // 5. 创建订单 BookingOrder order = new BookingOrder(); order.setOrderNo(generateOrderNo()); order.setAmount(amount); // ... 其他字段赋值 bookingOrderMapper.insert(order); // 6. 模拟支付（扣会员余额） memberCardService.deduct(user.getId(), amount); return BookingResult.success(order); }

注意几个实现要点。

@Transactional事务注解必须加上，因为扣余额和创建订单两个操作要保证原子性，任何一个失败都必须整体回滚，否则出现"钱扣了订单没生成"或反过来，对账必炸。

金额计算用BigDecimal，绝不能用double！这是Java做金额计算的铁律。double的浮点误差在做乘法累加时会产生零点几分钱的偏差，平时看不出来，月末对不上账你就哭吧。单价乘以小时数，用BigDecimal的multiply方法，保留两位小数，scale设为2，RoundingMode.HALF_UP四舍五入。

小时数的计算也埋了个细节。体育馆通常最小预约单位是半小时，你可以在前端限制选择时间粒度，也可以在后端做校验。我的建议是服务端也要再校验一次startTime和endTime的分钟数必须是0或30，前端限制是体验问题，后端校验是安全底线，信不过用户输入是后端开发的基本素养。

4.2 会员卡与扣费逻辑

会员卡计费这块，我建议用策略模式把那几种卡的扣费差异化封装起来，而不是在Service里堆if-else。思路是这样的：

public interface CardStrategy { void deduct(MemberCard card, BigDecimal amount); } public class CountCardStrategy implements CardStrategy { public void deduct(MemberCard card, BigDecimal amount) { int remain = card.getRemainCount(); if (remain <= 0) throw new BizException("次卡次数已用完"); int next = remain - 1; card.setRemainCount(next); if (next == 0) card.setStatus(0); } } public class TimeCardStrategy implements CardStrategy { public void deduct(MemberCard card, BigDecimal amount) { if (card.getValidEnd() == null || card.getValidEnd().isBefore(LocalDate.now())) { throw new BizException("卡已过期"); } } }

然后做一个CardStrategyFactory，根据cardType返回对应策略，Service层只管调用strategy.deduct(card, amount)。这样一来，以后要想新增一种"十次卡赠送两次"的卡，只需新增一个策略实现类，其余代码不用动。这就是开闭原则的一个真实案例，答辩提出来，比你空讲设计模式概念有力得多。

扣费流水也要单独记。我建议建一张account_flow流水表，字段包括流水号、用户id、关联订单号、变动类型（充值/消费/退款）、变动金额、变动前余额、变动后余额、备注、创建时间。为什么要变动前余额和变动后余额？这是对账的抓手，如果哪笔账期望对不上，你能顺着流水表回溯到每一步余额变化，迅速定位问题。这个"余额快照"的思路在财务系统里是标配，哪怕毕设规模小，设计感也拉满。

4.3 课程与教练模块的扩展设计

除了预约场馆，体育馆一般还开设团课和私教课。课程安排表可以这样设计：一个course表存课程基本信息（名称、教练id、场地id、上课时间、上课日期、容量、已报名人数、价格、状态），再配一张course_booking表存学员报名记录。

课程报名和场地预约的核心区别在于容量概念。场地是"同一时段只能一个人或一队人占用"，课程是"同时间段最多N个人报名"，允许N个人同时存在。所以课程表里维护一个capacity字段，报名时判断已报名人数是否小于容量，并在事务里对课程行加锁更新人数：

Course course = courseMapper.selectByIdForUpdate(courseId); if (course.getEnrolledCount() >= course.getCapacity()) { throw new BizException("课程名额已满"); } course.setEnrolledCount(course.getEnrolledCount() + 1); courseMapper.updateById(course);

selectByIdForUpdate是悲观锁的一种，确保并发下两个人同时报名最后一人时，不会超卖。毕设阶段做到这一步，并发考虑已经超过大多数同期作品了。

教练这块可以单独建coach表，管理姓名、专长、简介、照片、在职状态。排课校验也要注意一个规则：同一教练同一时间段不能跨场地同时上两节课。

4.4 后台管理端与数据统计

后台管理端的功能模块包括：管理员登录、场馆信息维护、课程管理、用户管理、订单管理、会员卡管理、公告管理。这里很多都是标准CRUD，不用过多展开，唯独自定义查询值得说说。

后台列表页不可避免会遇到组合条件查询，比如"查姓张的、注册时间从3月到6月、当前状态正常的所有会员"。MyBatis-Plus的LambdaQueryWrapper直接链式拼接，条件为空时自动跳过，不会拼出错误SQL。这在Controller层接收多个查询参数时特别方便：

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(name), User::getRealName, name) .ge(startTime != null, User::getCreateTime, startTime) .le(endTime != null, User::getCreateTime, endTime) .eq(type != null, User::getUserType, type) .orderByDesc(User::getCreateTime);

每个条件里的前置boolean表达式是关键：只有当参数非空时才拼该条件。如果你不做这个空值判断，用户不填姓名时SQL就变成WHERE real_name LIKE '%%'，虽然也能查出结果，但全表扫一遍的性能隐患和潜在的意外结果就出来了。

数据统计这块，利用MySQL的日期函数可以轻松实现按天、按月聚合。比如查每天的预约营收：

SELECT DATE(create_time) AS day, SUM(amount) AS total_amount FROM booking_order WHERE status = 1 AND deleted = 0 GROUP BY DATE(create_time) ORDER BY day;

前端配合ECharts画折线图和柱状图，场地利用率、月度营收走势、会员增长曲线，这三张图一摆，管理端的专业感马上不一样。数据可视化是很多毕设的薄弱环节，你做好了，就是亮点。

5. 实操过程中的踩坑实录

5.1 SpringBoot版本太高引发的连锁反应

SpringBoot版本坑我几乎每年都在学生项目里见到。特别常见的情况是：照着教程下载了最新版SpringBoot 3.x，引入spring-boot-starter-web后，又引入自己之前搜到的旧教程里的javax.*包代码，一启动就是ClassNotFoundException: javax.servlet.Filter。

原因在于SpringBoot 3.0是一次大版本更新，Servlet API从javax.servlet迁移到了jakarta.servlet，同时所有第三方starter的兼容性也变了。简单说，你引入的依赖和代码里import的包名必须跟这根体系走，混着用必炸。

解决方案很简单，回归SpringBoot 2.7.x。JDK保持8或11，依赖多选尚在维护的稳定版本，遇到问题去GitHub搜issue，资料齐全，社区里基本你踩过的坑别人都踩过并解决了。这不是技术退化，而是毕设求稳的理性选择。

5.2 MyBatis-Plus自动生成建表SQL的问题

现在很多项目用MyBatis-Plus的代码生成器，根据实体类自动生成Mapper、Service、Controller，甚至有人想让它直接根据实体类生成建表SQL。这个思路很好，但实际用起来有两个局限值得一提。

第一，代码生成器生成的是Java类之间的CRUD代码，不是数据库表结构。它默认假设你的表已经存在，因为实体类字段必须和表字段一一对应才能正常工作。想省事的话，可以用MyBatis-Plus-generator 3.5.1及以上版本自带的DbType配置，配合InitTable之类的辅助脚本，但更稳定的做法是自己写建表DDL，或者用工具从Excel设计稿导出SQL。

第二，实体类字段类型和MySQL字段类型的映射不完全等价。比如Java的LocalDateTime在MySQL里要明确DATETIME，Boolean可能映射成TINYINT(1)。如果直接让工具自动生成表，产出的字段类型往往不够精准，比如金额该用DECIMAL(10,2)它可能生成DOUBLE，这不就回到double的坑了嘛。所以我的建议是：表结构设计优先，实体类其次，先建表再逆向生成实体类，这个顺序别反了。

5.3 阿里云服务器和本地环境调试

毕设想部署到云服务器上演示，容易踩的坑是数据库连接配置和环境变量。我第一次帮学生部署时就遇到过：本地数据库密码是123456，服务器上改成了别的，结果他忘了改application.yml，jar包启动后日志连续报数据库拒绝连接，页面全白，急得团团转。

后来我学乖了，配置文件里不硬编码密码，用环境变量占位：

spring: datasource: username: ${DB_USERNAME:root} password: ${DB_PASSWORD:123456}

这样本地跑有默认值兜底，部署到服务器上用DB_PASSWORD环境变量注入真实密码，一台机器一套配置，互不干扰。同样思路也适用于JWT密钥、文件上传路径等环境相关配置。

另一个高频问题：服务器是宝塔面板管理的，部署SpringBoot jar包时端口默认8080，如果没在安全组放行，浏览器永远访问不通。要记住，云服务器有三层关口——应用监听地址、系统防火墙、云平台安全组，任何一层挡住都连不上。调试时先curl localhost:8080确认应用正常，再排查网络层，定位效率会高很多。

5.4 JDK环境变量与多版本冲突

有同学电脑上同时装了JDK 8和JDK 17，命令行java -version看到的版本和IDE里配置的版本不一致，反复起停项目排查半天，最后发现是环境变量JAVA_HOME指错了JDK路径。这个问题在Windows上特别典型，因为你改完系统环境变量，新开的命令行窗口才会重新读取，已经在用的终端窗口还是旧路径。

我的建议是：毕设阶段机器上只保留一个JDK，或者用IDE内部配置指定JDK版本，不要依赖系统全局JAVA_HOME。IDEA里Project Structure -> SDK选定JDK 8，Maven的Java Compiler改为8，保持三者一致再跑项目。真要在本地测多版本，用脚本临时切换JAVA_HOME，用完立即切回，别让多个版本的JDK同时在系统全局环境里争抢。

5.5 数据库时间字段的时区梦魇

连接MySQL时如果serverTimezone没配好，你在日志里能看到系统时间和数据库时间差了8小时，或者插入的时间字段少8小时。这是时区问题，不是代码错误。

解决方案就是在JDBC连接串显式指定时区：

url: jdbc:mysql://localhost:3306/gym_system?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

另外MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.x是com.mysql.jdbc.Driver，别混用。有时候同学按照老教程复制了驱动类名，连接MySQL 8怎么都报Loading class错误，就是这个问题。

6. 答辩演示与文档的加分细节

6.1 演示脚本要有故事线

很多学生答辩现场演示时，鼠标乱点，边点边想，给老师的印象特别差。我给你一个稳妥的演示脚本设计：按业务场景讲故事，而不是按菜单顺序走马观花。

演示开场就直接切痛点：今天有个会员想预约明天下午三点的羽毛球场地。你用这个账号登录用户端，走一遍查场地、选时段、提交预约、扣款的完整流程，然后再登录管理员端，在订单列表里看到这单的数据，在统计报表里看到今日营收的增长。这样一来，你的整个系统就是围绕一个真实场景在运转，老师不仅看到了功能，还看到了业务流程的串联，这就是"系统性强"的直观感受。

6.2 把做过的关键设计讲成亮点

答辩时不要只说"我用了SpringBoot和MyBatis-Plus"，要把工程里的设计思考提炼成有记忆点的亮点。我按项目实际情况帮大家梳理了几个：

• 场地时间冲突校验的区间重叠判断逻辑，能推导出四种边界情况。
• 余额快照流水表设计，保证每一笔账可追溯可对账。
• 会员卡计费的策略模式，新增卡类型不需要改动原有扣费逻辑。
• 悲观锁处理课程报名并发的超卖问题。
• 逻辑删除字段保护数据可追溯性。

每个亮点准备一个"为什么这么做"和"如果不这么做会怎样"的两句解释，老师问起来你就能对答如流。这就是我前面反复强调的原理重要性——能讲清楚为什么，才是真正的掌握。

6.3 文档写作的两个关键

毕设论文或设计文档至少要有两个核心章节需要认真写。

需求分析部分，不要只写"系统需要实现场馆管理"，最好配用例图和用例描述表，把每个角色能做什么操作一条条列出来。这个部分看起来基础，却是整个文档的逻辑起点，评委会从这里判断你有没有真正理解业务。

系统设计部分，开篇放一张系统的功能结构图，再放一张数据库ER图，两张图可以抵得上两千字。E-R图画清楚表之间的关联，字段注释给全，这段东西做扎实了，整个文档的专业度立马上一个台阶。

我个人还有个习惯是写"开发/部署文档"作为附录，把JDK版本、MySQL版本、建库脚本、启动命令、默认账号密码全部写清楚。这个附录答辩时老师经常翻，也是你自己以后重新运行项目时最需要的救命文档——毕竟三个月后再看自己的项目，你可能连启动步骤都忘光了。

说回到这个百胜体育馆管理系统，技术上不复杂，难的是把业务链条走完整，把设计细节想清楚，把坑提前规避掉。如果你正卡在某个地方，比如时间冲突的SQL写不对、SpringBoot起不来、MyBatis-Plus代码生成器配不明白，按着上面这几节的排查思路走一遍，大部分问题都能解决。真正用点心把这个项目打磨完整，它带给你的收获会远远超过一份毕业设计本身。