企业官网建设流程全解析

1. 实验室共享预约的核心痛点：为什么需要一个平台

先说个我亲眼见过的场景：某高校的计算机实验室，课表上排得满满当当，但课后的空闲时段完全靠人工登记。负责管理的老师手边放着一本纸质登记簿，学生想用实验室，得跑一趟办公室、翻登记簿找空档、填表、等审批。赶上期末或者课程设计高峰期，同一时段往往有三四拨人申请，谁先登记谁用，后来的只能改期。更头疼的是设备借用——某台工作站坏了没及时更新状态，下一个学生用到一半才发现，连带影响整个实验进度。

这种手工模式的核心问题不是"麻烦"，而是信息不透明。实验室有没有空档、设备能不能用、你申请的时间段是否和别人冲突，这些关键信息全部掌握在登记簿和管理员脑子里。学生看不到实时状态，管理员要在大量纸质记录里人工比对，效率和准确率都扛不住。我几年前接过一个类似的实训项目，当时做了一套 Excel 排班表来缓解，但多人同时编辑、权限管理、设备状态同步根本没法解决，后来才下定决心做独立平台。

这套用 Java + SpringBoot + SSM 搭建的实验室共享预约平台，解决的就是上述链条里的三个典型问题：

1. 可视化资源状态：所有实验室、设备的使用情况统一展示，空闲、占用、维护中一目了然。
2. 标准化预约流程：学生线上提交预约申请，管理员审批，系统自动做时间冲突校验，不依赖人工记忆。
3. 全链路操作留痕：谁在什么时间申请了哪间实验室，审批意见是什么，都形成可追溯的记录，方便期末统计和绩效评估。

适合谁来参考？两类人。一类是正在做毕业设计、需要快速理清"预约类系统"业务逻辑的学生——这类项目在毕设里出现频率极高，选它不是因为新潮，而是因为业务闭环完整、技术覆盖全面，从增删改查到并发冲突、权限控制、数据统计都能讲清楚；另一类是学校里真的要给实验室管理做信息化的老师或技术人员，可以直接参考这套数据模型和预约流程设计，甚至在此基础上做二次开发。

整套平台的核心功能清单并不复杂，但每一项都要落到实处：用户注册与登录、实验室信息管理（包括图片、位置、容纳人数、设备清单）、实验室预约申请与审批、设备借用管理、个人预约记录查询、管理员后台统计。功能一眼看完，但实现过程中涉及的状态设计、冲突校验、事务处理，才是真正有价值的部分。

2. 技术选型复盘：SpringBoot与SSM这套组合背后的取舍

2.1 "SpringBoot+SSM"到底是什么组合

很多人在项目标题里看到"SpringBoot+SSM"会觉得矛盾——SSM 是 Spring + SpringMVC + MyBatis 的缩写，SpringBoot 本身已经自带 SpringMVC，再把两者并列是什么操作？

实际开发中的理解是：SpringBoot 作为项目的基础框架和快速集成工具，项目内部仍沿用 SSM 的三层架构思想——Controller 层管请求路由，Service 层管业务逻辑，Mapper（DAO）层管数据库操作。MyBatis 负责持久层映射，SpringMVC 的请求处理机制在 SpringBoot 中通过spring-boot-starter-web自动装配。换句话说，这不是两套框架叠加，而是用 SpringBoot 把传统 SSM 项目中繁琐的 XML 配置和依赖管理问题全部自动化了。

我见过很多学生在配置传统 SSM 项目时，光web.xml、spring-mvc.xml、spring-mybatis.xml三个配置文件就要折腾一天，各种<mvc:annotation-driven>、<context:component-scan>标签写错一个就启动报错。SpringBoot 把这些约定俗成的配置变成了自动装配逻辑，你只需要在application.yml里写数据库连接信息，再配合@MapperScan扫描 Mapper 接口，就能把 MyBatis 跑起来。

2.2 为什么 SpringBoot 成了这类项目的首选

预约平台这类"管理系统"性质的业务，核心诉求是快速交付、稳定运行、易于修改，而不是追求极致的性能和复杂架构。SpringBoot 在这三点上优势非常明显：

