基于Java的羽毛球馆管理系统：Spring Boot预约设计与并发控制实战-平芜编程栈

1. 先搞清楚这个“管理系统”到底要管什么——需求边界与应用场景

很多人一看到“基于Java的羽毛球馆管理系统”，第一反应就是“又是一个XX管理系统，老套路了”。说实话，我刚接到这个题目的时候也是这么想的，但真正开始梳理需求之后才发现，羽毛球馆这种按场地、按时间段计费的业务，和普通进销存、信息管理系统有本质上的差异，要做得好用，远不是数据库增删改查那么简单。

先明确一下这类系统的典型用户角色和业务闭环。一个羽毛球馆的日常运营，核心参与方有三个：前台/管理员、顾客、场地资源。管理系统的本质，就是把这三者之间发生的业务动作——预约场地、按时段计费、会员充值、进场核销、收入统计——从线下纸质登记或Excel表格里解放出来，变成一套在线化的流程。

具体到功能边界，我梳理下来大致分为这几个板块：

场地管理：场馆内有多少片场地，每片场地的类型（塑胶、木地板）、是否可用、按时段的价格标准。
预约管理：顾客选日期、选时间段、选场地，完成预约；管理员可以代客预约、取消预约、处理爽约。
会员管理：会员信息建档、储值卡充值、余额扣费、会员等级与折扣。
订单与收费：预约成功后生成订单，结算方式支持单次付费或会员余额扣款，支持押金记录。
统计报表：每日/每月的场地使用率、收入汇总、热门时段分析，辅助场馆做经营决策。
系统管理：管理员账号、操作日志、基础参数配置（如营业时间、时段划分）。

这套需求放在任何一家中小型羽毛球馆都跑得通。也正因为业务场景典型，作为毕业设计或练手项目，它的完整性足够高，又不至于复杂到一个人搞不定，所以这类题目经久不衰。

再说直白一点：这个项目的难点不在“会不会写Java”，而在“能不能把场馆的预约业务在系统里设计得严谨”。后面我会逐个环节展开，尤其是时段冲突、并发预约、价格计算这些容易翻车的地方。

2. 技术选型：为什么是Spring Boot + MyBatis + MySQL，而不是更“老”的组合

很多人在技术选型上会犹豫，看到网上有SSH（Struts+Spring+Hibernate）的旧教程，也有Spring Boot + MyBatis Plus的新教程，还有前后端分离的Vue方案，到底怎么选？我的建议很直接：除非你的题目里明确指定了SSH或其他旧技术栈，否则无脑选Spring Boot + MyBatis + MySQL。理由有三条。

第一，Spring Boot把配置简化到了极致。SSH时代光配置XML就要折腾一两天，Spring Boot的自动配置让你把精力放在业务代码上，而不是配置文件里。第二，MyBatis上手成本低，SQL自己写，对于预约时间判断、场地使用率统计这类复杂查询，SQL的可控性远高于Hibernate的HQL。第三，MySQL是事实标准，环境资料多，面试问起来也顺理成章。

具体到版本组合，我实测稳定的一套是：

组件	版本	说明
JDK	1.8	主流稳定，兼容性最好
Spring Boot	2.7.x	2.x系列的最后一个较稳版本
MyBatis	3.5.x	配合mybatis-spring-boot-starter 2.x
MySQL	5.7 或 8.0	5.7兼容性好，8.0性能更强，建议8.0
前端	Thymeleaf 或 Vue 3 + Element Plus	看题目要求，非前后端分离用前者更省事

这里多说一句关于前端的选择。如果你的题目不要求前后端分离，老老实实用Spring Boot自带的Thymeleaf模板引擎，加入Bootstrap或Layui，开发效率最高，也最容易调试。如果题目要求前后端分离，那前端用Vue 3 + Element Plus + Axios，后端只提供RESTful API，这种方案展示效果更好，但工作量大概多出三分之一，需要自己权衡。

IDEA里建议安装Lombok插件，实体类不用写一堆getter/setter，代码能少一半。数据库工具用Navicat或DataGrip都行，我习惯用DataGrip，写复杂SQL调试起来比Navicat顺手。

这套组合还有一个隐形优势：网上排查问题的帖子最多。你随便搜一个报错，几乎都能找到对应解决方案。对毕设来说，“可维护性”的第一要义不是代码写得有多优雅，而是遇到bug时能不能快速查到资料。

3. 数据库设计：场地预约这类时间型业务，最容易出乱子的地方全在这层

