Spring Boot实战：公园场地预约管理系统从需求到答辩全攻略

如果你正在纠结 Java 课程设计或者毕业设计选什么题目我建议你看一眼“公园游玩场地预约管理系统”。这个题目听起来不复杂但它不是那种烂大街的图书管理、学生信息管理它把 Spring Boot 开发里最常见的一批考点——REST API、MyBatis 数据访问、事务控制、并发处理、定时任务、数据统计、角色权限——全都串在了一个非常接地气的场景里。我自己把这一套从需求分析、搭环境、写代码、准备文档到最后录制运行演示视频和讲解视频完整走了一遍最大的感受是这个题不是随便选一个“XX管理系统”能比的它既能稳稳做出来又能支撑起足够多的亮点去讲。我当时的 Java 基础也就刚学完 JavaSE 和 MySQLServlet 和 Spring Boot 也是边做边补项目前后花了一个多月。如果你的基础和我差不多这篇文章可以给你一个完整的参考如果你已经有一定 Spring Boot 经验也可以重点看并发处理和统计这两块它们是最容易被导师和面试官追问的地方。1. 为什么我会推荐“公园场地预约”作为 Spring Boot 实战项目1.1 它覆盖的考点比普通管理系统多得多大多数课设题目比如“员工信息管理系统”“图书借阅系统”做下来基本就是增删改查一张表、几个 Controller、几个 HTML 页面。公园场地预约不一样它天然带着几个纯管理端做不出来的业务场景预约本身有“时段冲突”问题你得处理并发场地有维护维修状态不是所有场地随时都能约游客统计不是靠人填出来的得从预约记录中聚合生成一张预约单有完整生命周期状态流转必须清晰用户和管理员看到的数据视图完全不同权限控制绕不开。这些点直接对应 Spring Boot 的核心能力。项目做完你写简历时不会再说“熟悉增删改查”而是“实现过带并发控制的预约系统”说服力完全不一样。我当时的技术选型是这样的组成部分选型说明开发工具IDEA 2022 / VS Code后端用 IDEA前端开发用 VS Code 会更轻JDK1.8稳定资料多课设首选后端框架Spring Boot 2.7.x避开 3.x 的命名空间与 JDK 17 问题持久层MyBatis Plus 3.5.x比纯 MyBatis 省掉大量样板代码数据库MySQL 8.05.7 也可以但 8.0 更容易遇到时区配置问题前端Vue 3 Element Plus ECharts预约表单、后台管理、统计图表都能覆盖构建工具Maven 3.8标准IDEA 自带项目管理Git Gitee 私有仓库推荐防手滑删库1.2 为什么是 Spring Boot 2.7 而不是 3.x这是我踩过一次坑后的经验。Spring Boot 3.0 开始JDK 最低要求 17底层包名也从 javax 变成了 jakarta很多老教程、老依赖直接不兼容。对课程设计和毕设来说稳定压倒一切2.7.x JDK 8 的组合网上资料最多出问题搜得到答案导师检查环境时也不会因为版本太新而打不开项目。另外 MyBatis Plus 3.5.x 和 Spring Boot 2.7 的兼容性非常顺不需要额外操心 starter 版本冲突。我在初期也试过用 JPA但最终还是换回了 MyBatis Plus因为课设阶段你更需要对 SQL 有掌控感导师问起“某条统计 SQL 怎么写”的时候你能说得清楚。2. 需求盘点与模块拆分把系统边界先划清楚再动手2.1 两类使用者的三种核心流程我在画用例图之前先给系统定了两个使用端游客端注册/登录、浏览所有场地、查看场地详情与可用时段、预约场地、查看/取消自己的预约。管理端维护场地信息开放/关闭、审核预约订单、安排设施维护计划、处理维护记录、查看游客统计报表、发布公园公告。预约主流程很直观游客选场地 → 选日期和时段 → 确认订单 → 管理员在后台确认/核销。公园场景一般没有在线支付但我仍然在订单表里预留了支付相关字段比如支付状态和支付时间。这样后续接微信/支付宝沙箱支付也方便答辩时还能顺带展开讲一句“预留了扩展位”。2.2 三个业务闭环预约闭环场地可用 → 用户下单 → 订单生效 → 到期核销 → 进入统计数据。维护闭环发现故障/上报 → 生成维护计划 → 场地状态转为维护中 → 预约查询排除该场地 → 维护完成 → 场地重新开放。统计闭环预约数据入库 → 定时任务按天汇总 → 写入统计表 → 前端 ECharts 展示。这三个闭环相互关联预约闭环产生数据维护闭环影响“可约场地”统计闭环消费预约数据。把它们画成一张流转图放在项目文档里答辩时讲“系统模块关系”两分钟就能讲完。2.3 角色权限怎么做为了不引入过重的框架我用 Spring Boot 拦截器 Session 实现登录态和角色判断管理员接口统一放在/admin/**前缀下拦截器里校验 session 中的 userRole 是否为 ADMIN。核心就两步Component public class AdminAuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(loginUser); if (user null) { response.setStatus(401); response.getWriter().write(未登录); return false; } // 角色不是 ADMIN 直接返回 403 MapString, Object userMap (MapString, Object) user; if (!ADMIN.equals(userMap.get(role))) { response.setStatus(403); response.getWriter().write(无权限); return false; } return true; } }再注册到 WebMvcConfigurer 里只拦截/admin/**路径。有人会问不用 Spring Security 吗我的回答是课程设计阶段把业务做扎实更重要权限用拦截器反而更容易讲清楚Spring Security 留着面试前专门学就行。3. 数据库设计六张表如何撑起预约、维护、统计三个闭环3.1 表结构总览一个公园预约系统不需要堆几十张表我最终落在六张核心表上sys_user、venue、reservation_order、maintenance_record、visitor_daily_stat、notice。表名用途关键字段sys_user用户与管理员id、username、password、role、phonevenue公园场地id、name、type、location、base_price、statusreservation_order预约订单id、order_no、user_id、venue_id、venue_name、price、use_date、time_slot、statusmaintenance_record设施维护记录id、venue_id、content、plan_start、plan_end、status、handlervisitor_daily_stat每日游客统计id、stat_date、venue_id、visit_count、order_countnotice公园公告id、title、content、create_time、publisher3.2 预约订单表绝不能只存 venue_id这是我在改版过程中体会最深的一点订单表除了外键 venue_id必须冗余场地名称和价格快照。原因很实际如果场地后来改名、调价甚至被删掉历史订单依然要能看得到“当时约的是哪里、多少钱”。如果只存 venue_id一旦 venue 表数据变化订单历史全乱套。这条设计在电商订单里非常常见移植到公园预约系统里答辩时导师一听就懂。订单状态字段我定义成 TINYINT具体是0待确认游客提交预约管理员还没处理1已确认管理员确认通过2已核销游客到场管理员核销3已取消游客或管理员取消4已过期预约日期已过但未核销状态流转只用数字不搞 String 枚举因为数据库里比较和索引性能更好前端再通过 Map 映射成中文显示。3.3 价格单独建一张表更划算我一开始偷懒直接在 venue 表写了一个 base_price 字段后来发现公园调价很频繁而且经常是“工作日一个价、周末一个价”。如果只靠 base_price预约下单时就没法根据日期自动算出正确价格。我的最终方案是新建 price_config 表CREATE TABLE price_config ( id BIGINT PRIMARY KEY AUTO_INCREMENT, venue_id BIGINT NOT NULL, week_flag TINYINT NOT NULL COMMENT 1工作日 2周末, price DECIMAL(10,2) NOT NULL, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );下单时先判断目标日期是工作日还是周末再去 price_config 取对应价格。如果没有配置就 fallback 到 venue.base_price。这个“价格策略”很容易在答辩时展开讲因为它涉及了“基础数据 动态规则”的思维。4. 预约核心链路从可约查询到生成订单的完整代码4.1 查询可约场地可约场地要同时满足三个条件场地状态为启用、当前没有处于“维护中”的维护记录、目标时段没有冲突订单。如果用纯 SQL 写大概是这个样子SELECT * FROM venue v WHERE v.status 1 AND NOT EXISTS ( SELECT 1 FROM maintenance_record m WHERE m.venue_id v.id AND m.status IN (0, 1) AND m.plan_start #{targetDate} AND m.plan_end #{targetDate} )不过我在实际项目里考虑到嵌套查询会影响列表页性能选择了在维护计划新增或完成时直接同步修改 venue.status把场地状态分成“空闲/占用/维护中”三种。查询可约场地就变成了一个单表条件查询效率高很多代码也短。这个“空间换时间”的思路是我做这个项目学到的很划算的一笔账。4.2 预约下单的 Service 实现下单是系统的核心方法我把它拆成清晰的五步Service public class ReservationService { Autowired private ReservationOrderMapper orderMapper; Autowired private VenueMapper venueMapper; Transactional(rollbackFor Exception.class) public ResultDto createOrder(OrderCreateDTO dto) { // 1. 校验场地存在且可用 Venue venue venueMapper.selectById(dto.getVenueId()); if (venue null || venue.getStatus() ! 1) { return ResultDto.error(场地不存在或不可预约); } // 2. 校验预约日期合法性 LocalDate useDate dto.getUseDate(); if (useDate.isBefore(LocalDate.now())) { return ResultDto.error(预约日期不能早于今天); } // 3. 校验时段参数 if (dto.getTimeSlot() null || dto.getTimeSlot() 1 || dto.getTimeSlot() 3) { return ResultDto.error(时段参数不合法); } // 4. 防止重复预约利用唯一索引 条件插入 int rows orderMapper.insertWithConflictCheck( dto.getUserId(), venue.getId(), venue.getName(), dto.getUseDate(), dto.getTimeSlot(), getPrice(venue, dto.getUseDate()) ); if (rows 0) { return ResultDto.error(该时段已被预约请选择其他时段); } // 5. 返回订单号 return ResultDto.success(); } }第 4 步是关键后续第五节专门讲。步骤 1 到 3 属于防御式校验必须在 Service 层做不能让前端页面替我们把关因为接口是可以被直接调用的。4.3 事务与异常回滚方法上加Transactional(rollbackFor Exception.class)注意一定要带 rollbackFor。Spring 默认只对 RuntimeException 回滚而很多业务异常我习惯用自定义异常抛出如果不指定 rollbackFor事务不会回滚数据就脏了。这里也建议在生成订单号时不要用简单时间戳拼接我用的规则是yyyyMMddHHmmss 4位随机数 userId后四位虽然不能保证全局绝对唯一但配合唯一索引完全够用而且比 UUID 短很多演示的时候好看。5. 同一时段被多人抢购怎么办并发防超卖的三种方案5.1 先复现超卖问题我一开始写的是“最朴素”的下单逻辑先查一下这个时段有没有订单没有就插入。看起来没问题但用 JMeter 开 10 个线程同时预约同一个场地同一个时段的时候出现了多条成功记录。因为这个“检查-插入”之间没有加锁多个请求同时发现“没有冲突”然后同时插入自然就超卖了。这个 Bug 反而成了我整个项目里最有价值的经验因为很多课程设计根本不会用并发工具去测自己的系统而你做了讲出来就是亮点。5.2 方案一悲观锁在线程 A 查询冲突记录时加上SELECT ... FOR UPDATE锁住对应场地记录事务提交后再释放。这样线程 B 只能等到锁释放后再查询就能看到线程 A 插入的订单。// 查询场地并锁行 Venue venue venueMapper.selectByIdForUpdate(dto.getVenueId()); // 再检查该时段是否已有订单悲观锁的优点是简单缺点也明显并发高的时候性能下降而且要确保 where 条件命中索引否则可能锁全表。这个方案适合演示给导师看“我懂锁”。5.3 方案二数据库唯一约束 条件插入这是我在真实项目里最终采用的方案。给 reservation_order 表建一个针对时段的唯一索引然后改用一个“带冲突检查的插入语句”CREATE TABLE reservation_order ( ... time_slot TINYINT NOT NULL, status TINYINT NOT NULL DEFAULT 0, UNIQUE KEY uniq_venue_date_slot (venue_id, use_date, time_slot, status) );但这会遇到另一个问题如果 status 是可变的唯一索引里包含 status同一个场地同一时段只要状态不同唯一索引就失效了。实践中更稳妥的做法是把“有效订单”单独用一个约束控制我在 MyBatis 里写的是insert idinsertWithConflictCheck INSERT INTO reservation_order (order_no, user_id, venue_id, venue_name, price, use_date, time_slot, status, create_time) SELECT #{orderNo}, #{userId}, #{venueId}, #{venueName}, #{price}, #{useDate}, #{timeSlot}, 0, NOW() FROM DUAL WHERE NOT EXISTS ( SELECT 1 FROM reservation_order WHERE venue_id #{venueId} AND use_date #{useDate} AND time_slot #{timeSlot} AND status IN (0, 1) ) /insert这个 SQL 的巧妙之处在于“插入前检查冲突”和“真正插入”是同一个原子操作配合唯一索引兜底即使并发非常极端数据库也会拦住重复数据。代码里判断rows 0就知道冲突了。5.4 方案三乐观锁还可以给 venue 表加 version 字段更新场地状态时SET version version 1 WHERE version ?更新行数为 0 就重试。这种方案适合“库存扣减”类场景。预约业务的本质是“检查一条记录是否存在然后插入一条记录”乐观锁不太自然而且重试逻辑会让课设代码变复杂。我最终只用了方案二代码量少效果直观压测时无论多少并发同时抢只有一个人能成功。这个结论写在项目文档里比任何空话都有说服力。6. 设施维护与游客统计从“能用”到“加分”的两个模块6.1 设施维护的状态联动维护记录表维护的不只是“什么时间修了什么”它的核心价值在于让系统知道“这段时间该场地不能被预约”。我在 maintenance_record 中设计了 plan_start、plan_end、status 三个关键字段在新增维护计划后立刻把对应 venue.status 改为 2维护中维护完成后再改回 1可用。这里有一个容易被忽略的校验点新维护计划的起止时间不能与预约订单的 use_date 重叠。不然会出现“游客都已经预约了系统又把场地维护掉”的逻辑矛盾。实现时在维护计划新增接口里做一次订单冲突查询如果有冲突订单直接拒绝保存并要求管理员先联系游客改期。6.2 游客统计只需要几条聚合 SQL游客统计模块我实现了三个维度按天统计、按周统计、按月统计。数据来源就是 reservation_order 表里面 status 为 1 或 2 的有效订单。-- 按天统计某场地游客数 SELECT use_date, COUNT(*) AS visit_count FROM reservation_order WHERE venue_id #{venueId} AND status IN (1, 2) AND use_date BETWEEN #{startDate} AND #{endDate} GROUP BY use_date ORDER BY use_date;按周和按月就是把 GROUP BY 改成YEARWEEK(use_date)、DATE_FORMAT(use_date, %Y-%m)。这套 SQL 非常简单但如果每次页面刷新都实时查订单表数据量大了以后会很浪费。所以我在做项目的时候选择用定时任务把“昨天”的数据提前算好写进 visitor_daily_stat 表页面直接查统计表。6.3 定时任务与图表接口定时任务用 Spring Boot 自带的 Scheduled 一行注解就行Component public class VisitorStatJob { Resource private VisitorStatService visitorStatService; Scheduled(cron 0 30 1 * * ?) public void buildYesterdayStat() { visitorStatService.buildStat(LocalDate.now().minusDays(1)); } }cron 表达式0 30 1 * * ?表示每天凌晨 1:30 执行一次。注意启动类上要加EnableScheduling不然注解不生效。统计接口返回近 7 天的数据前端用 ECharts 画一张折线图游客到访趋势一眼就能看懂。这个“订单数据 → 定时汇总 → 统计表 → 图表展示”的链路是我答辩时最有信心的演示点之一。7. 交付物整理源码、文档、运行视频和讲解视频要怎么做7.1 一个能“直接跑起来”的源码比什么都重要很多课程设计交上来导师第一件事就是让他跑起来看效果。所以我提交源码前刻意检查了几件事sql 脚本放在项目根目录 sql/ 下application.yml 里数据库账号密码用本地默认值并在注释中写明如何修改README 写清三步启动流程导入数据库 → 修改配置 → 启动后端和前端整个项目路径不要包含中文字符。我发现不少同学直接把整个项目拷进“新建文件夹”然后压缩包路径里全是中文。这个细节特别容易让运行视频第一步就翻车。7.2 文档结构与运行视频的脚本化我最终整理的项目文档包括这些部分项目概述背景、目标、技术栈需求分析用例图、角色说明、核心用例表数据库设计ER 图、表结构说明、字段注释接口文档每个接口的路径、请求参数、返回示例核心代码说明并发防超卖、状态联动、定时统计部署手册从零到能打开网页的完整过程。录制运行视频时不要即兴发挥我提前写好了一个脚本顺序是启动数据库 → 启动后端 → 启动前端 → 用户注册登录 → 游客浏览场地并发起预约 → 切换管理员账号 → 后台确认订单 → 添加维护计划 → 查看游客统计图表 → 结束。总共控制在 8-10 分钟不要录太长没人愿意看半小时的鼠标在屏幕上瞎移。7.3 讲解视频怎么讲才不像“读PPT”讲解视频我建议 10-15 分钟结构是“需求-设计-核心代码-演示-总结”。最核心的劝告是不要逐行读代码不要念 PPT。导师和同学真正想听的是“你遇到了什么问题、你的解决思路是什么”。例如讲到并发防超卖可以先抛出问题“我在压测时发现同一时段被多人同时预约会超卖”再讲怎么用条件插入和唯一索引解决。这种讲故事的方式比单纯说“我这里用了 Transactional”要有说服力得多。8. 开发过程中的踩坑日志与最终成果清单8.1 Spring Boot 3.x 与 JDK 8 不兼容我最早建项目时图新鲜选了最新的 Spring Boot 3.2结果 JDK 8 环境下编译直接报错提示程序包 javax.servlet 不存在。排查后才发现 3.x 已经改成 jakarta.servlet而且要求 JDK 17 以上。最后我删掉重新建了 2.7.x 项目问题彻底消失。给我的教训是环境版本不匹配是第一坑建项目之前先确认 JDK 版本。8.2 MyBatis 查询结果全是 null这个坑让我排查了很久。表字段是 user_name实体字段是 userName查询结果却一直是 null。原因是我没有开启 MyBatis 的下划线转驼峰配置。在 application.yml 加一行mybatis: configuration: map-underscore-to-camel-case: true问题立刻解决。如果不小心忘了加你会在调试时看到一条记录里只有 id 有值其它全是 null定位时要第一个想到它。8.3 前端跨域访问被拦截前端 Vue 跑在 5173 端口后端 Spring Boot 跑在 8080 端口浏览器直接请求接口报 CORS 错误。解决方法是在后端加一个 CorsFilterConfiguration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意 allowCredentials(true) 的时候allowedOrigin 不能写成*要使用 addAllowedOriginPattern。8.4 MySQL 8 的时区问题运行时报错The server time zone value Öйú±ê׼ʱ¼ä is unrecognized时不要慌这就是 MySQL 8 默认时区没设置的原因。在 JDBC URL 后面加上?serverTimezoneAsia/ShanghaiuseSSLfalsecharacterEncodingutf8即可。如果还报错再检查一下 MySQL 驱动版本是不是 8.x。8.5 上传图片或文件时提示超过大小限制项目里有公告和场地上传图片的需求。Spring Boot 默认单文件上传上限是 1MB我录入第一张场地图片时就报错。在配置文件中放开限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB另外图片保存路径不要写死成C:/user/xxx我后来改成了相对路径放在项目 resources/upload 目录下这样换机器跑也能正常访问。8.6 最终成果清单整个项目做完后我盘点了一下最终交付的成果Java Spring Boot 后端源码、Vue 前端源码、数据库初始化脚本、完整技术文档含 ER 图和接口说明、8 分钟运行演示视频、15 分钟讲解视频以及一份记录关键踩坑问题的开发日志。这套“源码 文档 运行视频 讲解视频”完整交付物其实比单一堆代码文档更能发挥作用因为它的每一部分都服务于同一个目标让项目能被理解、被复现、被认可。最后再分享一个小建议如果你时间充足可以把压测报告放进文档里简单写一下“用 JMeter 模拟 10 个并发请求最终成功订单数为 1”。这个结论本身的冲击力比任何技术名词都大。项目能不能让别人眼前一亮往往就看这些真实细节。