• 内嵌 Tomcat：不需要单独配置外部 Servlet 容器，打包成 Jar 直接java -jar就能跑，部署门槛大幅降低。
• Starter 依赖体系：需要什么功能加什么依赖，比如mybatis-spring-boot-starter、spring-boot-starter-validation，版本兼容性由 SpringBoot BOM 统一管理，很少出现传统 SSM 里 jar 包版本冲突的噩梦。
• 配置简化：数据库、Redis、文件上传等常见场景都有现成的配置项，不用像传统 SSM 一样手写一堆 Bean 定义。

有一个细节很多初学者容易忽略：SpringBoot 的自动装配虽然方便，但也意味着"配置在黑盒里"。比如 MyBatis 的map-underscore-to-camel-case这个参数，默认值在不同版本里表现不同，如果实体类属性用了驼峰命名而数据库字段是下划线风格，查询结果可能出现某些字段是 null。这个我在后文踩坑部分会详细说。

2.3 为什么说 MyBatis 在这个项目里不可替代

有人会问，既然是 SpringBoot 项目，用 Spring Data JPA 不是更省事吗？JPA 确实在单表 CRUD 上有优势，但预约平台有一个高频操作是 JPA 很难优雅处理的——多条件动态查询。比如管理员在后台按实验室名称、设备类型、预约日期、审批状态等多个条件组合筛选预约记录，条件个数和组合方式完全不确定。用 MyBatis 的<if>标签配合<where>标签动态拼接 SQL，几行代码就能解决；用 JPA 则需要写Specification或QueryDSL，学习成本一下子上来了。

另外，预约冲突校验这类核心 SQL 需要精确控制查询逻辑，MyBatis 手写 SQL 的方式让人能直接看到数据库到底执行了什么，排查问题时心理踏实。对于学生项目来说，这一点特别重要——答辩时老师问"你这条 SQL 逻辑是怎么写的"，你能直接说清楚，而不是含糊地解释"框架帮我处理了"。

所以这套技术组合的取舍逻辑是：SpringBoot 管运行环境与配置、SpringMVC 管请求流转、MyBatis 管数据操作，三者各司其职。对一个预期业务规模不大、但逻辑链条完整的预约系统来说，这个选型兼顾了开发效率和可解释性。

3. 数据模型设计：把预约业务拆成五张核心表

数据库设计是预约平台的地基。我习惯先画业务流转图再建表：用户发起预约 → 系统校验时间冲突 → 管理员审批 → 用户使用实验室 → 完成或取消。围绕这条链路，数据表可以拆成五张核心表。

3.1 用户、实验室、设备三类基础表的设计要点

用户表（sys_user）：不要只存账号密码就完事。一个预约平台里，用户至少分"学生"和"管理员"两种角色，所以需要有role字段（0-学生，1-管理员，2-超级管理员，按需扩展）。密码字段建议用 BCrypt 加密存储，明文存密码在答辩时会被直接扣分。扩展字段里real_name、student_no、phone、email都要预留，后续做审核通知和借用登记都用得上。

实验室表（lab_info）：除了lab_name、location、capacity这些基本字段，两个细节需要特别注意。一是status字段，标记实验室是否开放预约——放假期间或装修中的实验室应能一键置为不可预约，而不是删除记录；二是cover_image字段存缩略图路径，列表页展示需要。设备清单如果简单，可以直接存一个逗号分隔的字符串；如果设备多且需要单独管理，就拆关联表。

设备表（equipment）：equipment_name、lab_id（归属实验室）、status（0-正常，1-维修中，2-已报废）。设备状态会影响实验室预约的可用性——比如某实验室里唯一一台高性能工作站坏了，管理员可以临时把实验室标记为不可预约，也可以只标记设备维修中，预约逻辑里单独判断。两种方案都可行，关键是业务规则要提前定清楚，不要在代码里又写一套，纸面又写一套。

3.2 预约记录表是整条业务链的核心

预约记录表（appointment）承载所有核心业务，字段设计直接决定代码复杂度和查询效率。我的建议是至少包含以下字段：

start_time和end_time设计成 datetime 而不是单独的"星期 + 时间段"字段，是为了方便直接做时间重叠判断。appointment_date单独抽出来，是因为按天统计预约量是管理员后台的常见需求，单独一个date字段配合索引，查询效率会好很多。