数据库设计是这类系统最重要的环节，没有之一。很多人拿着“用户表、场地表、订单表”三板斧就开干，结果做到预约时间判断、场地冲突检测、按时间段统计收入的时候，发现表结构根本支撑不起来，只能推倒重来。我不想让你走这个弯路，直接把踩过坑之后验证可行的表结构拆给你看。

3.1 核心表清单与设计意图

以我的项目为例，共设计了8张核心表，覆盖上面说的所有业务模块：

user用户表：存放管理员和会员两类账号，通过role字段区分（0-管理员，1-会员）。字段包括用户名、密码（MD5加密存储）、姓名、手机号、余额、会员等级、创建时间等。
venue场地表：每片场地的编号（如A区1号）、类型（塑胶/木地板）、位置描述、状态（0-停用，1-可用）。
venue_price场地价格表：这里是最关键的一个设计。不同时段价格不同，比如工作日白天30元/小时，晚间和周末50元/小时。所以价格不能写死在场地表里，必须单独一张表，按时段模板关联。
time_slot时段表：定义一天的时段，如08:00-22:00，每1小时为一个时段，共14个时段。
reservation预约单表：核心业务表，记录谁在哪天预定了哪片场地、哪个时段。状态字段区分待支付、已支付（预订成功）、已取消、已完成、已爽约。
orders订单表：一笔预约对应一条订单，记录订单编号、金额、支付方式（现金/余额/微信）、支付时间、关联的预约单ID。
recharge_record充值记录表：会员充值的流水记录，用于对账。
operation_log操作日志表：记录管理员的关键操作，如代客预约、取消预约、调整价格等，方便审计。

3.2 最容易设计错的“时段”与“价格”

很多第一次做场馆系统的人，会把“日期”和“时间段”混在一起处理。比如直接在预约表里存一个start_time和end_time，这本身没错，但如果你想实现“一个时间段只能被一个人预约”，就必须做冲突检测，单纯用两个时间字段也能判断，但逻辑会绕很多。

我的做法是：预约单里存三个关键字段：reservation_date（预约日期）、time_slot_id（时段ID）、venue_id（场地ID），唯一索引设为这三者的组合。这样从数据库层面就杜绝了同一场地、同一天、同一时段被重复预约的可能。这是一个非常实用的小技巧，比在Java代码里先查再插要可靠一个量级。

价格表的字段设计为：venue_type（场地类型）、time_slot_id（时段ID）、weekday_type（工作日/周末）、price（价格）。这样设计有几个好处：

不同场地类型可以定不同价格；
工作日和周末可以分别定价；
时段调整只动时段表，价格表自动关联生效。

3.3 状态机设计：预约单的状态流转

预约单的状态一定要做成“状态机”思维，不能想改就改。我的约定是：

待支付(0) -> 已支付(1) -> 已完成(2) 待支付(0) -> 已取消(3) 已支付(1) -> 已取消(3) // 管理员或会员取消，需走退款逻辑 已支付(1) -> 已爽约(4) // 超过预约时间未到场

这个状态流转逻辑要在Service层统一封装，Controller层的每个动作都调用指定的方法，避免出现“状态乱跳”的脏数据。作为一个练手项目，把状态机这个意识建立起来，比多做三个功能都值。

3.4 预留扩展字段

如果想让系统看起来更有设计感，可以加一个sys_config表，存放营业开始时间、结束时间、每时段时长、押金金额等可配置参数。这样管理员不需要改代码就能调整场馆规则，答辩的时候也能多一个亮点可讲。

4. 开发环境与项目骨架搭建：手把手把第一行代码跑起来

环境准备这部分没太多玄学，但版本不一致导致的各种稀奇古怪的报错，我见得太多。直接给一套我跑通的版本组合，照着配基本不会出问题。

4.1 环境安装与版本核对

JDK 1.8：安装完一定要配置环境变量JAVA_HOME和PATH。命令行输入java -version确认版本。
Maven 3.6+：IDEA自带的Maven其实可以用，但最好配置阿里云镜像，不然拉依赖能等到怀疑人生。在settings.xml里设置mirror为aliyun。
MySQL 8.0：安装时选utf8mb4字符集。用户名root，密码自己记清楚。
IDEA：安装Lombok插件，配置好Maven仓库路径。

4.2 创建项目的三种方式，推荐第二种

