尧图网页设计 
简介这份资源是基于SSMSpring、SpringMVC、MyBatis框架开发的实验室设备预约系统完整设计包面向高校计算机相关专业的毕业设计、课程设计与期末大作业场景帮助解决传统实验室设备预约效率低、易出错、难管理的问题。压缩包共1166个文件约18.63MB涵盖51个Java源码、31个JSP页面、42个Jar依赖、1个SQL脚本及18个XML配置另有256个HTML、227个CSS、186个JS与大量PNG、GIF等前端静态资源完整呈现前后端分离的项目结构。系统以MySQL存储预约数据、用户与设备信息支持用户在线预约与管理员统一管理并遵循需求分析、系统设计、编码实现、系统测试的软件工程流程。目前已有43人学习下载适合需要参考SSM整合配置、数据库表设计与预约业务逻辑实现的读者可据此快速理解项目分层、复用代码并完成自己的设计任务。1. 从一台被预约到冒烟的示波器说起SSM 实验室设备预约系统到底在解决什么实验室里最贵的不是那台矢量网络分析仪而是没人说得清它今天下午到底谁在用。我见过一个电子实验室三台示波器、两台频谱仪管理员用 Excel 排班结果一周内撞车四次有研究生白跑两趟。后来他们上了套基于 SSM 的实验室设备预约系统冲突率直接归零。这套系统说白了就干三件事把设备台账数字化、把时间段锁死、把审批流程串起来。SSM 是 Spring SpringMVC MyBatis 的组合国内高校课程设计和中小型管理系统里最常见的技术栈上手快、资料多、答辩好讲。它适合谁适合要交课程设计的学生、要给实验室做内部工具的老师以及想用一套完整 CRUD 项目练手 SSM 常用注解的开发者。这篇笔记不讲空话从表结构到冲突检测 SQL从 MyBatis 映射到部署踩坑全部按能复现的标准写。2. 表结构与冲突检测预约系统真正的技术核心在哪很多人以为预约系统难在界面其实难在数据库设计。设备、用户、预约记录三张表怎么关联时间段怎么存冲突怎么判这些定错了后面全是坑。这一章把地基打牢后面写代码才不会返工。2.1 四张核心表与字段设计一个能用的实验室设备预约系统最少需要四张表用户表、设备表、预约记录表、审批日志表。用户表存账号密码和角色学生/管理员设备表存设备编号、名称、状态、所属实验室预约记录表是核心审批日志表用来追溯谁在什么时候批了哪条申请。预约记录表的关键字段设计如下字段名类型说明idBIGINT主键自增user_idBIGINT预约人外键关联用户表device_idBIGINT设备 ID外键关联设备表start_timeDATETIME预约开始时间end_timeDATETIME预约结束时间statusTINYINT0 待审批 1 已通过 2 已拒绝 3 已取消 4 已完成purposeVARCHAR(255)使用用途create_timeDATETIME提交时间这里有个设计决策时间段用两个 DATETIME 字段存而不是拆成日期加节次。拆节次看起来简单但一旦实验室开放时间调整节次映射全乱。用 DATETIME 存绝对时间冲突判断就是区间重叠问题逻辑清晰。设备表里要有一个 status 字段区分「可用」「维修中」「已停用」预约时先查设备状态再查时间冲突两层过滤。审批日志表至少要有 operator_id、action、target_id、remark、operate_time 五个字段答辩时老师问「怎么追溯审批记录」你能直接答上来。2.2 冲突检测 SQL一条语句判断时间段是否重叠时间段重叠的判定条件是新预约的开始时间小于已有预约的结束时间且新预约的结束时间大于已有预约的开始时间。这个条件覆盖了包含、相交、被包含三种情况。写成 MyBatis 的 XML 映射!-- 查询与指定时间段冲突的已通过预约数量 -- select idcountConflict resultTypeint SELECT COUNT(*) FROM reservation WHERE device_id #{deviceId} AND status 1 AND start_time lt; #{endTime} AND end_time gt; #{startTime} /select逻辑说明status 1只统计已通过的预约待审批的不算冲突否则两个人同时申请同一时段会互相阻塞。start_time endTime AND end_time startTime是标准的区间重叠判定注意 XML 里小于号要转义成lt;这是 MyBatis 新手最常翻车的地方。参数说明deviceId是设备主键startTime和endTime是用户提交的预约起止时间。返回值为 0 表示无冲突可以提交大于 0 则拒绝并提示用户换时间段。在 Service 层调用时还要加一层校验开始时间不能早于当前时间结束时间必须大于开始时间单次预约时长不超过 4 小时这个阈值按实验室规定改。这三条校验放在 Java 代码里做不要塞进 SQL否则报错信息不友好。2.3 用 SSM 常用注解搭出预约接口SSM 里 Spring 和 SpringMVC 的注解是日常写得最多的。Controller 层用RestController和RequestMappingService 层用Service和Transactional依赖注入用Autowired或Resource。下面是一个预约提交接口的骨架RestController RequestMapping(/api/reservation) public class ReservationController { Autowired private ReservationService reservationService; PostMapping(/submit) public Result submit(RequestBody ReservationDTO dto) { // 参数基础校验 if (dto.getStartTime().after(dto.getEndTime())) { return Result.fail(结束时间必须晚于开始时间); } // 调用 Service 层内部做冲突检测 return reservationService.createReservation(dto); } }逻辑说明Controller 只做参数格式校验和路由业务逻辑全部下沉到 Service。RequestBody接收 JSON 格式的请求体前端用 axios 或 fetch 提交时 Content-Type 要设为 application/json。参数说明ReservationDTO是数据传输对象包含 deviceId、startTime、endTime、purpose 四个字段。时间字段用JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解格式化否则前端传字符串会解析失败。Service 层的createReservation方法要加Transactional因为「检测冲突 插入记录」必须在一个事务里否则并发提交时两个请求可能同时通过冲突检测然后都插入成功。这是预约系统最隐蔽的坑后面避坑章节会展开。3. 从登录到审批把 SSM 各层串起来的最小可运行路径表设计好了接下来要把 Spring、SpringMVC、MyBatis 三层配置跑通。很多人的项目卡在「配置写了一堆但启动就报错」这一章按最小可运行路径走每一步都给出配置和验证方法。3.1 Spring 与 MyBatis 整合配置的四个关键点SSM 整合的核心是把 MyBatis 的 SqlSessionFactory 交给 Spring 管理。需要配的东西不少但关键就四个数据源、SqlSessionFactoryBean、MapperScannerConfigurer、事务管理器。!-- Spring 配置文件核心片段 -- bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName valuecom.mysql.cj.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/lab_device?useSSLfalseamp;serverTimezoneAsia/Shanghai/ property nameusername valueroot/ property namepassword valueyour_password/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ property nametypeAliasesPackage valuecom.lab.entity/ /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.lab.mapper/ /bean逻辑说明mapperLocations指定 XML 映射文件位置typeAliasesPackage让实体类可以用短名引用MapperScannerConfigurer自动扫描 Mapper 接口并生成代理对象省去逐个配置。参数说明数据库 URL 里的serverTimezoneAsia/Shanghai必须加否则 MySQL 8 会报时区错误。useSSLfalse在本地开发时加上避免警告。Druid 连接池的初始连接数和最大连接数用默认值就够实验室级别并发不高。验证方法写一个 JUnit 测试注入 Mapper 调一次查询能返回数据就说明整合成功。不要等前端写完再测那时候报错你分不清是配置问题还是代码问题。3.2 设备列表分页查询的 Mapper 与 Service 写法设备列表是使用频率最高的页面必须分页。MyBatis 分页有两种做法用 PageHelper 插件或者手写 limit。PageHelper 更省事但要注意版本兼容。Service public class DeviceServiceImpl implements DeviceService { Autowired private DeviceMapper deviceMapper; Override public PageInfoDevice listDevices(int pageNum, int pageSize, String keyword) { PageHelper.startPage(pageNum, pageSize); ListDevice list deviceMapper.selectByKeyword(keyword); return new PageInfo(list); } }逻辑说明PageHelper.startPage只对紧接着的第一条查询生效所以必须紧挨着 Mapper 调用。返回的PageInfo包含总记录数、总页数、当前页数据前端直接拿来渲染分页组件。参数说明pageNum从 1 开始pageSize建议 10 到 20太大前端渲染慢。keyword用于按设备名称模糊搜索Mapper XML 里用LIKE CONCAT(%, #{keyword}, %)。对应的 Mapper XMLselect idselectByKeyword resultTypecom.lab.entity.Device SELECT * FROM device where if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY id DESC /selectwhere标签会自动处理第一个 ANDif做条件拼接。这是 MyBatis 动态 SQL 最常用的组合答辩时被问到「怎么实现条件查询」直接说这个。3.3 审批流程的状态机与接口实现预约审批是一个典型的状态流转待审批 → 已通过 / 已拒绝已通过 → 已完成 / 已取消。状态不能乱跳比如已拒绝的不能直接改成已完成。在 Service 层用一个方法统一处理状态变更Transactional public Result approve(Long reservationId, Integer action, String remark) { Reservation r reservationMapper.selectById(reservationId); if (r null) { return Result.fail(预约记录不存在); } if (r.getStatus() ! 0) { return Result.fail(该预约已处理不能重复审批); } int newStatus (action 1) ? 1 : 2; reservationMapper.updateStatus(reservationId, newStatus); approvalLogMapper.insert(new ApprovalLog(reservationId, getCurrentUserId(), action, remark)); return Result.success(); }逻辑说明先查记录判断当前状态只有待审批status0的才能被审批。审批通过后同时写一条日志保证操作可追溯。Transactional确保状态更新和日志插入要么都成功要么都回滚。参数说明action为 1 表示通过2 表示拒绝。remark是审批意见拒绝时必填。getCurrentUserId()从 Session 或 Token 中获取当前登录用户 ID。这里有个容易忽略的点审批通过后要再次检查时间冲突。因为从提交到审批可能隔了几小时这期间可能有别的预约被批准了。所以approve方法里在更新状态前应该再调一次countConflict有冲突就拒绝并提示管理员。4. 避坑与排查SSM 预约系统上线前必须处理的五个问题这一章全是血泪经验。下面五个问题每一个我都见过真实项目翻车按「现象 → 原因 → 解决」写清楚。4.1 并发提交导致同一时段被重复预约现象两个学生几乎同时提交同一台设备同一时段的预约系统都提示成功管理员审批时发现两条冲突记录。原因冲突检测和插入记录之间存在时间窗口两个线程都通过了检测然后都执行了插入。这是典型的竞态条件。解决三个层面处理。第一Service 方法加Transactional并设置隔离级别为ISOLATION_REPEATABLE_READ。第二在 reservation 表上对(device_id, start_time, end_time)建唯一索引数据库层面兜底。第三如果并发量真的很小用synchronized关键字锁住 Service 方法也能扛但不推荐作为长期方案。4.2 MyBatis 时间字段映射报 Invalid value 异常现象提交预约时后台报Invalid value for getTimestamp()或时间差 8 小时。原因MySQL 驱动版本和时区配置不匹配或者实体类用了java.util.Date但数据库是DATETIME类型转换出问题。解决JDBC URL 加serverTimezoneAsia/Shanghai实体类时间字段统一用java.time.LocalDateTimeMyBatis 3.4.5 以上原生支持。如果必须用 Date在 Mapper XML 里显式指定jdbcTypeTIMESTAMP。4.3 前端传的时间格式后端解析失败现象前端用new Date()转成字符串提交后端报JSON parse error。原因JavaScript 的toISOString()输出的是2024-01-15T08:30:00.000Z格式带 T 和 ZSpringMVC 默认的日期解析器不认。解决前端提交前用 dayjs 或手动格式化成yyyy-MM-dd HH:mm:ss后端 DTO 字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)。两边格式约定死不要依赖自动推断。4.4 事务不生效导致审批状态更新了但日志没写现象审批操作后预约状态变了但审批日志表里没有对应记录。原因Transactional注解没生效。常见原因有三个方法不是 public、同类内部调用、Spring 配置没开tx:annotation-driven/。解决确认方法为 public把事务方法抽到独立的 Service 类里避免自调用检查 Spring 配置里有没有开启注解驱动事务。用TransactionSynchronizationManager.isActualTransactionActive()在方法里打印一下就能确认事务是否真的开了。4.5 部署到 Tomcat 后静态资源 404现象本地 IDEA 里跑得好好的打成 war 包丢到 Tomcat 后 CSS、JS 全部 404。原因SpringMVC 的 DispatcherServlet 拦截了所有请求包括静态资源。本地开发时 IDE 可能做了额外处理部署后暴露了问题。解决在 spring-mvc.xml 里加mvc:resources mapping/static/** location/static//和mvc:default-servlet-handler/。前者显式映射静态资源路径后者把未匹配的请求交回给 Tomcat 默认 Servlet 处理。两个都加上基本能覆盖所有情况。5. 让预约系统真正好用三个进阶技巧与验证方法基础功能跑通只是及格线。这一章讲三个让系统从「能用」到「好用」的技巧每个都附带验证方法你可以直接拿去改自己的项目。5.1 用定时任务自动完成过期预约已通过的预约如果过了结束时间还没人操作状态应该自动变成「已完成」。手动改不现实用 Spring 的Scheduled注解做定时任务Component public class ReservationScheduler { Autowired private ReservationMapper reservationMapper; // 每 30 分钟执行一次把已过期的已通过预约标记为已完成 Scheduled(cron 0 0/30 * * * ?) public void autoCompleteExpired() { int count reservationMapper.completeExpired(); if (count 0) { System.out.println(自动完成过期预约 count 条); } } }对应的 SQL 是UPDATE reservation SET status 4 WHERE status 1 AND end_time NOW()。逻辑说明只处理已通过且结束时间早于当前时间的记录改成已完成状态。参数说明cron 表达式0 0/30 * * * ?表示每 30 分钟的第 0 秒执行按需调整频率。验证方法手动改一条记录的 end_time 为过去时间等定时任务触发后查数据库看状态是否变成 4。注意要在 Spring 配置里加task:annotation-driven/否则Scheduled不生效。5.2 设备使用率统计的 SQL 与图表数据接口管理员最关心的数据是「哪台设备最忙、哪个时段最挤」。一条 SQL 就能算出来-- 统计每台设备近 30 天的预约总时长小时 SELECT d.name, ROUND(SUM(TIMESTAMPDIFF(MINUTE, r.start_time, r.end_time)) / 60, 1) AS total_hours FROM reservation r JOIN device d ON r.device_id d.id WHERE r.status IN (1, 4) AND r.start_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY d.id, d.name ORDER BY total_hours DESC;逻辑说明只统计已通过和已完成的预约用TIMESTAMPDIFF算每次预约的分钟数求和后除以 60 得到小时数。DATE_SUB(NOW(), INTERVAL 30 DAY)限定近 30 天。参数说明status IN (1, 4)排除待审批和已拒绝的记录。时间范围可以改成 7 天或 90 天按管理需求调整。后端把这个查询结果包装成 JSON 返回前端用 ECharts 渲染柱状图。验证方法手动插入几条不同设备的预约记录调接口看返回数据是否和手算一致。5.3 我踩过的坑与给你的建议最后说一个我自己的教训。早期做这套系统时我把冲突检测只放在前端做——用户选时间段时用 JavaScript 查一下有没有冲突。结果有人直接调接口绕过前端同一时段被约了三次。后来我把校验全部下沉到 Service 层前端只做体验优化后端做最终裁决。这个原则适用于所有管理系统前端校验是给用户看的后端校验是给数据看的两者都要有但后端才是最后一道防线。另一个习惯是每次改完 Mapper XML先跑单元测试再启动 Web 服务。MyBatis 的 XML 错误在启动时不一定报往往要等到实际调用才暴露提前测能省很多时间。这套 SSM 实验室设备预约系统不算复杂但把表设计、冲突检测、事务处理、状态流转这几块吃透后面做任何预约类、排班类系统都是同一套思路。希望帮到你。本文还有配套的精品资源点击获取 SSM实验室设备预约系统实战：表结构、冲突检测与避坑指南
简介这份资源是基于SSMSpring、SpringMVC、MyBatis框架开发的实验室设备预约系统完整设计包面向高校计算机相关专业的毕业设计、课程设计与期末大作业场景帮助解决传统实验室设备预约效率低、易出错、难管理的问题。压缩包共1166个文件约18.63MB涵盖51个Java源码、31个JSP页面、42个Jar依赖、1个SQL脚本及18个XML配置另有256个HTML、227个CSS、186个JS与大量PNG、GIF等前端静态资源完整呈现前后端分离的项目结构。系统以MySQL存储预约数据、用户与设备信息支持用户在线预约与管理员统一管理并遵循需求分析、系统设计、编码实现、系统测试的软件工程流程。目前已有43人学习下载适合需要参考SSM整合配置、数据库表设计与预约业务逻辑实现的读者可据此快速理解项目分层、复用代码并完成自己的设计任务。1. 从一台被预约到冒烟的示波器说起SSM 实验室设备预约系统到底在解决什么实验室里最贵的不是那台矢量网络分析仪而是没人说得清它今天下午到底谁在用。我见过一个电子实验室三台示波器、两台频谱仪管理员用 Excel 排班结果一周内撞车四次有研究生白跑两趟。后来他们上了套基于 SSM 的实验室设备预约系统冲突率直接归零。这套系统说白了就干三件事把设备台账数字化、把时间段锁死、把审批流程串起来。SSM 是 Spring SpringMVC MyBatis 的组合国内高校课程设计和中小型管理系统里最常见的技术栈上手快、资料多、答辩好讲。它适合谁适合要交课程设计的学生、要给实验室做内部工具的老师以及想用一套完整 CRUD 项目练手 SSM 常用注解的开发者。这篇笔记不讲空话从表结构到冲突检测 SQL从 MyBatis 映射到部署踩坑全部按能复现的标准写。2. 表结构与冲突检测预约系统真正的技术核心在哪很多人以为预约系统难在界面其实难在数据库设计。设备、用户、预约记录三张表怎么关联时间段怎么存冲突怎么判这些定错了后面全是坑。这一章把地基打牢后面写代码才不会返工。2.1 四张核心表与字段设计一个能用的实验室设备预约系统最少需要四张表用户表、设备表、预约记录表、审批日志表。用户表存账号密码和角色学生/管理员设备表存设备编号、名称、状态、所属实验室预约记录表是核心审批日志表用来追溯谁在什么时候批了哪条申请。预约记录表的关键字段设计如下字段名类型说明idBIGINT主键自增user_idBIGINT预约人外键关联用户表device_idBIGINT设备 ID外键关联设备表start_timeDATETIME预约开始时间end_timeDATETIME预约结束时间statusTINYINT0 待审批 1 已通过 2 已拒绝 3 已取消 4 已完成purposeVARCHAR(255)使用用途create_timeDATETIME提交时间这里有个设计决策时间段用两个 DATETIME 字段存而不是拆成日期加节次。拆节次看起来简单但一旦实验室开放时间调整节次映射全乱。用 DATETIME 存绝对时间冲突判断就是区间重叠问题逻辑清晰。设备表里要有一个 status 字段区分「可用」「维修中」「已停用」预约时先查设备状态再查时间冲突两层过滤。审批日志表至少要有 operator_id、action、target_id、remark、operate_time 五个字段答辩时老师问「怎么追溯审批记录」你能直接答上来。2.2 冲突检测 SQL一条语句判断时间段是否重叠时间段重叠的判定条件是新预约的开始时间小于已有预约的结束时间且新预约的结束时间大于已有预约的开始时间。这个条件覆盖了包含、相交、被包含三种情况。写成 MyBatis 的 XML 映射!-- 查询与指定时间段冲突的已通过预约数量 -- select idcountConflict resultTypeint SELECT COUNT(*) FROM reservation WHERE device_id #{deviceId} AND status 1 AND start_time lt; #{endTime} AND end_time gt; #{startTime} /select逻辑说明status 1只统计已通过的预约待审批的不算冲突否则两个人同时申请同一时段会互相阻塞。start_time endTime AND end_time startTime是标准的区间重叠判定注意 XML 里小于号要转义成lt;这是 MyBatis 新手最常翻车的地方。参数说明deviceId是设备主键startTime和endTime是用户提交的预约起止时间。返回值为 0 表示无冲突可以提交大于 0 则拒绝并提示用户换时间段。在 Service 层调用时还要加一层校验开始时间不能早于当前时间结束时间必须大于开始时间单次预约时长不超过 4 小时这个阈值按实验室规定改。这三条校验放在 Java 代码里做不要塞进 SQL否则报错信息不友好。2.3 用 SSM 常用注解搭出预约接口SSM 里 Spring 和 SpringMVC 的注解是日常写得最多的。Controller 层用RestController和RequestMappingService 层用Service和Transactional依赖注入用Autowired或Resource。下面是一个预约提交接口的骨架RestController RequestMapping(/api/reservation) public class ReservationController { Autowired private ReservationService reservationService; PostMapping(/submit) public Result submit(RequestBody ReservationDTO dto) { // 参数基础校验 if (dto.getStartTime().after(dto.getEndTime())) { return Result.fail(结束时间必须晚于开始时间); } // 调用 Service 层内部做冲突检测 return reservationService.createReservation(dto); } }逻辑说明Controller 只做参数格式校验和路由业务逻辑全部下沉到 Service。RequestBody接收 JSON 格式的请求体前端用 axios 或 fetch 提交时 Content-Type 要设为 application/json。参数说明ReservationDTO是数据传输对象包含 deviceId、startTime、endTime、purpose 四个字段。时间字段用JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解格式化否则前端传字符串会解析失败。Service 层的createReservation方法要加Transactional因为「检测冲突 插入记录」必须在一个事务里否则并发提交时两个请求可能同时通过冲突检测然后都插入成功。这是预约系统最隐蔽的坑后面避坑章节会展开。3. 从登录到审批把 SSM 各层串起来的最小可运行路径表设计好了接下来要把 Spring、SpringMVC、MyBatis 三层配置跑通。很多人的项目卡在「配置写了一堆但启动就报错」这一章按最小可运行路径走每一步都给出配置和验证方法。3.1 Spring 与 MyBatis 整合配置的四个关键点SSM 整合的核心是把 MyBatis 的 SqlSessionFactory 交给 Spring 管理。需要配的东西不少但关键就四个数据源、SqlSessionFactoryBean、MapperScannerConfigurer、事务管理器。!-- Spring 配置文件核心片段 -- bean iddataSource classcom.alibaba.druid.pool.DruidDataSource property namedriverClassName valuecom.mysql.cj.jdbc.Driver/ property nameurl valuejdbc:mysql://localhost:3306/lab_device?useSSLfalseamp;serverTimezoneAsia/Shanghai/ property nameusername valueroot/ property namepassword valueyour_password/ /bean bean idsqlSessionFactory classorg.mybatis.spring.SqlSessionFactoryBean property namedataSource refdataSource/ property namemapperLocations valueclasspath:mapper/*.xml/ property nametypeAliasesPackage valuecom.lab.entity/ /bean bean classorg.mybatis.spring.mapper.MapperScannerConfigurer property namebasePackage valuecom.lab.mapper/ /bean逻辑说明mapperLocations指定 XML 映射文件位置typeAliasesPackage让实体类可以用短名引用MapperScannerConfigurer自动扫描 Mapper 接口并生成代理对象省去逐个配置。参数说明数据库 URL 里的serverTimezoneAsia/Shanghai必须加否则 MySQL 8 会报时区错误。useSSLfalse在本地开发时加上避免警告。Druid 连接池的初始连接数和最大连接数用默认值就够实验室级别并发不高。验证方法写一个 JUnit 测试注入 Mapper 调一次查询能返回数据就说明整合成功。不要等前端写完再测那时候报错你分不清是配置问题还是代码问题。3.2 设备列表分页查询的 Mapper 与 Service 写法设备列表是使用频率最高的页面必须分页。MyBatis 分页有两种做法用 PageHelper 插件或者手写 limit。PageHelper 更省事但要注意版本兼容。Service public class DeviceServiceImpl implements DeviceService { Autowired private DeviceMapper deviceMapper; Override public PageInfoDevice listDevices(int pageNum, int pageSize, String keyword) { PageHelper.startPage(pageNum, pageSize); ListDevice list deviceMapper.selectByKeyword(keyword); return new PageInfo(list); } }逻辑说明PageHelper.startPage只对紧接着的第一条查询生效所以必须紧挨着 Mapper 调用。返回的PageInfo包含总记录数、总页数、当前页数据前端直接拿来渲染分页组件。参数说明pageNum从 1 开始pageSize建议 10 到 20太大前端渲染慢。keyword用于按设备名称模糊搜索Mapper XML 里用LIKE CONCAT(%, #{keyword}, %)。对应的 Mapper XMLselect idselectByKeyword resultTypecom.lab.entity.Device SELECT * FROM device where if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY id DESC /selectwhere标签会自动处理第一个 ANDif做条件拼接。这是 MyBatis 动态 SQL 最常用的组合答辩时被问到「怎么实现条件查询」直接说这个。3.3 审批流程的状态机与接口实现预约审批是一个典型的状态流转待审批 → 已通过 / 已拒绝已通过 → 已完成 / 已取消。状态不能乱跳比如已拒绝的不能直接改成已完成。在 Service 层用一个方法统一处理状态变更Transactional public Result approve(Long reservationId, Integer action, String remark) { Reservation r reservationMapper.selectById(reservationId); if (r null) { return Result.fail(预约记录不存在); } if (r.getStatus() ! 0) { return Result.fail(该预约已处理不能重复审批); } int newStatus (action 1) ? 1 : 2; reservationMapper.updateStatus(reservationId, newStatus); approvalLogMapper.insert(new ApprovalLog(reservationId, getCurrentUserId(), action, remark)); return Result.success(); }逻辑说明先查记录判断当前状态只有待审批status0的才能被审批。审批通过后同时写一条日志保证操作可追溯。Transactional确保状态更新和日志插入要么都成功要么都回滚。参数说明action为 1 表示通过2 表示拒绝。remark是审批意见拒绝时必填。getCurrentUserId()从 Session 或 Token 中获取当前登录用户 ID。这里有个容易忽略的点审批通过后要再次检查时间冲突。因为从提交到审批可能隔了几小时这期间可能有别的预约被批准了。所以approve方法里在更新状态前应该再调一次countConflict有冲突就拒绝并提示管理员。4. 避坑与排查SSM 预约系统上线前必须处理的五个问题这一章全是血泪经验。下面五个问题每一个我都见过真实项目翻车按「现象 → 原因 → 解决」写清楚。4.1 并发提交导致同一时段被重复预约现象两个学生几乎同时提交同一台设备同一时段的预约系统都提示成功管理员审批时发现两条冲突记录。原因冲突检测和插入记录之间存在时间窗口两个线程都通过了检测然后都执行了插入。这是典型的竞态条件。解决三个层面处理。第一Service 方法加Transactional并设置隔离级别为ISOLATION_REPEATABLE_READ。第二在 reservation 表上对(device_id, start_time, end_time)建唯一索引数据库层面兜底。第三如果并发量真的很小用synchronized关键字锁住 Service 方法也能扛但不推荐作为长期方案。4.2 MyBatis 时间字段映射报 Invalid value 异常现象提交预约时后台报Invalid value for getTimestamp()或时间差 8 小时。原因MySQL 驱动版本和时区配置不匹配或者实体类用了java.util.Date但数据库是DATETIME类型转换出问题。解决JDBC URL 加serverTimezoneAsia/Shanghai实体类时间字段统一用java.time.LocalDateTimeMyBatis 3.4.5 以上原生支持。如果必须用 Date在 Mapper XML 里显式指定jdbcTypeTIMESTAMP。4.3 前端传的时间格式后端解析失败现象前端用new Date()转成字符串提交后端报JSON parse error。原因JavaScript 的toISOString()输出的是2024-01-15T08:30:00.000Z格式带 T 和 ZSpringMVC 默认的日期解析器不认。解决前端提交前用 dayjs 或手动格式化成yyyy-MM-dd HH:mm:ss后端 DTO 字段加JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)。两边格式约定死不要依赖自动推断。4.4 事务不生效导致审批状态更新了但日志没写现象审批操作后预约状态变了但审批日志表里没有对应记录。原因Transactional注解没生效。常见原因有三个方法不是 public、同类内部调用、Spring 配置没开tx:annotation-driven/。解决确认方法为 public把事务方法抽到独立的 Service 类里避免自调用检查 Spring 配置里有没有开启注解驱动事务。用TransactionSynchronizationManager.isActualTransactionActive()在方法里打印一下就能确认事务是否真的开了。4.5 部署到 Tomcat 后静态资源 404现象本地 IDEA 里跑得好好的打成 war 包丢到 Tomcat 后 CSS、JS 全部 404。原因SpringMVC 的 DispatcherServlet 拦截了所有请求包括静态资源。本地开发时 IDE 可能做了额外处理部署后暴露了问题。解决在 spring-mvc.xml 里加mvc:resources mapping/static/** location/static//和mvc:default-servlet-handler/。前者显式映射静态资源路径后者把未匹配的请求交回给 Tomcat 默认 Servlet 处理。两个都加上基本能覆盖所有情况。5. 让预约系统真正好用三个进阶技巧与验证方法基础功能跑通只是及格线。这一章讲三个让系统从「能用」到「好用」的技巧每个都附带验证方法你可以直接拿去改自己的项目。5.1 用定时任务自动完成过期预约已通过的预约如果过了结束时间还没人操作状态应该自动变成「已完成」。手动改不现实用 Spring 的Scheduled注解做定时任务Component public class ReservationScheduler { Autowired private ReservationMapper reservationMapper; // 每 30 分钟执行一次把已过期的已通过预约标记为已完成 Scheduled(cron 0 0/30 * * * ?) public void autoCompleteExpired() { int count reservationMapper.completeExpired(); if (count 0) { System.out.println(自动完成过期预约 count 条); } } }对应的 SQL 是UPDATE reservation SET status 4 WHERE status 1 AND end_time NOW()。逻辑说明只处理已通过且结束时间早于当前时间的记录改成已完成状态。参数说明cron 表达式0 0/30 * * * ?表示每 30 分钟的第 0 秒执行按需调整频率。验证方法手动改一条记录的 end_time 为过去时间等定时任务触发后查数据库看状态是否变成 4。注意要在 Spring 配置里加task:annotation-driven/否则Scheduled不生效。5.2 设备使用率统计的 SQL 与图表数据接口管理员最关心的数据是「哪台设备最忙、哪个时段最挤」。一条 SQL 就能算出来-- 统计每台设备近 30 天的预约总时长小时 SELECT d.name, ROUND(SUM(TIMESTAMPDIFF(MINUTE, r.start_time, r.end_time)) / 60, 1) AS total_hours FROM reservation r JOIN device d ON r.device_id d.id WHERE r.status IN (1, 4) AND r.start_time DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY d.id, d.name ORDER BY total_hours DESC;逻辑说明只统计已通过和已完成的预约用TIMESTAMPDIFF算每次预约的分钟数求和后除以 60 得到小时数。DATE_SUB(NOW(), INTERVAL 30 DAY)限定近 30 天。参数说明status IN (1, 4)排除待审批和已拒绝的记录。时间范围可以改成 7 天或 90 天按管理需求调整。后端把这个查询结果包装成 JSON 返回前端用 ECharts 渲染柱状图。验证方法手动插入几条不同设备的预约记录调接口看返回数据是否和手算一致。5.3 我踩过的坑与给你的建议最后说一个我自己的教训。早期做这套系统时我把冲突检测只放在前端做——用户选时间段时用 JavaScript 查一下有没有冲突。结果有人直接调接口绕过前端同一时段被约了三次。后来我把校验全部下沉到 Service 层前端只做体验优化后端做最终裁决。这个原则适用于所有管理系统前端校验是给用户看的后端校验是给数据看的两者都要有但后端才是最后一道防线。另一个习惯是每次改完 Mapper XML先跑单元测试再启动 Web 服务。MyBatis 的 XML 错误在启动时不一定报往往要等到实际调用才暴露提前测能省很多时间。这套 SSM 实验室设备预约系统不算复杂但把表设计、冲突检测、事务处理、状态流转这几块吃透后面做任何预约类、排班类系统都是同一套思路。希望帮到你。本文还有配套的精品资源点击获取