尧图网页设计 
简介这份资源是基于SSM框架的体育场地预约系统完整毕业设计项目面向计算机相关专业需要完成毕业设计、课程设计或期末大作业的本科与专科学生尤其适合正在寻找可运行、可参考的Java Web实战项目的开发者。压缩包共包含1155个文件整体约18.69MB其中以html、css、js等前端页面与样式脚本为主配合jsp视图、java后端源码、jar依赖包以及png、gif、jpg等图片素材和sql数据库脚本、xml配置文件构成一套结构完整的前后端分离式预约管理项目。项目围绕体育场地的查询、预约、订单管理与后台维护等核心业务展开涵盖用户管理、场地信息维护、预约时段控制等典型模块能帮助读者理解SSM整合开发流程、数据库表设计与页面交互实现。目前已有41人学习下载适合作为毕业设计选题参考或课程设计模板读者可据此快速搭建运行环境、梳理功能模块划分并在此基础上进行二次开发与功能扩展。1. 体育场地预约系统为什么总在“并发抢场”上翻车体育场地预约系统说白了就是把线下“打电话占场”搬到线上用户选日期、选时段、提交订单管理员审核或自动确认后台把场地状态锁死。SSMSpring SpringMVC MyBatis是这类毕业设计里最稳的技术底座资料多、上手快、答辩时老师也认。但真正让系统“能用”和“能看”的分水岭不在页面多漂亮而在同一时段被两个人同时提交时系统会不会把同一块场地卖两次。我见过太多基于 SSM 的体育场地预约系统功能列表写得满满当当一到演示环节开两个浏览器同时点“预约”数据库里就出现两条重叠订单。这不是小 bug这是业务逻辑的根。这篇笔记就围绕这个标题把 SSM 环境下从建表、锁场、下单到后台审核的完整落地路径拆开讲顺带把毕业设计里最容易踩的坑一次说清。适合正在做计算机毕业设计、软件工程毕业设计或者想拿一个 SSM 项目练手的同学。2. 先定表结构场地、时段、订单三张表怎么切2.1 为什么不能把“时段”直接塞进场地表很多同学第一反应是建一张venue表里面放time_slot字段用逗号分隔“08:00-09:00,09:00-10:00”。这种设计在查询“某天某时段还有没有空场”时只能靠LIKE模糊匹配既走不了索引也没法做唯一约束。一旦并发上来数据库层面根本拦不住重复预约。我一般会把模型拆成三层场地venue、时段模板time_slot、预约订单reservation。时段模板定义一天有哪些可预约的段比如 08:00-09:00、09:00-10:00每个段有固定 ID。订单表里存venue_id slot_id reserve_date并对这三个字段建唯一索引。这样即使应用层锁没做好数据库也会在插入重复记录时直接报错相当于给系统上了最后一道保险。-- 场地表 CREATE TABLE venue ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, type VARCHAR(32) COMMENT 篮球/羽毛球/网球, price DECIMAL(10,2), status TINYINT DEFAULT 1 COMMENT 1可用 0维护 ); -- 时段模板表 CREATE TABLE time_slot ( id INT PRIMARY KEY AUTO_INCREMENT, start_time TIME NOT NULL, end_time TIME NOT NULL ); -- 预约订单表 CREATE TABLE reservation ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, venue_id INT NOT NULL, slot_id INT NOT NULL, reserve_date DATE NOT NULL, status TINYINT DEFAULT 0 COMMENT 0待审核 1已确认 2已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_venue_slot_date (venue_id, slot_id, reserve_date) );唯一索引uk_venue_slot_date是核心。注意它只对“有效订单”生效如果用户取消后状态改成 2这条记录还在表里会挡住别人预约。常见做法是取消时把记录移到历史表或者把唯一索引改成包含status的条件索引——但 MySQL 不支持部分索引所以更稳的方案是取消即物理删除或者用status参与唯一键但只对 0 和 1 生效这需要应用层保证。我一般直接物理删除取消订单简单可靠。2.2 日期和时段怎么组合成可预约单元用户看到的界面是“选场地 → 选日期 → 选时段”后端需要把venue_id、reserve_date、slot_id组合成一个可预约单元。查询某天某场地已被占用的时段SQL 这样写SELECT slot_id FROM reservation WHERE venue_id #{venueId} AND reserve_date #{reserveDate} AND status IN (0, 1);前端拿到已占用列表后把对应时段置灰。这里有个细节待审核status0的订单也要算占用否则一个人提交后还没审核另一个人又能选同一时段审核时就会冲突。很多系统在这里翻车就是因为只把 status1 当作占用。提示如果业务允许“待审核超时自动释放”需要加定时任务把超时未审核的订单状态改成取消并删除否则场地会被永久锁死。3. 用 SSM 跑通预约主流程从 Controller 到 Service 的锁场逻辑3.1 环境依赖与最小配置SSM 项目常见用 Maven 管理依赖核心就三块Spring 的spring-context、spring-txSpringMVC 的spring-webmvcMyBatis 的mybatis和mybatis-spring。数据库连接池用 Druid 或 HikariCP 都行我一般用 Druid监控页面在答辩时是个加分项。!-- pom.xml 关键依赖 -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.x/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.x/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.x/version /dependency版本号按你本地仓库实际有的选不必追新。Spring 5.3 和 MyBatis 3.5 搭配最稳网上教程也最多。spring-mybatis.xml里配好dataSource、sqlSessionFactory、mapperScannerConfigurerspring-mvc.xml里开注解驱动和静态资源映射这些是标准动作不展开。3.2 Service 层怎么防止同一时段被重复预约这是整个系统最关键的十几行代码。核心思路先查后插在并发下不可靠必须靠数据库唯一约束兜底同时用事务保证订单和状态一致。Service public class ReservationServiceImpl implements ReservationService { Autowired private ReservationMapper reservationMapper; Override Transactional(rollbackFor Exception.class) public Result reserve(ReservationDTO dto) { // 1. 先查是否已被占用快速失败减少无谓插入 int count reservationMapper.countOccupied( dto.getVenueId(), dto.getSlotId(), dto.getReserveDate()); if (count 0) { return Result.fail(该时段已被预约); } // 2. 插入订单依赖唯一索引兜底 try { Reservation r new Reservation(); r.setUserId(dto.getUserId()); r.setVenueId(dto.getVenueId()); r.setSlotId(dto.getSlotId()); r.setReserveDate(dto.getReserveDate()); r.setStatus(0); reservationMapper.insert(r); return Result.ok(预约成功等待审核); } catch (DuplicateKeyException e) { // 唯一索引冲突说明并发下被别人抢先 return Result.fail(手慢了该时段刚被预约); } } }countOccupied对应 SQL 就是上面那条查status IN (0,1)的语句。Transactional保证插入失败时事务回滚。DuplicateKeyException是 Spring 对SQLIntegrityConstraintViolationException的转译捕获它就能把并发冲突转成友好提示。参数说明venueId、slotId、reserveDate三个参数必须来自前端且做非空校验userId从 session 取不能信前端传的。status初始为 0表示待审核。3.3 Controller 层参数接收与返回格式Controller 只做参数校验和调用 Service不写业务逻辑。用RestController返回 JSON前端用 Ajax 提交。RestController RequestMapping(/api/reservation) public class ReservationController { Autowired private ReservationService reservationService; PostMapping(/create) public Result create(RequestBody ReservationDTO dto, HttpSession session) { User user (User) session.getAttribute(loginUser); if (user null) { return Result.fail(请先登录); } dto.setUserId(user.getId()); if (dto.getVenueId() null || dto.getSlotId() null || dto.getReserveDate() null) { return Result.fail(参数不完整); } return reservationService.reserve(dto); } }ReservationDTO里放userId、venueId、slotId、reserveDate四个字段reserveDate用JsonFormat(pattern yyyy-MM-dd)做日期绑定。返回的Result统一包含code、msg、data前端根据code判断成功失败。注意不要用RequestParam逐个接参数字段一多容易漏用 DTO 整体接收配合Valid做校验更规范。4. 后台审核与状态流转别让“待审核”变成永久锁4.1 审核通过和驳回分别改什么管理员在后台看到待审核列表点“通过”把status改成 1点“驳回”把记录删掉或改成 2 并释放时段。这里有个设计选择驳回后是保留记录还是删除如果保留且status2唯一索引仍然占着位置别人无法预约。所以驳回必须删除记录或者把唯一索引设计成只对status IN (0,1)生效——MySQL 做不到只能应用层在驳回时执行DELETE。Transactional public Result audit(Integer reservationId, boolean pass) { Reservation r reservationMapper.selectById(reservationId); if (r null || r.getStatus() ! 0) { return Result.fail(订单状态异常); } if (pass) { r.setStatus(1); reservationMapper.updateStatus(r); } else { reservationMapper.deleteById(reservationId); } return Result.ok(pass ? 已通过 : 已驳回); }审核通过后用户端看到订单状态变为“已确认”驳回后订单消失时段重新可约。这里的状态机很简单但一定要在 Service 层加status ! 0的判断防止重复审核。4.2 用户取消预约怎么释放时段用户取消自己的待审核或已确认订单同样要删除记录释放时段。但已确认的订单取消可能涉及退款或信用扣分毕业设计里简化处理即可直接删除状态不保留。Transactional public Result cancel(Integer reservationId, Integer userId) { Reservation r reservationMapper.selectById(reservationId); if (r null || !r.getUserId().equals(userId)) { return Result.fail(无权操作); } if (r.getStatus() 1) { // 已确认订单取消实际项目可能要退款这里直接删 reservationMapper.deleteById(reservationId); } else { reservationMapper.deleteById(reservationId); } return Result.ok(已取消); }两个分支代码一样是因为毕业设计里不做退款逻辑。如果要做就在status1分支里加一条退款记录再把订单状态改成 2 并保留——但那样唯一索引会挡住时段所以退款完成后仍需删除或把venue_id置空。我一般建议直接删除简单且不会出并发问题。5. 避坑与排查体育场地预约系统最常见的 5 个翻车点5.1 现象两个用户同时提交都提示“预约成功”原因Service 层只做了count查询没有唯一索引或者唯一索引建了但插入时没触发。并发下两个线程都查到 count0然后都插入成功。解决确认reservation表有UNIQUE KEY uk_venue_slot_date (venue_id, slot_id, reserve_date)并且插入时捕获DuplicateKeyException。可以用 JMeter 开 10 个线程同时打同一个接口验证看是否只有一个成功。5.2 现象用户取消后时段仍然显示“已占用”原因取消操作只改了status2没有删除记录唯一索引和查询都把 status2 算作占用。解决取消即DELETE或者查询已占用时加status IN (0,1)条件同时唯一索引改为包含status并只对 0、1 生效——MySQL 不支持所以还是删除最稳。5.3 现象待审核订单一直不处理场地被锁死原因没有超时释放机制用户提交后不审核也不取消时段永久占用。解决加定时任务每小时扫描create_time超过 30 分钟且status0的订单自动删除。用 Spring 的Scheduled注解即可。Scheduled(cron 0 0/30 * * * ?) public void releaseTimeoutOrders() { reservationMapper.deleteTimeout(30); }对应 SQLDELETE FROM reservation WHERE status 0 AND create_time DATE_SUB(NOW(), INTERVAL #{minutes} MINUTE)。5.4 现象日期格式前端传2025-01-01后端报类型转换错误原因ReservationDTO里的reserveDate是java.util.Date没有加JsonFormatJackson 默认按时间戳解析。解决加JsonFormat(pattern yyyy-MM-dd, timezone GMT8)或者把字段类型改成java.time.LocalDate并注册JavaTimeModule。5.5 现象MyBatis 插入后返回的主键是 null原因insert语句没有配useGeneratedKeystrue keyPropertyid。解决在 Mapper XML 的insert标签上加这两个属性或者用注解Options(useGeneratedKeys true, keyProperty id)。否则后续要用订单 ID 做审核时拿不到值。6. 用 JMeter 压测验证锁场效果以及一个我常留的“后悔药”6.1 压测脚本怎么配验证并发锁场最直接的办法是用 JMeter 开线程组模拟 20 个用户同时预约同一场地同一时段。配置如下元件配置项值线程组线程数20线程组Ramp-Up1 秒HTTP 请求方法POSTHTTP 请求路径/api/reservation/createHTTP 请求Body{venueId:1,slotId:1,reserveDate:2025-06-01}HTTP 信息头Content-Typeapplication/json监听器聚合报告查看成功/失败数预期结果只有 1 个请求返回“预约成功”其余 19 个返回“手慢了”或“该时段已被预约”。如果成功数大于 1说明锁场失败回去检查唯一索引和异常捕获。6.2 一个我常留的“后悔药”订单操作日志表毕业设计答辩时老师常问“如果用户说预约成功了但后台没记录怎么办”。我一般会加一张reservation_log表记录每次预约请求的user_id、venue_id、slot_id、reserve_date、request_time、result成功/失败/异常。这张表不参与业务只做追溯。CREATE TABLE reservation_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT, venue_id INT, slot_id INT, reserve_date DATE, result VARCHAR(32), request_time DATETIME DEFAULT CURRENT_TIMESTAMP );在 Service 的reserve方法入口和出口各插一条日志或者用 AOP 切面统一记录。这样即使线上出问题也能查到“谁在什么时候抢了哪个场”。答辩时展示这张表比空口说“我做了并发控制”有说服力得多。6.3 最后一句实在话做体育场地预约系统页面可以简单但锁场逻辑和唯一索引必须一次做对。我见过太多项目在演示时翻车就是因为把并发当儿戏。把上面那套表结构、Service 锁场、JMeter 压测跑一遍你的毕业设计至少在后端逻辑上站得住。希望帮到你。本文还有配套的精品资源点击获取 SSM体育场地预约系统并发锁场实战：从表结构到JMeter压测
简介这份资源是基于SSM框架的体育场地预约系统完整毕业设计项目面向计算机相关专业需要完成毕业设计、课程设计或期末大作业的本科与专科学生尤其适合正在寻找可运行、可参考的Java Web实战项目的开发者。压缩包共包含1155个文件整体约18.69MB其中以html、css、js等前端页面与样式脚本为主配合jsp视图、java后端源码、jar依赖包以及png、gif、jpg等图片素材和sql数据库脚本、xml配置文件构成一套结构完整的前后端分离式预约管理项目。项目围绕体育场地的查询、预约、订单管理与后台维护等核心业务展开涵盖用户管理、场地信息维护、预约时段控制等典型模块能帮助读者理解SSM整合开发流程、数据库表设计与页面交互实现。目前已有41人学习下载适合作为毕业设计选题参考或课程设计模板读者可据此快速搭建运行环境、梳理功能模块划分并在此基础上进行二次开发与功能扩展。1. 体育场地预约系统为什么总在“并发抢场”上翻车体育场地预约系统说白了就是把线下“打电话占场”搬到线上用户选日期、选时段、提交订单管理员审核或自动确认后台把场地状态锁死。SSMSpring SpringMVC MyBatis是这类毕业设计里最稳的技术底座资料多、上手快、答辩时老师也认。但真正让系统“能用”和“能看”的分水岭不在页面多漂亮而在同一时段被两个人同时提交时系统会不会把同一块场地卖两次。我见过太多基于 SSM 的体育场地预约系统功能列表写得满满当当一到演示环节开两个浏览器同时点“预约”数据库里就出现两条重叠订单。这不是小 bug这是业务逻辑的根。这篇笔记就围绕这个标题把 SSM 环境下从建表、锁场、下单到后台审核的完整落地路径拆开讲顺带把毕业设计里最容易踩的坑一次说清。适合正在做计算机毕业设计、软件工程毕业设计或者想拿一个 SSM 项目练手的同学。2. 先定表结构场地、时段、订单三张表怎么切2.1 为什么不能把“时段”直接塞进场地表很多同学第一反应是建一张venue表里面放time_slot字段用逗号分隔“08:00-09:00,09:00-10:00”。这种设计在查询“某天某时段还有没有空场”时只能靠LIKE模糊匹配既走不了索引也没法做唯一约束。一旦并发上来数据库层面根本拦不住重复预约。我一般会把模型拆成三层场地venue、时段模板time_slot、预约订单reservation。时段模板定义一天有哪些可预约的段比如 08:00-09:00、09:00-10:00每个段有固定 ID。订单表里存venue_id slot_id reserve_date并对这三个字段建唯一索引。这样即使应用层锁没做好数据库也会在插入重复记录时直接报错相当于给系统上了最后一道保险。-- 场地表 CREATE TABLE venue ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, type VARCHAR(32) COMMENT 篮球/羽毛球/网球, price DECIMAL(10,2), status TINYINT DEFAULT 1 COMMENT 1可用 0维护 ); -- 时段模板表 CREATE TABLE time_slot ( id INT PRIMARY KEY AUTO_INCREMENT, start_time TIME NOT NULL, end_time TIME NOT NULL ); -- 预约订单表 CREATE TABLE reservation ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, venue_id INT NOT NULL, slot_id INT NOT NULL, reserve_date DATE NOT NULL, status TINYINT DEFAULT 0 COMMENT 0待审核 1已确认 2已取消, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_venue_slot_date (venue_id, slot_id, reserve_date) );唯一索引uk_venue_slot_date是核心。注意它只对“有效订单”生效如果用户取消后状态改成 2这条记录还在表里会挡住别人预约。常见做法是取消时把记录移到历史表或者把唯一索引改成包含status的条件索引——但 MySQL 不支持部分索引所以更稳的方案是取消即物理删除或者用status参与唯一键但只对 0 和 1 生效这需要应用层保证。我一般直接物理删除取消订单简单可靠。2.2 日期和时段怎么组合成可预约单元用户看到的界面是“选场地 → 选日期 → 选时段”后端需要把venue_id、reserve_date、slot_id组合成一个可预约单元。查询某天某场地已被占用的时段SQL 这样写SELECT slot_id FROM reservation WHERE venue_id #{venueId} AND reserve_date #{reserveDate} AND status IN (0, 1);前端拿到已占用列表后把对应时段置灰。这里有个细节待审核status0的订单也要算占用否则一个人提交后还没审核另一个人又能选同一时段审核时就会冲突。很多系统在这里翻车就是因为只把 status1 当作占用。提示如果业务允许“待审核超时自动释放”需要加定时任务把超时未审核的订单状态改成取消并删除否则场地会被永久锁死。3. 用 SSM 跑通预约主流程从 Controller 到 Service 的锁场逻辑3.1 环境依赖与最小配置SSM 项目常见用 Maven 管理依赖核心就三块Spring 的spring-context、spring-txSpringMVC 的spring-webmvcMyBatis 的mybatis和mybatis-spring。数据库连接池用 Druid 或 HikariCP 都行我一般用 Druid监控页面在答辩时是个加分项。!-- pom.xml 关键依赖 -- dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version5.3.x/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.x/version /dependency dependency groupIdcom.alibaba/groupId artifactIddruid/artifactId version1.2.x/version /dependency版本号按你本地仓库实际有的选不必追新。Spring 5.3 和 MyBatis 3.5 搭配最稳网上教程也最多。spring-mybatis.xml里配好dataSource、sqlSessionFactory、mapperScannerConfigurerspring-mvc.xml里开注解驱动和静态资源映射这些是标准动作不展开。3.2 Service 层怎么防止同一时段被重复预约这是整个系统最关键的十几行代码。核心思路先查后插在并发下不可靠必须靠数据库唯一约束兜底同时用事务保证订单和状态一致。Service public class ReservationServiceImpl implements ReservationService { Autowired private ReservationMapper reservationMapper; Override Transactional(rollbackFor Exception.class) public Result reserve(ReservationDTO dto) { // 1. 先查是否已被占用快速失败减少无谓插入 int count reservationMapper.countOccupied( dto.getVenueId(), dto.getSlotId(), dto.getReserveDate()); if (count 0) { return Result.fail(该时段已被预约); } // 2. 插入订单依赖唯一索引兜底 try { Reservation r new Reservation(); r.setUserId(dto.getUserId()); r.setVenueId(dto.getVenueId()); r.setSlotId(dto.getSlotId()); r.setReserveDate(dto.getReserveDate()); r.setStatus(0); reservationMapper.insert(r); return Result.ok(预约成功等待审核); } catch (DuplicateKeyException e) { // 唯一索引冲突说明并发下被别人抢先 return Result.fail(手慢了该时段刚被预约); } } }countOccupied对应 SQL 就是上面那条查status IN (0,1)的语句。Transactional保证插入失败时事务回滚。DuplicateKeyException是 Spring 对SQLIntegrityConstraintViolationException的转译捕获它就能把并发冲突转成友好提示。参数说明venueId、slotId、reserveDate三个参数必须来自前端且做非空校验userId从 session 取不能信前端传的。status初始为 0表示待审核。3.3 Controller 层参数接收与返回格式Controller 只做参数校验和调用 Service不写业务逻辑。用RestController返回 JSON前端用 Ajax 提交。RestController RequestMapping(/api/reservation) public class ReservationController { Autowired private ReservationService reservationService; PostMapping(/create) public Result create(RequestBody ReservationDTO dto, HttpSession session) { User user (User) session.getAttribute(loginUser); if (user null) { return Result.fail(请先登录); } dto.setUserId(user.getId()); if (dto.getVenueId() null || dto.getSlotId() null || dto.getReserveDate() null) { return Result.fail(参数不完整); } return reservationService.reserve(dto); } }ReservationDTO里放userId、venueId、slotId、reserveDate四个字段reserveDate用JsonFormat(pattern yyyy-MM-dd)做日期绑定。返回的Result统一包含code、msg、data前端根据code判断成功失败。注意不要用RequestParam逐个接参数字段一多容易漏用 DTO 整体接收配合Valid做校验更规范。4. 后台审核与状态流转别让“待审核”变成永久锁4.1 审核通过和驳回分别改什么管理员在后台看到待审核列表点“通过”把status改成 1点“驳回”把记录删掉或改成 2 并释放时段。这里有个设计选择驳回后是保留记录还是删除如果保留且status2唯一索引仍然占着位置别人无法预约。所以驳回必须删除记录或者把唯一索引设计成只对status IN (0,1)生效——MySQL 做不到只能应用层在驳回时执行DELETE。Transactional public Result audit(Integer reservationId, boolean pass) { Reservation r reservationMapper.selectById(reservationId); if (r null || r.getStatus() ! 0) { return Result.fail(订单状态异常); } if (pass) { r.setStatus(1); reservationMapper.updateStatus(r); } else { reservationMapper.deleteById(reservationId); } return Result.ok(pass ? 已通过 : 已驳回); }审核通过后用户端看到订单状态变为“已确认”驳回后订单消失时段重新可约。这里的状态机很简单但一定要在 Service 层加status ! 0的判断防止重复审核。4.2 用户取消预约怎么释放时段用户取消自己的待审核或已确认订单同样要删除记录释放时段。但已确认的订单取消可能涉及退款或信用扣分毕业设计里简化处理即可直接删除状态不保留。Transactional public Result cancel(Integer reservationId, Integer userId) { Reservation r reservationMapper.selectById(reservationId); if (r null || !r.getUserId().equals(userId)) { return Result.fail(无权操作); } if (r.getStatus() 1) { // 已确认订单取消实际项目可能要退款这里直接删 reservationMapper.deleteById(reservationId); } else { reservationMapper.deleteById(reservationId); } return Result.ok(已取消); }两个分支代码一样是因为毕业设计里不做退款逻辑。如果要做就在status1分支里加一条退款记录再把订单状态改成 2 并保留——但那样唯一索引会挡住时段所以退款完成后仍需删除或把venue_id置空。我一般建议直接删除简单且不会出并发问题。5. 避坑与排查体育场地预约系统最常见的 5 个翻车点5.1 现象两个用户同时提交都提示“预约成功”原因Service 层只做了count查询没有唯一索引或者唯一索引建了但插入时没触发。并发下两个线程都查到 count0然后都插入成功。解决确认reservation表有UNIQUE KEY uk_venue_slot_date (venue_id, slot_id, reserve_date)并且插入时捕获DuplicateKeyException。可以用 JMeter 开 10 个线程同时打同一个接口验证看是否只有一个成功。5.2 现象用户取消后时段仍然显示“已占用”原因取消操作只改了status2没有删除记录唯一索引和查询都把 status2 算作占用。解决取消即DELETE或者查询已占用时加status IN (0,1)条件同时唯一索引改为包含status并只对 0、1 生效——MySQL 不支持所以还是删除最稳。5.3 现象待审核订单一直不处理场地被锁死原因没有超时释放机制用户提交后不审核也不取消时段永久占用。解决加定时任务每小时扫描create_time超过 30 分钟且status0的订单自动删除。用 Spring 的Scheduled注解即可。Scheduled(cron 0 0/30 * * * ?) public void releaseTimeoutOrders() { reservationMapper.deleteTimeout(30); }对应 SQLDELETE FROM reservation WHERE status 0 AND create_time DATE_SUB(NOW(), INTERVAL #{minutes} MINUTE)。5.4 现象日期格式前端传2025-01-01后端报类型转换错误原因ReservationDTO里的reserveDate是java.util.Date没有加JsonFormatJackson 默认按时间戳解析。解决加JsonFormat(pattern yyyy-MM-dd, timezone GMT8)或者把字段类型改成java.time.LocalDate并注册JavaTimeModule。5.5 现象MyBatis 插入后返回的主键是 null原因insert语句没有配useGeneratedKeystrue keyPropertyid。解决在 Mapper XML 的insert标签上加这两个属性或者用注解Options(useGeneratedKeys true, keyProperty id)。否则后续要用订单 ID 做审核时拿不到值。6. 用 JMeter 压测验证锁场效果以及一个我常留的“后悔药”6.1 压测脚本怎么配验证并发锁场最直接的办法是用 JMeter 开线程组模拟 20 个用户同时预约同一场地同一时段。配置如下元件配置项值线程组线程数20线程组Ramp-Up1 秒HTTP 请求方法POSTHTTP 请求路径/api/reservation/createHTTP 请求Body{venueId:1,slotId:1,reserveDate:2025-06-01}HTTP 信息头Content-Typeapplication/json监听器聚合报告查看成功/失败数预期结果只有 1 个请求返回“预约成功”其余 19 个返回“手慢了”或“该时段已被预约”。如果成功数大于 1说明锁场失败回去检查唯一索引和异常捕获。6.2 一个我常留的“后悔药”订单操作日志表毕业设计答辩时老师常问“如果用户说预约成功了但后台没记录怎么办”。我一般会加一张reservation_log表记录每次预约请求的user_id、venue_id、slot_id、reserve_date、request_time、result成功/失败/异常。这张表不参与业务只做追溯。CREATE TABLE reservation_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id INT, venue_id INT, slot_id INT, reserve_date DATE, result VARCHAR(32), request_time DATETIME DEFAULT CURRENT_TIMESTAMP );在 Service 的reserve方法入口和出口各插一条日志或者用 AOP 切面统一记录。这样即使线上出问题也能查到“谁在什么时候抢了哪个场”。答辩时展示这张表比空口说“我做了并发控制”有说服力得多。6.3 最后一句实在话做体育场地预约系统页面可以简单但锁场逻辑和唯一索引必须一次做对。我见过太多项目在演示时翻车就是因为把并发当儿戏。把上面那套表结构、Service 锁场、JMeter 压测跑一遍你的毕业设计至少在后端逻辑上站得住。希望帮到你。本文还有配套的精品资源点击获取