方式一：IDEA Spring Initializr。适合有网络环境的情况，直接勾选Web、MyBatis、MySQL Driver、Lombok依赖生成项目。
方式二：手动搭建。创建一个Maven项目，pom.xml里手动填依赖。我推荐这种方式，因为你能看清每个依赖的作用，而不是无脑勾选。
方式三：从已有项目复制改。适合赶时间的人，但要注意改包名和配置，不然容易出问题。

pom.xml核心依赖配置如下：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

4.3 application.yml配置

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/badminton_venue?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword thymeleaf: cache: false mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.badminton.entity configuration: map-underscore-to-camel-case: true

这里map-underscore-to-camel-case记得一定要设为true，不然数据库字段reservation_date映射到Java属性reservationDate会失败，别问我怎么知道的，都是泪。

4.4 包结构与分层规划

一个典型的包结构如下：

com.example.badminton ├── controller // 控制器，只做参数接收和结果返回 ├── service // 业务逻辑层，核心逻辑全部在这 │ └── impl ├── mapper // MyBatis的Mapper接口 ├── entity // 实体类 ├── dto // 数据传输对象，接收前端参数 ├── vo // 视图对象，返回给前端的结果封装 ├── config // 配置类，如拦截器、WebMvc配置 ├── common // 通用工具类、常量、统一返回结果封装 └── BadmintonApplication.java // 启动类

分层不搞复杂，但Controller自己干活、Service空转、Mapper里塞业务逻辑这三件事坚决不能干。约定清请求参数的接收在Controller，业务规则判断在Service，数据库操作在Mapper，这个习惯一旦养成，后面维护起来会顺手很多。

5. 核心功能模块逐块拆解：从登录鉴权到预约下单的完整实现思路

骨架搭好之后，接下来就是把功能一个个填进去。我按业务主链路来讲：登录 → 场地查询 → 预约下单 → 订单支付 → 统计报表，这条链路走通了，基本功能就全了。

5.1 登录功能：简单会话管理，但别用明文密码

登录模块用Session做会话管理就够了，不需要引入Spring Security、JWT这种东西，那是给前后端分离的大型系统用的。但密码不能用明文，至少做MD5加盐。

用户表的密码字段存MD5(密码 + 固定盐值)，盐值可以写死在常量类里。

public class MD5Util { private static final String SALT = "badminton2024"; public static String encrypt(String password) { String toEncrypt = password + SALT; return DigestUtils.md5DigestAsHex(toEncrypt.getBytes(StandardCharsets.UTF_8)); } }

登录逻辑用拦截器统一校验，写一个LoginInterceptor，拦截除登录页、静态资源之外的所有请求。从Session里拿不到登录用户就重定向到登录页。这样每一接口就不用重复写“是否已登录”的判断了。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

5.2 场地查询与筛选：按日期+时段动态加载

场地查询是预约的前置动作，核心是“在选定日期和时段的情况下，哪些场地可约”。这个查询必须做关联判断，不能只查场地表，否则明明被约了还显示可约，那这个系统就废了。

我的做法是写一个Mapper查询，先查出所有可用场地，然后排除掉指定日期和时段已经被预约的场地：

<select id="findAvailableVenues" resultType="VenueVO"> SELECT v.*, p.price FROM venue v LEFT JOIN venue_price p ON v.venue_type = p.venue_type AND p.time_slot_id = #{timeSlotId} AND p.weekday_type = #{weekdayType} WHERE v.status = 1 AND v.id NOT IN ( SELECT r.venue_id FROM reservation r WHERE r.reservation_date = #{date} AND r.time_slot_id = #{timeSlotId} AND r.status IN (0, 1) <!-- 待支付和已支付都算占用 --> ) </select>

这里注意状态过滤：待支付和已支付状态都算占用场地，已取消和已完成的不能算。这一点特别容易被忽略，逻辑上想清楚就行了。

5.3 预约下单：事务 + 唯一索引双重保险

预约动作是典型的需要事务保护的操作。用户点了预约，系统要完成三步：检查场地是否仍可约 → 写入预约单 → 生成订单。这三步必须在一个事务里执行，任何一个失败都要整体回滚。

核心代码如下：

