做课程设计或毕业设计，最怕的不是技术难点，而是题目看着大、做着空，最后答辩的时候讲不出“你解决了一个什么问题”。最近帮实验室学弟调试一个“基于SpringBoot的面向企业用户的复合型活动基地活动场地预约与活动规划系统”，我发现这个题目其实比大多数“XX管理系统”要有内容得多。预约不是简单地“插入一条订单”，活动规划也不是“写个备注字段”，真正做好落库、状态流转、排期冲突这三件事，就够写满一万字文档，也足够在答辩时讲到评委点头。这篇文章就围绕这个系统，从需求拆解、数据库设计、核心业务实现到避坑实录，完整过一遍。
这套系统的定位很清晰：面向企业用户，服务对象是一个拥有多类型场地的复合型活动基地。场地可能是室内会议厅、户外草坪、拓展训练区、多功能演播厅等，企业用户需要在线查看场地、选择时段、提交预约，并且在预约通过后，进一步规划活动的具体环节——几点签到、几点团建、几点用餐、场地怎么布置。如果你正在选课设/毕设题目，或者刚接触SpringBoot想找一个业务闭环完整、能写清楚“为什么这么做”的项目练手，这个方向值得参考。
1. 项目拆解：先想清楚这个系统到底在解决什么问题
1.1 复合型活动基地的业务痛点
很多同学一上来就画表、写代码，结果做到一半发现业务逻辑对不上。复合型活动基地和单一场馆最大的区别在于：场地是多类型的，使用是分时段的，活动是跨场地联动的。举个例子，一个企业要做20人的团建，上午在会议厅做开场分享，下午在户外草坪做拓展，晚上在餐厅用餐。人工排期的话，运营人员要在几张Excel表之间来回确认，最怕出现两个企业同时看中同一块草坪的同一个下午。
这类系统的价值就是把“线下手写登记 + 电话确认”变成“线上可视排期 + 状态自动流转”。预约通过后，企业还能在系统里对这次活动进行二次编排，把每个环节的时间、地点、负责人、物料需求列清楚。基地运营方则可以通过后台统一审核、管理场地状态、查看排期日历。这不只是把纸质流程搬上线，而是把“场地资源”和“活动计划”两条线绑定在同一个系统里。
1.2 需求分层：用户侧、运营侧、管理侧各管什么
需求分析不建议一上来就列功能清单，我习惯按角色分视角梳理，这样写出来的需求文档答辩时也更好讲。
- 用户侧（企业用户）：注册登录、浏览场地列表与详情、按日期查看场地可预约时段、提交预约申请、查看审核结果、对已通过的预约创建活动规划、维护活动环节明细。
- 运营侧（基地管理员）：维护场地信息（类型、容量、价格、图片、简介）、维护场地可预约时段、审核用户的预约申请、查看所有企业的活动规划、发布公告。
- 管理侧（系统管理员）：管理企业账号、管理用户权限、查看预约与活动数据统计、配置基础参数（如预约提前时长、单次预约最大小时数）。
这样的分层有一个好处：每个功能都能回答“谁在用、用来解决什么”。我见过很多课设代码，Controller里几十个接口堆在一起，问他“这个接口是给谁调的”答不上来，基本就等于白做。系统里各角色对应到菜单和权限后，项目结构自然就清晰了。
1.3 核心业务流程：一句话串起所有模块
整个系统可以用一条链路串起来：
企业用户注册并完善企业信息 → 浏览场地与可预约时段 → 提交预约申请 → 管理员审核 → 审核通过后企业创建活动规划 → 活动按环节执行 → 管理员在后台实时查看排期。
这里面有两个关键节点容易做浅。第一个是“可预约时段”的展示，它必须和已有预约数据联动，不能只是场地表里一个写死的开关字段。第二个是“活动规划”，它不是预约的附属备注，而是一套独立的主从表结构，包含活动主表和多个活动明细项，每个明细项有开始时间、结束时间、地点、负责人、所需资源。这两块做扎实了，系统才真正算得上“复合型活动基地”的预约与规划系统，而不是一个普通的场馆租赁单页。
2. 技术选型与工程结构：SpringBoot不是唯一解，但是稳妥解
2.1 为什么用SpringBoot + MyBatis + MySQL这套组合
选题阶段完全可以纠结一下技术栈，但一旦确认是课程设计或毕业设计，我的建议是求稳。SpringBoot赢在自动配置和内置容器，一条命令就能跑起来，不用像SSH那样写一堆XML配置文件。这对答辩演示非常友好——评委让你现场启动项目，你双击运行一个Main方法，服务就起来了，比配Tomcat再部署war包体面太多。
持久层选MyBatis而不是JPA/Hibernate，原因也很实际：MyBatis的SQL是自己写的，你对数据库做了什么一目了然，面试或答辩时被问“这条查询怎么优化”能直接说出SQL逻辑。而且网上的学习资料、踩坑案例绝大多数都是MyBatis体系，遇到问题更好查。
数据库选MySQL就不用多说了，免费、通用、毕业设计主流。需要注意的是版本和驱动匹配：如果你用了MySQL 8.x，连接驱动要配com.mysql.cj.jdbc.Driver，URL里还要加时区参数，否则启动时大概率报时区错误。这个细节后面专门说。
2.2 项目目录结构与分层设计的取舍
我见过不少同学的课设代码，Service类几千行，Controller里写SQL，实体类还夹杂着页面跳转逻辑。这种代码能跑，但答辩时一问“分层的作用是什么”就露馅了。这个题目我推荐按下面这套目录组织，既不过度设计，又能把职责讲清楚：
com.example.activity ├── controller # 接口层，接收请求参数，返回统一Result ├── service # 业务层，处理预约冲突、状态流转、活动规划等逻辑 │ └── impl ├── mapper # MyBatis数据访问层，写SQL或对应Mapper.xml ├── entity # 数据库实体类 ├── dto # 前端交互对象（如预约提交VO、活动规划VO） ├── config # 配置类（拦截器、跨域、全局异常处理） ├── common # 通用类（Result统一返回、状态枚举、常量） └── interceptor # 登录与权限拦截这里要多说一句：entity和dto要分开，不要嫌麻烦。预约表里可能存了创建时间、更新时间、状态备注等字段，前端提交预约时只需要场地ID、日期、起止时间、活动主题、人数就够了。直接用实体接收，要么多传了字段，要么有的字段前端填不了很别扭。用DTO做参数隔离，接口文档都好写很多。
权限这块，如果用了Spring Security，答辩时确实有亮点，但对课设来说复杂度偏高——你还要解释过滤器链、UserDetailsService、BCrypt加密等一堆概念。实测下来，用拦截器加Session判断登录态，按角色区分菜单和接口权限，完全够用，而且代码量少、逻辑透明。想加亮点的话，可以用拦截器统一做登录校验，再用一个自定义注解标记管理员接口，代码很简洁，讲起来也清楚。
前端方面，如果时间充裕，推荐Vue3 + Element Plus做一个管理后台，前后端分离，打包后放到SpringBoot的static目录或单独部署都行。如果时间紧，直接用Thymeleaf加Bootstrap渲染页面也可以，少一套跨域和Token处理，重点放在后端业务上。我帮学弟调试时用的是Vue前后端分离方案，管理端相对成熟，开发效率高，企业用户端也用同一套风格，整体一致性好。
2.3 为什么不推荐在这类课设里碰微服务
有人会想，网格里那么多SpringCloud、分布式锁、消息队列的热搜词，要不要堆点技术上去？我的意见是不要。这个系统的并发量远没到需要微服务的程度，加一堆中间件反而把核心业务淹没了。评委一眼就能看出你是为了凑技术栈而用技术，追问几个“为什么不用单机事务解决”大概率答不上来。老老实实把SpringBoot、MySQL、MyBatis这套组合吃透，把预约冲突、状态机、活动编排这些业务点讲深，比列十个中间件名称有用得多。
3. 数据库设计：预约不乱、规划不散的秘诀
3.1 核心表结构与关系梳理
数据库设计是这类系统的重中之重，预约业务最怕数据乱：一个场地同时段被抢、一个预约被重复审核、活动明细和主表对不上。我按实际表结构梳理一遍，你可以直接参考改造。
第一张表是用户表（t_user），字段包括用户ID、用户名、密码、真实姓名、手机号、角色（0企业员工、1企业管理员、2基地管理员）、所属企业ID。密码记得存加密后的值，不要明文入库。
第二张表是企业表（t_enterprise），包括企业ID、企业名称、统一社会信用代码、联系人、联系电话、注册时间、状态。用户和企业是多对一关系，企业充值或信用等级这些扩展字段可以先不放，保持精简。
第三张表是场地表（t_venue），重点在这几个字段：
| 字段 | 说明 |
|---|---|
| venue_name | 场地名称 |
| venue_type | 场地类型（室内会议厅/户外草坪/拓展区/餐厅等） |
| capacity | 容纳人数 |
| price_per_hour | 每小时价格 |
| open_time / close_time | 可预约的起止时间，比如08:00-22:00 |
| status | 场地状态（0停用 1启用） |
| description / image_url | 简介与图片 |
第四张表是预约订单表（t_reservation），这是整个系统的核心。字段包括预约单号、企业ID、用户ID、场地ID、预约日期、开始时间、结束时间、活动主题、参与人数、预算、状态、审核备注、创建时间、更新时间。预约日期和开始/结束时间分开存，是为了查询某一天的排期更方便。状态字段建议用Integer：0待审核、1已通过、2已拒绝、3已取消、4已完成。
第五张表是活动规划主表（t_activity），关联预约ID、企业ID，包括活动名称、计划日期、总预算、规划说明、状态。第六张表是活动明细表（t_activity_item），关联活动主表ID，包括环节名称、开始时间、结束时间、地点、负责人、所需资源、备注、排序号。这两张表是一对多的关系，活动规划的核心就是“主表定整体，明细表定环节”。
剩下还可以加公告表（t_notice）和操作日志表（t_log），公告用于基地运营方发布活动须知、临时闭场通知，日志记录关键操作，方便统计和回溯。不过日志表如果时间紧可以先不做，不影响主流程。
3.2 时间段冲突判断的两种建模思路
这是整个系统最值得认真讲的一个点，也是答辩时的加分项。场地预约绕不开一个问题：同一个场地、同一天、同一时间段，不能同时被两个预约占用。怎么设计数据表和查询逻辑来保证这一点？
方案一：预生成场地时段表。为每个场地生成固定时段（如每天按小时拆分），每个时段有独立状态。这种方案优点是好理解，管理端可以直接看到每个时段被谁占了；缺点是灵活度差，如果用户要订14:30到17:30这种非整点时段，就要拆成三个时段分别锁定，事务处理麻烦，跨时段还容易在边界上出Bug。
方案二：预约表直接存开始时间和结束时间，通过SQL重叠判断来检测冲突。重叠条件很简洁：
-- 判断某场地某时间段是否与已有预约重叠 -- 条件：新预约开始时间 < 已有预约结束时间 AND 新预约结束时间 > 已有预约开始时间 SELECT COUNT(*) FROM t_reservation WHERE venue_id = #{venueId} AND reservation_date = #{reservationDate} AND status IN (0, 1) AND start_time < #{endTime} AND end_time > #{startTime}这个方案更贴近真实业务，也更容易扩展到跨天预约。要注意的是边界约定：如果A预约是9:00-10:00，B预约是10:00-11:00，在“开始小于结束、结束大于开始”的规则下，两边不重叠，这符合日常理解，也避免了一个小时的边界被反复争抢。
我实际用的是方案二。插入预约时，先在同一数据库事务里执行一次重叠检查，确认无冲突后再执行Insert，并把这两步放在Service层的同一个事务方法中。数据库层面还可以给(venue_id, reservation_date, start_time, end_time)建组合索引，查询排期和冲突检测都快。
另外提醒一点：状态条件一定要加status IN (0, 1)。待审核的预约也要占住时段，否则可能出现两个待审核单同时通过、最后撞时段的问题。已拒绝和已取消的预约不参与冲突判断，相当于释放时段。
3.3 外键、冗余与逻辑删除的设计原则
外键在课设里是双刃剑。物理外键能保证引用完整性，比如预约单必须指向一个真实存在的场地和企业，但也会带来问题：删除场地时如果已有预约记录引用它，会报外键约束错误，处理起来很麻烦。我建议表设计时逻辑上用外键（字段关联），但不建物理外键约束，而在Service层自己控制引用校验。答辩时你可以说这是为了保持业务逻辑的可控性——这个说辞比“我不会配外键”要好听得多，也符合很多互联网公司的实际做法。
冗余字段也得用起来。预约表里存了venue_id，但我在查询列表时还会冗余一个venue_name，企业名称也会冗余。原因很简单：管理后台要展示“哪个企业订了哪个场地”，如果每次都去联表查场地表和企业表，SQL写得长，前端表结构也复杂。对于课设这种体量的系统，适度冗余能显著简化查询，而且这些字段属于低频更新数据，一致性风险很小。删除策略统一用逻辑删除，给表加一个deleted字段，删除时置1，查询时默认过滤。这比物理删除安全，万一误删还能恢复，写进文档里也是“数据安全设计”的一部分。
4. 核心业务实现：预约流程与活动规划怎么落地
4.1 预约主流程：状态机驱动的审核闭环
预约状态是整个模块的中枢。我在Service层用一个枚举类统一管理，避免代码里到处写魔法值：
public enum ReservationStatus { PENDING(0, "待审核"), APPROVED(1, "已通过"), REJECTED(2, "已拒绝"), CANCELLED(3, "已取消"), COMPLETED(4, "已完成"); private final int code; private final String desc; // 构造方法、getter省略 }预约提交时状态置为0，管理员审核通过后变1，活动结束后手动或定时置为4。取消操作是有讲究的：只有0和1状态能取消，2和4不能取消；取消后要释放时段，后续预约立刻能订这个时间。审核拒绝时要填写原因，前端才会显示“管理员驳回了预约申请，原因：场地维护”。
状态流转的校验逻辑一定要写在Service层，Controller只负责接收参数和调用Service。我用一个Map或者switch做状态流转表，非法流转直接抛业务异常。这样代码清晰，答辩时也能画出状态图来讲。
4.2 活动规划：预约之后的二次编排
预约审核通过后，企业用户可以创建活动规划。这部分我采用了“主从表”结构：活动主表记录一次活动的整体信息，比如活动名称、计划日期、总预算、整体说明；活动明细表记录每个环节，比如09:00-09:30在会议厅签到，09:30-11:00在拓展区做团队破冰，12:00-13:00在餐厅用餐。
明细表的排序字段特别重要。前端的时间轴展示、打印活动流程表、甚至导出Excel，都依赖排序号的顺序。实现时，我给每个明细项一个sort_order字段，查询时按sort_order ASC排序。新增明细时取当前活动明细里的最大排序号加1，调整顺序时做一个整段交换即可，逻辑简单且稳定。
活动明细里还建议加need_resource字段，记录这个环节需要基地提供什么资源，比如音响、投影、帐篷、烧烤架等。这能让系统从“场地预约”延伸到“资源协调”的层面，是复合型活动基地区别于普通场馆租赁的亮点之一。管理端可以按活动查看所有环节及所需资源，提前准备物料。
这个模块在答辩时可以重点讲表结构设计：为什么用两张表而不是把环节直接塞在预约表里。理由也很简单，一次预约可以对应多次活动（比如同一场地长期合作，按月规划），而一次活动必然有多个环节，一对多是天然的业务关系，拆分后扩展性和可读性都强很多。
4.3 并发与幂等：同一时段被抢订怎么办
“两个企业同时点击提交，订同一个场地同一个下午4点-6点，会发生什么？”这个问题，几乎每个答辩评委都会问。处理方案有三种，我按复杂度从低到高说。
方案一：事务内先查询再插入。在三层结构里，冲突检测和插入在同一个事务方法中，数据库默认的隔离级别下，如果两个请求同一时刻进来，MySQL的行锁和间隙锁能保证串行化执行。代价是性能一般，但对课设体量绰绰有余。
方案二：数据库唯一索引兜底。如果想更稳一点，可以给预约表加一个唯一索引(venue_id, reservation_date, start_time, end_time)，数据库层面强制任何重复时段都无法插入。但要注意，唯一索引会把“已拒绝、已取消”的记录也拦住，所以要么在状态变化时删除原记录，要么用部分索引（MySQL 8.0.13以后支持函数式索引，课设里讲清楚不容易，慎用）。我通常只在“待审核和已通过”这两类状态存在时，在代码里去重，唯一索引兜底放在“同一时间段不能存在两条有效预约”这一层。
方案三：Redis分布式锁。用Redis的SETNX实现一个简单的锁，key是lock:reservation:场地ID:日期:时段，拿到锁的请求才能执行预约创建。这个方案能讲出并发亮点，但引入了额外组件，如果对Redis不熟，答辩时容易被追问缓存与数据库一致性，反而被动。
我的建议是方案一为主，把重叠判断和插入放在一个事务方法里，然后再加一个组合索引保证查询性能。如果想让代码更有看点，可以在Service层加一个synchronized或JVM锁做进程内互斥，但是要说明清楚这只对单实例部署有效，多实例还是得靠Redis。能把“单机锁和分布式锁的区别”说出来，已经是超出课设水平的表现了。
4.4 统一返回结果与全局异常处理
接口格式统一，前后端联调会省很多事。我写了一个通用Result类：
@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { return new Result<>(200, "操作成功", data); } public static <T> Result<T> error(String message) { return new Result<>(500, message, null); } }再加上@RestControllerAdvice全局异常处理器，把业务异常、参数校验异常、系统异常分别映射成对应的错误码。这样前端只用判断code是否为200，其他都是弹错误提示，不用写一堆try-catch。全局异常处理还有一个隐藏好处：避免数据库异常直接暴露给前端，比如唯一索引冲突的报错信息对用户来说毫无意义，统一转成“该时段已被预约，请更换时间”更友好。
5. 实操记录：从空项目到跑通的完整过程
5.1 环境准备与版本选择
如果你用的是SpringBoot，版本选择上有一个大坑：SpringBoot 3.x需要JDK17，而很多学校的教学环境还停留在JDK8，不少同学的电脑也只装了JDK8。实测下来，课设阶段用SpringBoot 2.7.x系列最稳妥，配JDK8和Maven3.6+都能正常跑，网上搜到的教程和依赖坐标也基本都是这个版本体系。如果你自己熟悉JDK17，用3.x当然也行，但要注意javax包名改成了jakarta，一些老代码直接复制过来会报编译错误。
创建工程有两种方式：IDEA里直接选择Spring Initializr，或者到start.spring.io下载压缩包导入。下载慢的话用阿里云镜像https://maven.aliyun.com/repository/spring-plugin做初始服务地址，Maven仓库也换成阿里云，能省很多等待时间。依赖方面必加的有：Spring Web、MyBatis Starter、MySQL驱动、Lombok、Validation，前端用Vue的话再加Spring Security或拦截器相关配置，但Spring Security不是必须，我用拦截器方案就绕开了。
application.yml是启动的第一个拦路虎，我给出一个经过验证的最小配置：
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/activity_base?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.activity.entity configuration: map-underscore-to-camel-case: truemap-underscore-to-camel-case: true这个配置强烈建议打开，它能让数据库的venue_name自动映射到Java的venueName，少写一堆@Results注解。URL里的serverTimezone=Asia/Shanghai不能省，MySQL 8.x驱动不配时区，连接阶段就会报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized，这个错代码在中文环境里显示成乱码，特别迷惑人。
数据库脚本用Navicat或者命令行执行都行，记得表创建完后导入一条测试数据，验证连接是否正常。建议数据结构里把核心表的测试数据都准备好，比如3个不同类型的场地、1个测试企业账号、1个管理员账号，这样前端联调时不用反复造数据。
5.2 关键代码落地：Controller、Service、Mapper怎么组织
前面说了不用把代码全贴出来，但几个核心点值得给出参考写法。
第一个是预约创建的Service逻辑。先做基础校验，再做时段重叠检查，最后插入订单并生成预约单号：
@Override @Transactional(rollbackFor = Exception.class) public ReservationVO createReservation(ReservationCreateDTO dto, Long userId) { // 1. 参数校验：场地是否存在、场地是否启用、时间是否合法 Venue venue = venueMapper.selectById(dto.getVenueId()); if (venue == null || venue.getStatus() == 0) { throw new BizException("场地不存在或已停用"); } if (dto.getStartTime().isAfter(dto.getEndTime())) { throw new BizException("开始时间不能晚于结束时间"); } // 2. 冲突检测：同一场地同一日期同一时段不能有有效预约 int conflictCount = reservationMapper.countConflict( dto.getVenueId(), dto.getReservationDate(), dto.getStartTime(), dto.getEndTime()); if (conflictCount > 0) { throw new BizException("该时段已被预约，请更换时间"); } // 3. 创建预约订单 Reservation reservation = new Reservation(); BeanUtils.copyProperties(dto, reservation); reservation.setUserId(userId); reservation.setReservationNo(generateReservationNo()); reservation.setStatus(ReservationStatus.PENDING.getCode()); reservationMapper.insert(reservation); return convertToVO(reservation); }这里@Transactional注解是关键，它不是随便加的。冲突检查和插入必须在一个事务里，否则两个并发请求可能同时通过检查再同时插入，最终撞车。用事务把两个操作绑在一起，配合MySQL默认的RR隔离级别，第二个事务会阻塞到第一个事务提交后再执行检查，从而发现冲突。讲清楚这个原理，就是答辩里的一个亮点。
第二个是Mapper里的重叠查询SQL，用MyBatis注解方式写是这样：
@Select("<script>" + "SELECT COUNT(*) FROM t_reservation " + "WHERE venue_id = #{venueId} " + "AND reservation_date = #{date} " + "AND status IN (0, 1) " + "AND start_time < #{endTime} " + "AND end_time > #{startTime}" + "</script>") int countConflict(@Param("venueId") Long venueId, @Param("date") LocalDate date, @Param("startTime") LocalTime startTime, @Param("endTime") LocalTime endTime);注意XML里小于号和大于号要转义，<写成<，>写成>，不然XML解析直接报错。这个坑我见过不止一次，很多同学复制SQL报错后一脸懵，其实就是符号转义问题。
5.3 前端对接与文档写作要点
前端如果用了Vue，接口请求统一放一个request.js封装axios，加上请求拦截器携带Session或Token，响应拦截器统一处理Result结构。页面方面建议优先做这几个：企业端的场地列表页、可预约时段选择页、活动规划编辑页，管理端的审核列表页、场地管理页、排期日历页。把核心流程页面做完比做十个打杂页面强。
选场地时的“可预约时段”展示，需要后端提供一个接口：传入场地ID和日期，返回这一天内该场地的已预约时段列表，前端把已占用的时段置灰不可选。这个体验很直观，而且后端逻辑简单——查t_reservation里状态为0和1且日期匹配的记录，返回起止时间。顺便还能计算已占时长，展示给运营看。
文档写作有个容易被忽视的点：数据库设计章节一定要把E-R图、表结构说明、字段含义写清楚。哪怕你系统功能写得一般，数据库设计论述充分，分数也不会低。流程相关章节配上文字版的状态流转说明，比如“待审核→通过/拒绝，通过→取消/完成，拒绝/取消后时段自动释放”，这段文字既是业务梳理，也是答辩提纲。
6. 常见问题与避坑速查
6.1 环境与构建问题
下面这些坑，基本每个做SpringBoot课设的人都会碰到至少一个。
| 现象 | 主要原因 | 解决方案 |
|---|---|---|
启动报Failed to configure a DataSource | 数据库连接信息未配置或配置错 | 检查application.yml的URL、账号密码 |
| 报时区异常或中文乱码 | URL缺serverTimezone=Asia/Shanghai、字符集不一致 | 补时区参数，统一UTF-8 |
| Maven依赖下载慢或失败 | 未配置国内镜像 | settings.xml配置阿里云镜像maven.aliyun.com |
| 端口8080被占用 | 本机其他服务占用 | 改server.port或关闭占用程序 |
| 前端打包后接口404 | 前后端分离部署跨域/路径错 | 配置CORS，或把前端dist放进SpringBoot静态目录 |
| 实体字段值为null | 下划线字段未映射驼峰属性 | 开启map-underscore-to-camel-case或写@Results |
端口占用是最常见的启动失败原因，排查时先看控制台最后的异常信息：如果是Port 8080 was already in use，直接换端口或者netstat -ano | findstr 8080找到进程杀掉。这个操作很简单，但能让你在演示现场不慌。
6.2 业务逻辑与数据问题
代码层面容易出问题的点，往往是逻辑不严密而不是语法错误。
第一个是预约冲突判断失效。常见原因有三：没放在事务里、状态条件没过滤、时间比较用了字符串导致格式不一致。时间字段统一用LocalDate和LocalTime，不要用String存日期时间，否则排序和比较都会出问题。
第二个是状态流转不可控。比如已拒绝的订单还能被取消，已完成的活动还能被编辑。解决办法是写状态校验工具方法，在每次更新前检查当前状态是否允许目标操作，不允许就抛异常。这个校验逻辑集中放在Service里，任何入口都走同一套代码，就不会漏。
第三个是级联数据问题。删除场地时如果该场地已有预约记录，系统要么报错要么产生孤儿数据。我的处理是删除前检查是否存在未完成的预约，存在则拒绝删除并提示。活动主表删除时，要同时删除其明细项，这个操作放在一个事务里，否则明细残留会导致前端时间轴出现空行。
第四个是日期选择边界问题。前端显示可预约时段，如果已经开始的时间段没置灰，用户可能选了无法执行的时间。后端校验时建议加上“开始时间必须晚于当前时间”的判断，同时限制只能预约未来7天或30天内的日期，这样排期数据也更干净。
6.3 编码规范与答辩准备
代码规范这件事，平时不注意，答辩前突击改代码最痛苦。我建议从一开始就养成几个习惯：接口路径用REST风格，比如GET /api/venue/list、POST /api/reservation、PUT /api/reservation/{id}/audit；状态码用枚举而不是散落的魔法数字；业务异常统一抛BizException再全局捕获。这些细节看着不起眼，但代码走查时能加不少印象分。
答辩准备时，提前把三个问题背熟：为什么用SpringBoot？预约冲突怎么防止？活动规划和普通预约系统的区别是什么？能用自己的话讲清楚这三点，再配合实际操作演示，基本就稳了。
7. 一些实际操作中积累的经验
再做这类“预约+规划”系统的同学，有几个点可以提前注意。
第一，把“场地可预约时段”和“预约记录”这两个概念分开建模，不要想当然地给场地表加一个“是否可预约”的字段。场地是静态资源，预约是动态状态，两者解耦后，新增场地类型、调整开放时间都会容易很多。
第二，活动规划的明细最好一开始就设计好排序字段，不要偷懒省略。等活动环节多了，前端要调顺序、打印流程表、导出执行单，没有sort_order字段会非常痛苦。
第三，测试数据一定要贴近真实业务。别造“测试场地1”“测试场地2”，最好用“云栖多功能会议厅”“青野户外草坪拓展区”“听风营地餐厅”这种命名。答辩时演示页面，评委看到有真实感的场景数据，比你空跑一个“hello world”强太多。日期也尽量用近期可预约的日期，避免演示当天因为日期已经过期选不了时段，现场翻车。
第四，做完核心功能后，给自己留两天的缓冲时间做演示彩排。课程设计翻车率最高的环节不是写代码，而是现场演示时数据库没启动、前端忘了build、脚本执行报错。把这些流程提前跑通，才算是真的完成这个项目。