这里有一个很容易犯的设计错误：用"星期几 + 第几节"来表示预约时间。这种表示法贴近大学课表的直觉，但致命问题是跨周判断、节假日调休、时长计算都变得非常别扭，而且查询某个时间段是否被占用时，SQL 写法会绕一大圈。所以哪怕前期录入数据时稍微麻烦一点，也要坚持用标准时间类型。

3.3 时间段冲突的 SQL 判断逻辑

预约系统的"防冲突"是整个项目最核心的校验逻辑。假设用户要预约的时间段是 [newStart, newEnd]，那么查找数据库中与该时间段重叠的记录，SQL 逻辑是这样的：

SELECT COUNT(*) FROM appointment WHERE lab_id = #{labId} AND status IN (0, 1) -- 待审核和已通过都算占用 AND appointment_date = #{appointmentDate} AND start_time < #{newEnd} AND end_time > #{newStart}

这个重叠判断的原理是：start_time < newEnd确保新预约开始前，旧预约还没结束；end_time > newStart确保旧预约结束时间在新预约开始之后。两个条件同时成立，说明两个时间段在时间轴上有交集。用生活化的比喻：一个人还没走，另一个人就要进门，两人撞上了——这个判断就是检查"前一个的结束时间是否晚于后一个的开始时间"且"后一个的开始时间是否早于前一个的结束时间"。

如果 COUNT 结果大于 0，直接提示用户"该时间段已被预约，请选择其他时间"。这个校验不仅要写在 Service 层，还要在建表时考虑加上时间约束（如果能上 MySQL 8.0 的话可以用生成列和唯一索引来兜底，但一般情况下 Service 层加锁校验就够用了），防止并发请求下出现超卖。

4. 并发与状态管理：预约为啥不能拍脑袋实现

4.1 同一实验室同一时间被抢的问题

很多学生第一次实现预约功能，代码逻辑是"先查有没有冲突，没有就插入"。这在单用户操作时没问题，但一旦两个用户同时提交预约请求，就会出现脏读：两个请求都查到了"当前时段空闲"，然后都执行了插入，数据库里就出现两条冲突的预约记录。

解决这个问题的核心思路是让"检查并插入"变成一个原子操作。有两种常见方案：

方案一：在 Service 层方法上加@Transactional，并配合数据库的行锁。查询语句加上FOR UPDATE，让冲突检查期间的记录行被锁住，另一个请求必须等前一个事务提交后才能查询。这种方式实现简单、效果可靠，但要注意锁的粒度和死锁风险——锁定范围尽量精确到具体lab_id + appointment_date对应的记录。