@Transactional(rollbackFor = Exception.class) public ReservationVO createReservation(ReservationRequest request) { // 1. 判断时段是否合法、场地是否存在 Venue venue = venueMapper.findById(request.getVenueId()); if (venue == null || venue.getStatus() != 1) { throw new BusinessException("场地不可用"); } // 2. 检查冲突（数据库唯一索引兜底） int count = reservationMapper.countConflict( request.getReservationDate(), request.getTimeSlotId(), request.getVenueId() ); if (count > 0) { throw new BusinessException("该时段已被预约，请选择其他时间段"); } // 3. 计算价格 BigDecimal price = priceMapper.findPrice( venue.getVenueType(), request.getTimeSlotId(), getWeekdayType(request.getReservationDate()) ); // 4. 创建预约单和订单 Reservation reservation = buildReservation(request, price); reservationMapper.insert(reservation); Order order = buildOrder(reservation); orderMapper.insert(order); return buildReservationVO(reservation, order); }

这里再强调一次唯一索引的重要性：三个字段(venue_id, reservation_date, time_slot_id)必须建联合唯一索引。这样即使是两个并发请求同时进来，最多只能有一个插入成功，另一个直接抛DuplicateKeyException，从数据库层面保证了冲突检测不会漏。

5.4 会员余额与支付：明确扣款对象的边界

会员充值和支付流程看起来简单，容易出错的地方在于“扣钱和更新预约状态必须同步”。如果先把余额扣了，再更新订单状态时出了异常，用户钱没了但订单还是待支付，这就很糟糕。

我的做法是把支付动作也放在同一个事务里：

@Transactional(rollbackFor = Exception.class) public void payByBalance(Integer orderId, Integer userId) { // 1. 查订单，校验归属和状态 Order order = orderMapper.findById(orderId); if (!order.getUserId().equals(userId)) { throw new BusinessException("订单不属于当前用户"); } if (order.getStatus() != 0) { throw new BusinessException("订单状态异常"); } // 2. 扣余额 int rows = userMapper.deductBalance(userId, order.getAmount()); if (rows == 0) { throw new BusinessException("余额不足"); } // 3. 更新订单和预约状态 orderMapper.updateStatus(orderId, 1); reservationMapper.updateStatus(order.getReservationId(), 1); // 4. 记录资金流水 rechargeRecordMapper.insert(buildPayRecord(order)); }

这里deductBalance的SQL写成update user set balance = balance - #{amount} where id = #{userId} and balance >= #{amount}，用一条SQL完成“判断余额是否够 + 扣款”，避免了先查再扣的并发问题。

5.5 取消预约与退款规则

取消预约的规则要提前定清楚。我的设定是：开场前2小时以上可以免费取消，全额退款；不足2小时取消按50%退款；开场后取消视为爽约，不退款。这个规则写在Service层的常量类里，方便调整。

退款动作就是把订单状态改为“已取消”，同时给用户余额加回退款金额。注意这里不能用“更新余额=原余额+退款金额”这种先查后改的方式，同样用一条原子SQL操作：

UPDATE user SET balance = balance + #{refundAmount} WHERE id = #{userId}

5.6 统计报表：只要一条简单的分组查询

月度收入统计、场地使用率排行这些，其实用一个GROUP BY就能搞定。比如“按月统计收入”：

SELECT DATE_FORMAT(pay_time, '%Y-%m') AS month, SUM(amount) AS total_income FROM orders WHERE status = 1 GROUP BY DATE_FORMAT(pay_time, '%Y-%m') ORDER BY month DESC

“热门时段统计”：

SELECT t.time_slot_desc, COUNT(r.id) AS reservation_count FROM reservation r LEFT JOIN time_slot t ON r.time_slot_id = t.id GROUP BY r.time_slot_id ORDER BY reservation_count DESC

报表的数据源就是这么简单，前端用ECharts画个柱状图或折线图，展示效果直接拉满。说实话，答辩的时候一张漂亮的图表比十页代码管用。

6. 排错实录：预约冲突、并发重复订单、日期跨月这三个坑，我是这么一步步排查的

这部分我挑三个我项目中真实踩过的坑来说，每一个都是排查过程，而不是直接给答案。这样做是希望大家以后遇到类似问题，能形成自己的排查思路。

6.1 并发重复预约：边界条件没问题，数据却还是炸了

第一次写预约功能时，我以为代码里查冲突就够了。本地测试一切正常，直到我开了两个浏览器窗口，同时提交同一场地的同一时段预约，结果两条都成功了。后来排查过程是这样的：

第一步，我先在数据库管理工具里查预约表，发现确实插入了两条同场地同时段的记录，说明Java代码层面的冲突检查没有起到作用。第二步，我断点调试Service层，发现两个请求几乎同时通过了countConflict检查，然后先后执行了insert。第三步，我的代码里“先查后插”并不是原子操作，两个线程在“查”的时候数据库里都没有记录，于是双双通过。第四步，解决办法就是给表加联合唯一索引，并捕获DuplicateKeyException转为友好的业务提示。

排查完我自己复盘了一下，这个问题的本质：任何“先查后写”的操作，在高并发下都有竞态条件。唯一索引是最后的防线上，这比任何代码层面的锁都要可靠。

6.2 时段边界判断：比如09:00-10:00和10:00-11:00到底冲不冲突

有一个Bug是用户反馈：预约了9点到10点的场地，居然还能预约10点到11点的，但这两个时段其实是不冲突的，因为前者的结束时刻恰是后者的开始时刻。问题出在我一开始用<=来判断冲突，把边界重复也算进去了。

正确的冲突判断逻辑应该这样理解：两个时间段不冲突的条件是，一个的结束时间小于等于另一个的开始时间。反过来说，冲突条件是：

start1 < end2 AND start2 < end1

比如9:00-10:00和10:00-11:00：

9:00 < 11:00 成立
10:00 < 10:00 不成立

所以判断为不冲突，符合直觉。但如果我把第二个条件误写成<=，就会把这种本不该冲突的时段也拦截掉。

不过，如果你的业务规定是“两场预约之间必须留半小时缓冲”，那就要增加一个bufferTime的判断，把这些边界条件放进常量表统一管理，方便后续调整。

6.3 日期跨月统计：用字符串处理月份，结果数据对不上

做月度报表时，我一开始用DATE_FORMAT(pay_time, '%Y-%m')来分组，实际跑下来发现数据对不上。排查后发现原因是我在Java代码里组装月份参数时用了new SimpleDateFormat("yyyy-MM")，然后直接拼进SQL的WHERE条件里，但传入的参数是字符串，跟数据库里的datetime字段比较时类型不一致，走了隐式转换，导致部分数据没被查出来。

解决办法：SQL参数直接传LocalDate类型，日期格式化交给数据库来处理，不要自己在Java层格式化成字符串再拼接。另一个更隐蔽的坑是跨年：统计2024-01的数据，如果没有带年份条件，会把2023年1月的数据也统计进去。所有报表查询，日期条件必须是“起始日期 + 结束日期”的双边界，而不是单个月份字符串。

6.4 一个排查故障的通用方法论

这三个问题都验证了一个老生常谈的道理：遇到bug先不要急着改代码，按“数据对不对 → 参数传得对不对 → 逻辑边界对不对 → 是不是并发问题”的顺序逐层排查，每一步都用日志或数据库查询来验证，而不是靠猜。这套方法我到现在还在用。

7. 界面设计思路与交互细节：后台管理页怎么做到“看起来专业且好用”

不再说具体页面布局，重点讲交互和展示上的几个细节。因为评审老师或者实际使用者，往往是通过页面交互来判断这个系统“用不用心”的。

7.1 场地预约页面：用网格视图替代列表

预约是高频操作，如果做成表格列表，使用者要点好几次才能完成一个预约。我建议用“网格视图”：横轴是时段，纵轴是场地编号，交叉点是一个可点击的格子。空闲的格子是绿色，已被预约的格子是灰色，当前选中的格子是橙色。用户点击格子，弹出确认框，确定价格，提交预约。这个交互和主流在线选座、选课系统的体验一致，上手成本比列表低得多。

7.2 表单校验：前端校验只是体验，后端校验才是安全

像手机号、预约日期这些输入项，前端一定做基本校验（比如是否为空、格式是否正确），但后端也必须做同样的校验。前端校验是为了减少无效请求，后端校验是为了防止有人绕过前端直接调接口搞破坏。这个意识必须养成：永远不要信任前端传来的数据。

7.3 操作反馈：每一个动作都要有明确结果提示

删除操作要二次确认，保存成功要有提示，余额不足要说明还差多少，预约成功要显示订单号。这些细节很多代码生成器做不出来，但恰恰是使用者（尤其是前台人员）最在意的。我项目里统一封装了一个Result类，所有接口返回固定的JSON结构，前端根据code字段判断是否成功，再弹出对应的提示信息。

7.4 管理端的权限控制：普通操作员和超级管理员要有区别

虽然用户表只有role一个字段，但权限上建议分两级：普通操作员能处理预约、收费、会员登记；超级管理员还能进行价格设置、数据统计查看、操作日志查询。权限控制用拦截器判断role字段即可，不需要引入复杂的权限框架，但功能上一定要区分，这算是一个很小的加分项。

8. 测试与部署：从自测用例到打jar包运行的完整流程

很多同学写完了代码，一运行没报错，就觉得自己做完了。其实从“代码能跑”到“系统可靠”，中间还差着系统的测试和部署这一步。这里分享我的做法。

8.1 核心业务的自测用例清单

至少要把这些场景手动跑一遍：

正常预约流程：选择场地、选择时段、提交预约、余额支付、查看订单。
冲突预约：同一场地同一时段已被预约时，系统能否正确提示。
并发预约：两个窗口同时提交，能否只有一个成功。
余额不足：账户余额低于订单金额时，能否正确拦截。
取消预约：开场前取消，退款是否正确；开场后取消，是否不退款。
日期边界：跨月、跨年的数据统计是否准确。
权限控制：普通操作员是否无法访问管理员功能。
异常输入：手机号格式错误、日期格式错误、空参数，是否有友好提示。

我建议用一个Excel表格记录测试时间和结果，这样答辩时可以顺带展示自己的测试意识。

8.2 打包部署：mvn package就够了

Spring Boot项目打包非常简单，在IDEA右侧Maven面板点击package，如果没报错，target目录下会生成一个xxx.jar文件。

本地部署测试：

java -jar badminton-0.0.1-SNAPSHOT.jar

如果想后台运行，Linux服务器上用：

nohup java -jar badminton-0.0.1-SNAPSHOT.jar > app.log 2>&1 &

注意打包前要把application.yml里的数据库地址改成实际部署环境的地址。如果数据库密码里有特殊字符，记得URL里要做转义，这个坑我踩过，数据库连不上时的报错信息还特别不明显。

8.3 演示环境的准备

答辩或项目展示时，建议准备一套完整的数据，不要上来是空的。预先构造好：10个会员、5片场地、两天的预约数据、一周的充值流水、一张月度统计图。展示的时候，顺着“登录 → 首页看数据 → 预约流程 → 会员管理 → 统计报表”这条主线走，逻辑清晰又流畅。另外，现场演示前一定要启动一次项目确认环境正常，这个细节不用我多说，但每年都有人栽在这里。

9. 这个项目的扩展方向：从“毕设能用”到“商业可用”要做的事

如果你做完基础功能还有余力，或者想在答辩里展示一些超出预期的思考，下面这些扩展方向可以挑一到两个做。不贪多，但做出来的东西要让评审老师看到你有“工程思维”，而不只是会写CRUD。

场地预约的自动冲突锁场机制：在下单前加一个“虚拟锁”或基于Redis的分布式锁，防止高并发下同一场地被抢。毕设用不上，但话术上能讲一讲。
消息通知：预约成功、取消退款、余额不足时，给用户发短信或邮件通知。可以对接阿里云短信服务，但要点到为止，不要为了“高大上”把项目搞失控。
Excel导出：将订单数据、会员数据导出为Excel，方便场馆财务做账。用Apache POI或EasyExcel实现，代码量不大，实用性很强。
使用率的热力图展示：把场地使用率做成一周热力图（纵轴时段、横轴星期几），一眼看出场地运营的高峰低谷，这是真实场馆经营者最喜欢的功能。
Spring Security整合：把自制的拦截器替换成Spring Security框架，学习一下框架的标准用法。这个对你面试时聊权限设计会有帮助。

我个人觉得，选1-2个做深做透，比每个都浅尝辄止要好得多。项目深度永远是比宽度更值钱的东西。

10. 我做完整个项目后的几句大实话

最后聊点技术之外的东西。这个项目从头到尾做完，我最大的体会是：管理系统类题目，最容易被人做成“套壳增删改查”，而真正拉开差距的，是对业务规则的理解和对边界情况的处理。

预约冲突、并发扣款、状态流转、时间边界、金额计算，这些才是系统的灵魂。你把这些问题解决好，哪怕界面朴素一点，代码里的逻辑梳理清楚，就已经是一个“能用的系统”。反过来，如果你只把注册登录和CRUD做完了，页面再花哨、特效再多，评委问一句“同一时段被抢了怎么办”，你就容易露怯。

所以我给后来者的建议是：先把这个业务彻底想明白，想明白再动手。画清楚用户角色、业务流程图、状态流转图，再上手写代码，效率反而更高。你不必追求大而全，但每个做出来的功能，都应该能经得起推敲。

如果你正在做类似的课题，我希望这篇文章能帮你少走一些弯路。哪怕你没有全看懂，照着核心表结构把数据库建出来，把预约冲突的判断逻辑理清了，再遇到问题，你应该就有感觉了。做项目就是这样，第一个能跑起来的版本永远是最差的，后面才会越改越顺手。