@Transactional public boolean createAppointment(Appointment appointment) { // 先锁定该实验室当天的预约记录，防止并发 List<Appointment> list = appointmentMapper.selectForUpdate( appointment.getLabId(), appointment.getAppointmentDate()); // 再在内存里判断时间冲突 for (Appointment a : list) { if (isOverlap(a, appointment)) { return false; // 冲突，回滚 } } return appointmentMapper.insert(appointment) > 0; }

方案二：用一个独立的"时间段占用表"或者 Redis 分布式锁来做更细粒度的控制。比如用 Redis 的SETNX以lab:日期:开始时间为 key 做加锁，抢锁失败直接提示冲突。这种方式能支撑更高的并发量，但对学生项目来说略微"过度设计"了，如果答辩时老师问为什么不用 Redis，你可以回答"当前规模下数据库锁足够，Redis 预留了扩展空间"。

我自己的经验是，学生项目用方案一就够了，但要在代码注释里写明并发控制思路，答辩时这是个高频考点。

4.2 状态流转设计：预约从生到死要经过哪些状态

预约状态的枚举值我在前面表格里写了五个：待审核、已通过、已拒绝、已取消、已完成。这五个状态之间的流转关系必须清晰，不能出现"已拒绝的记录还能被管理员通过"之类的逻辑漏洞。

正常流转路径是：

1. 学生提交预约 → 状态为待审核
2. 管理员通过 → 状态为已通过；管理员拒绝 → 状态为已拒绝
3. 学生在审核前可以自行取消 → 状态为已取消
4. 预约使用完毕后 → 状态为已完成（可以由管理员手动标记，也可以根据预约结束时间自动触发）

实现时，我建议把状态流转写成一个独立的方法或枚举类，而不是在 Controller 里直接setStatus。比如：

public enum AppointmentStatus { PENDING(0), APPROVED(1), REJECTED(2), CANCELLED(3), COMPLETED(4); public static boolean canCancel(int status) { return status == PENDING.value || status == APPROVED.value; } public static boolean canApprove(int status) { return status == PENDING.value; } }

这样所有状态合法性判断集中在一处，后续加新状态也只需要改一个文件。

4.3 事务边界与锁定策略的实践经验

事务的边界是另一个容易踩坑的地方。预约平台里至少要保证两个事务边界：

• 创建预约：冲突检查 + 插入记录必须在一个事务里，否则"先检查后插入"就没有意义。
• 审批操作：更新预约状态 + 记录审批人 + 写审批备注必须在一个事务里，避免出现状态改了但备注没写的半吊子数据。

这里有个提高事务可靠性的细节：所有可能抛异常的地方都要显式检查。MyBatis 的insert方法返回值是受影响行数，如果返回 0 说明插入失败，要主动抛异常让事务回滚，不要直接返回成功。我在调试过程中遇到过因为插入失败但没检查返回值，导致状态显示异常的问题，查了半天才发现是某条数据的外键关联不存在。

事务这块还有一个经验：@Transactional默认只在 RuntimeException 上回滚，如果你在业务代码里抛的是自定义异常的基类是 Exception，就可能出现"代码逻辑进异常分支了，但数据库没回滚"的怪异现象。解决方式很直接，@Transactional(rollbackFor = Exception.class)，这个注解参数不要省。

5. 关键模块实现速览：权限、动态查询与数据交互

5.1 登录与角色权限的落地姿势

预约平台的角色权限设计虽然简单——只有学生和管理员两种身份——但也不能在 Controller 里到处写if ("admin".equals(user.getRole()))。更好的做法是基于 Spring AOP 定义一个登录校验注解加拦截器。

我习惯把权限校验拆成三层：

1. 登录拦截：基于 Session 或 Token 判断用户是否已登录，未登录的请求统一跳转登录页或返回未授权 JSON。
2. 角色校验：基于 HandlerInterceptor 拦截器匹配请求路径，/admin/**开头的接口统一校验管理员身份。
3. 接口级别校验：如果某些特殊接口要求更细的权限，用@RequireRole("admin")这类自定义注解配合 AOP 切面实现。

@Aspect @Component public class RoleAspect { @Around("@annotation(requireRole)") public Object checkRole(ProceedingJoinPoint pjp, RequireRole requireRole) throws Throwable { // 从 ThreadLocal / RequestContext 获取当前登录用户 User currentUser = UserContext.get(); if (currentUser == null || !requireRole.value().equals(currentUser.getRole())) { throw new BusinessException(403, "无权限访问"); } return pjp.proceed(); } }

用 AOP 的好处是权限逻辑和业务逻辑完全解耦，Controller 里只需要关注参数校验和业务调用，代码清爽很多，也方便答辩时演示"切面编程"这个知识点。

5.2 动态 SQL 做多条件检索

管理员后台的预约记录查询、实验室列表筛选，几乎都逃不开多条件组合。MyBatis 动态 SQL 在这里作用很大，以预约记录查询为例：

<select id="selectAppointmentList" resultType="map"> SELECT a.*, u.real_name, l.lab_name FROM appointment a LEFT JOIN sys_user u ON a.user_id = u.id LEFT JOIN lab_info l ON a.lab_id = l.id <where> <if test="labId != null and labId != ''"> AND a.lab_id = #{labId} </if> <if test="status != null"> AND a.status = #{status} </if> <if test="startDate != null"> AND a.appointment_date &gt;= #{startDate} </if> <if test="endDate != null"> AND a.appointment_date &lt;= #{endDate} </if> <if test="realName != null and realName != ''"> AND u.real_name LIKE CONCAT('%', #{realName}, '%') </if> </where> ORDER BY a.create_time DESC </select>

因为用了LEFT JOIN，分页查询要用 PageHelper 插件时注意积分的坑：PageHelper.startPage()必须紧跟在查询语句之前，中间不能有其他 SQL 操作，否则分页会失效或者统计到错误的总数。

5.3 后端跟前端约定的数据交互格式

前后端交互的规范直接影响联调效率。我统一使用一种 Result 格式返回所有接口：{ code, message, data }，code 为 0 表示成功，非 0 表示业务异常。这样前端的 axios 拦截器只需要判断 code，错误提示从 message 里取，不用每个接口单独处理。

{ "code": 0, "message": "success", "data": { "total": 128, "list": [] } }

前端页面如果用的模板引擎（Thymeleaf），后端直接返回视图名。如果用的 Vue 等前后端分离方案，后端接口统一返回 JSON，前端通过 Axios 请求。两种方案我都在这个项目上玩过，说实话对于实验室预约这种规模的项目，用 Thymeleaf 做服务端渲染反而更省事——不用配置跨域、不用做登录态共享，Session 天然可用；但如果前端有比较复杂的图表展示（比如预约统计趋势图），Vue + ECharts 会更顺手。

6. 整合与调试中踩过的坑：版本、事务与配置

6.1 SpringBoot 版本与 starter 版本不匹配

整合 SpringBoot 和 MyBatis，最常用的依赖是mybatis-spring-boot-starter。但这套 starter 的版本和 SpringBoot 主版本之间有兼容矩阵，不是随便选一个就能跑。我踩过的一个典型坑是：SpringBoot 3.0 刚发布时，很多人直接把项目版本升级到 3.0，然后用了一个较老的mybatis-spring-boot-starter（1.x 版本），结果启动直接报ClassNotFoundException，原因是 SpringBoot 3.0 基于 Jakarta EE，而老 starter 里的拦截器还在引用javax.servlet包。

解决方案很直接：使用与 SpringBoot 主版本匹配的 starter 版本。比如 SpringBoot 2.7.x 对应mybatis-spring-boot-starter 2.3.x；SpringBoot 3.x 对应mybatis-spring-boot-starter 3.0.x。拿不准就去 Maven 仓库看该 starter 的发布时间和依赖声明，别乱猜。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency>

6.2 Mapper 接口扫描与 XML 路径配置

MyBatis 在 SpringBoot 中有两种使用方式：全注解（Mapper 接口上写@Select）和 XML 映射。预约平台的复杂动态查询明显更适合 XML，但 XML 的路径配置经常出问题。

application.yml里的配置需要注意三个点：

mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.lab.entity configuration: map-underscore-to-camel-case: true

• mapper-locations：必须指向实际放 XML 的路径，如果放在了src/main/java下而不是resources下，打包时默认不会带进 Jar，运行时报Invalid bound statement。最简单的做法是把 XML 放resources/mapper/下。
• type-aliases-package：配置后 Mapper 的返回类型可以直接写Appointment而不用写全限定类名。
• map-underscore-to-camel-case：开启后数据库的user_id才能自动映射到实体的userId，不开的话你会看到查询出的对象一堆字段都是 null，排查半天还不知道原因。

另外别忘了在启动类上加@MapperScan("com.example.lab.mapper")，扫不到 Mapper 接口，Spring 容器里就没有对应的 Bean，所有依赖注入都会报错。

6.3 @Transactional 失效的两个真实场景

我第一次在企业项目里遇到事务回滚失效时，花了大半天才找到原因。这种失效问题在预约平台里同样会出现，最常见的两个场景是：

1. 同类调用导致自注入失效。Spring 的事务是基于 AOP 代理实现的，默认情况下只有通过代理对象调用方法时，事务注解才生效。如果在一个 Service 内部写了一个方法调用同类中的另一个@Transactional方法（this.method()），这个调用不会经过代理对象，事务直接失效。之前遇到过的同学写的代码里，createAppointment()方法内部调this.checkAndInsert()，加再多事务注解也没用。

2. 非 public 方法加事务注解。Spring 的@Transactional只对 public 方法默认生效，如果你把事务方法写成 private，框架会静默忽略注解，不报错也不回滚。这个问题尤其隐蔽，因为代码编译运行看起来都很正常，直到出现脏数据才暴露。

另外，@Transactional的生命周期范围是整个方法体，包括远程调用和异步操作。如果事务方法里调用了外部接口而对方迟迟不返回，数据库连接会一直被占用，连接池耗尽后整个应用假死。预约平台里如果接入了邮箱通知或短信通知，建议把通知操作放到事务提交后再执行，配合 Spring 的@TransactionalEventListener监听事务提交事件。

7. 论文与答辩的加分点：LW 之外的实操印象分

这类项目经常配套 LW（论文），很多同学觉得把功能做出来了就大功告成，其实论文和答辩的表现同样重要。结合我多次参与类似项目评审的经验，下面这几个点最能让评委对你有好印象。

7.1 论文逻辑：从背景到实现的叙述主线

论文不要写成"用了什么技术、实现了什么功能"的流水账，要有明确的问题导向。我的建议是主线结构和做项目时的思路保持一致：

第一章 绪论：重点写现实背景——实验室共享预约的需求从哪里来？人工管理的低效体现在哪几个具体环节？同类系统（如教务系统里的教室预约）有什么不足？写清楚"为什么有这个系统"，比堆砌技术名词更有说服力。

第二章 需求分析：把用户类型、核心业务流程、功能需求（前台和后台分别列）、非功能需求（响应速度、并发量、安全性）写清楚。这里的重点是流程图和数据流描述，能用文字说清"谁在什么条件下发起什么操作、系统如何反馈"就是合格水平。

第三章 系统设计：分层架构图（Controller、Service、Mapper）、数据库 E-R 图与表结构。表结构说明里要写字段含义和设计理由，比如"预约状态为什么用 tinyint 而不是 varchar"，这种细节能明显体现思考深度。

第四章 系统实现：挑核心模块讲实现细节，推荐重点写预约冲突校验和权限控制。贴关键代码片段并解释思路，不要全篇贴代码——评委更看重你的思路，不是代码量。

第五章 测试与总结：功能测试列用例，性能测试如果做了就写响应时间，没做就如实说明。

7.2 答辩现场高频问题与应对思路

答辩时老师问的问题通常集中在几个"为什么"上：

• 为什么选择 SpringBoot 而不用传统 SSM 独立配置？回答思路：SpringBoot 简化了配置和部署，但项目仍保留 SSM 的分层结构，两者不冲突；强调自动装配原理理解清楚即可。
• 预约冲突是怎么避免的？这是必考题。把时间重叠判断 SQL 画出来，解释start_time < newEnd AND end_time > newStart的逻辑，再说一遍事务 + 锁的并发控制方案，基本就能拿分。
• 如果预约人数变多、并发量上来了，系统怎么优化？别慌着说"加 Redis"，而是先分析瓶颈在哪：当前方案数据库锁是否够用？懒加载与索引设计是否合理？再把可扩展方向（Redis 预校验、消息队列异步审批、读写分离）逐一列出，表现出"知道往哪走"比"已经做过"更重要。

7.3 一个容易被忽略的加分细节：数据初始化脚本

很多同学提交项目时把数据库建表脚本写在一个.sql文件里，这是基础操作。加分操作是：脚本里除了建表语句，还包含基础数据——比如默认管理员账号（BCrypt 加密后的密码）、几间正常的实验室记录、几个典型的预约记录（覆盖待审核、已通过、已完成等不同状态）。

这样评审老师导入数据库后，直接能看到界面上有真实数据，而不是空荡荡的列表。这个细节带来的第一印象提升，比你在论文里写一千字的功能描述都有效。

我在做类似项目时，还会在 README 里写清楚启动步骤、默认账号、测试用例，方便别人快速跑起来。这既是工程素养的体现，也是在团队协作或开源分享中必不可少的环节——毕竟你写的东西最终是要被人使用的，减少对方的上手时间，就是减少你自己的答疑时间。

8. 一点个人体会

把这套实验室共享预约平台完整走下来，我的感受是：预约类系统表面上是个典型的后台管理项目，真正有价值的部分反而是业务约束的完整性和对异常情况的处理能力。时间冲突校验、状态机的流转、并发下的数据一致性、权限控制的粒度——每一个环节都不难，但串在一起就能体现一个开发者对业务的理解深度。

最后分享一个小技巧：项目里所有状态字段的枚举值，最好集中放在一个常量类或枚举类里，并且加上注释说明每个值对应的业务含义，比如status = 2表示"预约已拒绝"。这个习惯一开始看起来有点"小题大做"，但等到你写统计报表、写定时任务清历史数据、或者接手别人的代码时，就会意识到它省下的时间远比当初多写那几行注释的成本大。

如果你正准备做类似的预约类系统（实验室、会议室、实训基地、实验设备都适用），把重心放在业务状态设计和并发冲突处理上，这两块通了，整体项目的水准不会差。有什么在实现过程中卡住的问题，欢迎在评论区聊，我看到会尽量答复。