做预约类系统，最怕的不是功能做不完，而是做完之后在真实场景里一测就翻车。这次要聊的是一个基于 Spring Boot 的宠物美容护理预约系统，面向的场景很典型：宠物主人在线选服务、选美容师、约时间，美容师在后台确认和推进订单，管理员管服务项目、管排班、看营收。这类业务看起来就是标准的增删改查，但真正落地时会碰到时间冲突、并发抢单、状态流转、角色权限一堆细碎问题。这篇文章就把我从需求梳理到数据库设计、接口实现、权限控制，再到实测踩坑的完整过程展开讲清楚，适合正在做类似项目的开发者，也适合想快速搭一套预约类管理系统的人参考。
先给个总的判断：如果你只把预约系统当成"预约表 CRUD"，后面必然要返工。预约的业务本质是资源的有限时段分配，所以设计的核心不是表格多不多，而是怎么保证"同一个美容师、同一个时间段、只能被一个预约占用"。这个点想透了，系统就成功了一大半。
1. 从"预约"倒推业务边界：三方角色和一条状态链
1.1 三类使用者的真实诉求
宠物美容护理预约系统和普通的商品下单系统有个明显区别：它既卖服务，又约时间，还绑定具体的人来执行。整个系统里站着三类角色，每一类的操作习惯都不一样。
顾客端要的是简单。登录注册之后，能维护自己的宠物档案，狗叫什么、什么品种、多大了、有没有攻击性、有没有皮肤病，这些信息直接影响美容师的操作准备。然后选美容店提供的服务项目，基础洗护、SPA、造型修剪、驱虫护理，每个项目有价位和预计耗时。接着选美容师、选日期、选时段，提交预约。顾客最关心的是"我选的这个时间到底还有没有位置"，以及"临时有事能不能取消"。
美容师端关心的是自己当天的工作节奏。他们需要一个工作台，能看到自己被分配了哪些预约，按时间排好序，能一键把预约从"已确认"推进到"服务中"，再推进到"已完成"。如果系统里还带评价功能，美容师也需要看到顾客对自己的评价。
管理员管的事情最杂。维护服务项目的上架下架、维护美容师的入职和休假状态、提前编排美容师的排班表，还要能查看所有预约单，按日期或按美容师筛选，看每天的营收和取消情况。很多做这类系统的人容易漏掉"排班管理"，结果美容师的服务时间全靠顾客随便选，最后现场一团乱。排班表提前锁死可用的美容师和时段，预约只能在排班范围内发生，这是预约系统的地基。
1.2 一条完整的状态链
预约单不是创建出来就完事，它要沿着一条状态链走完生命周期。我最终落地的状态机是：
待确认 → 已确认 → 服务中 → 已完成，另外还有已取消和已爽约两个分支状态。
为什么要有"待确认"和"已确认"两步？因为美容师的排班可能临时有变动，比如某位美容师当天上午临时请假，店长要能主动取消或调整还没开始的预约。顾客提交预约后先挂起，等店长或美容师确认，这样比顾客提交就直接锁定资源更贴合真实门店的运作方式。爽约状态则是针对"已确认但顾客没来"的情况，通常由美容师在核销时标记，这样统计营业数据时能看出来流失情况。
每个状态的推进都要有权限约束。顾客只能创建和取消预约，取消范围也有限制；美容师能把状态推进到服务中、已完成，或者标记爽约；管理员可以强制取消和调整。状态之间不是任意跳转的，代码里要有一层校验，不能出现"已完成"的订单又被改成"待确认"这种荒唐事。
1.3 技术选型：把功夫花在刀刃上
这套系统用的是 Spring Boot + MyBatis-Plus + MySQL，前端用传统的服务端渲染加 Bootstrap，后台管理界面类似但拆成独立模块。选这套组合不是因为"教程里都这么写",而是对这类业务来说它确实是投入产出比最高的方案。
Spring Boot 的自动配置让项目搭建成本极低，内嵌 Tomcat 也方便部署演示。MyBatis-Plus 在这个场景里比 JPA 实用，尤其是分页查询、逻辑删除、代码生成器，能省掉大量重复的 Mapper 编写时间。MySQL 对付这个量级的并发完全没有压力，配上 InnoDB 的事务和唯一索引，正好能解决预约防冲突最核心的问题。没有引入 Spring Security，是因为这种小型管理系统的权限模型只有三种角色，一个拦截器就能控制得明明白白，引入 Security 反而会让新手在学习时被过滤链、鉴权配置这些概念绕晕。
2. 数据库建模：六张表如何撑起整个预约流程
2.1 从用户表到评价表的核心清单
预约系统的数据模型围绕"人、宠物、服务、美容师、预约单"这五个对象展开。实践中我建议分成六张核心表：用户表、宠物信息表、服务项表、美容师表、预约单表、评价表，外加一张排班表。宁可一开始多建一张表，也不要后期硬往一张表里塞字段。
用户表负责三类角色的统一登录，用一个 role 字段区分管理员、美容师和顾客。宠物信息表挂在顾客下面，因为一个顾客可能带着两三只宠物来洗澡，每只宠物的脾气和禁忌都不一样。服务项表是预设的服务菜单，价格和时长都存在这里。美容师表单独拆出来，而不是直接用用户表的一条记录替代，是因为美容师要想关联排班、评价、擅长技能，独立表更加清晰。
预约单表是整张数据模型的中枢，字段规划尤其重要。除了外键关联之外，必须冗余上 appointment_date、start_time、end_time 这三个时间字段。很多人做预约表只存一个 appointment_time，结果"早上10点、时长两小时"还是"下午4点、时长两小时"都区分不清，到后面算冲突、算营收都很被动。冗余时间字段虽然看着重复，但查询和判断效率都高很多。
2.2 预约单表的建表细节
预约单表的建表语句，我简化和提炼后长这样：
CREATE TABLE appointment_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, customer_id BIGINT NOT NULL, pet_id BIGINT NOT NULL, service_id BIGINT NOT NULL, groomer_id BIGINT NOT NULL, appointment_date DATE NOT NULL, start_time VARCHAR(5) NOT NULL, end_time VARCHAR(5) NOT NULL, status TINYINT NOT NULL DEFAULT 0, remark VARCHAR(255), cancel_reason VARCHAR(255), actual_start_time DATETIME, actual_end_time DATETIME, create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, deleted TINYINT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_groomer_slot (groomer_id, appointment_date, start_time, status), KEY idx_customer (customer_id), KEY idx_status_date (status, appointment_date) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;这里的 order_no 是业务单号，比如 APPT20250607001，虽然数据库主键已经唯一，但业务单号有个好处：顾客打电话进店时报单号，比让店员问"您那行数据的 id 是多少"要自然得多。version 字段是为乐观锁预留的，后面讲并发时会用到。deleted 字段是逻辑删除标记，预约数据不能物理删，否则后面的营收统计、取消率统计都会变成一笔糊涂账。
2.3 排班表与逻辑删除的取舍
排班表的设计思路是"先有可约资源，再有预约"。管理员在某一天给美容师配上几个可用时段，每个时段对应排班表里一条记录，顾客能预约的时段全部来自排班表。这样就不用担心"顾客选了美容师休息日的晚上8点"这种离谱预约。
排班表的核心字段是 groomer_id、work_date、start_time、end_time、is_booked。is_booked 代表该时段是否已被占用。这里有个细节：排班表里不应该放预约单 id，因为一个时段一旦被预约，排班记录就应该处于锁定状态，具体是谁锁定的去看预约单表。排班表只管"可用/占用"，预约明细交给预约单表，职责分离之后，做"某个美容师一周可用时段列表"这类查询会非常顺手。
关于逻辑删除，我一律建议开。物理删除在演示阶段看不出问题，但一旦有了预约数据、评价数据、统计报表，删一条历史记录会让整条链断裂。MyBatis-Plus 配置了 @TableLogic 之后，普通查询会自动过滤已删除记录，管理员做数据恢复也方便。这个习惯越早养成越好。
3. 预约防冲突：并发撞单与时间区间相交判断
3.1 创建预约的核心流程
创建预约这个动作，是整套系统技术含量最高的地方，它同时暴露了业务逻辑和并发控制两个问题。我在 Service 层实现的流程是这样的：
- 校验顾客、宠物、服务项、美容师都存在且状态正常。
- 根据服务项表查出时长，算出 end_time，不接受前端传来的结束时间，防止有人恶意修改。
- 判断预约日期是否在排班表允许范围内，美容师当天是否排班，目标时段是否 still 可约。
- 检查目标美容师在同一日期同一时间段是否已被其他预约占用。
- 通过后再执行插入，由数据库唯一索引兜底，插入失败则返回"该时段已被抢走"。
前四步是业务层校验，第五步是数据库兜底。很多人只写第一步和第四步，以为查一下没有就能插，结果上线之后在高并发场景下超卖。我问过不止一个翻车的同学，他们的代码都是"先 select 再 insert"，两个请求同时查出"时段空闲"，然后先后 insert 成功。这就是典型的并发竞态。
3.2 数据库唯一索引怎么兜底
解决上面这个竞态，最朴实的办法就是给预约表加一个唯一索引，让数据库在插入时做最终裁决。索引字段选 groomer_id、appointment_date、start_time、status 的组合，含义是"同一个美容师在同一天同一个开始时间，只能存在同一种状态的一条预约记录"。
为什么要把 status 放进去？因为一个订单取消后，同一天同一时段理论上是可以重新被预约的。如果没有 status，记录会被取消占着索引位，新预约永远插不进去，业务就卡死了。把 status 纳入唯一索引之后，状态不同就能共存，被取消的单子也不会堵住新预约的插入路径。
这里有一个前提：唯一索引只能保证 start_time 不重复，如果一个预约是 10:00-12:00，另一个是 10:30-11:30，start_time 不同但区间已经交叉，唯一索引管不了。所以区间冲突判断必须在业务层完成，唯一索引只是兜底防并发，两者缺一不可。
3.3 区间交叉判定与事务控制
双区间交叉判断的规则说起来很简单，两个时间段相交的否定条件是：A 在 B 开始之前结束，或者 A 在 B 结束之后开始，取反就是相交。Java 里实现可以这样处理：
public boolean isTimeOverlap(String startA, String endA, String startB, String endB) { OrderTime a = new OrderTime(timeToMinutes(startA), timeToMinutes(endA)); OrderTime b = new OrderTime(timeToMinutes(startB), timeToMinutes(endB)); return a.start < b.end && b.start < a.end; }把字符串时间转成分钟数，比较大小关系就够了。判断条件写成"a.start < b.end && b.start < a.end"，不要用复杂的嵌套 if，越简单越不容易错。
Service 层方法需要加 @Transactional，但要注意事务只能处理异常回滚，不能解决并发插入。正确的组合是事务保证数据一致性，唯一索引保证并发唯一性。实际写的时候，我把"查占用"和"插入"放在同一个事务里，插入时如果触发了 DuplicateKeyException，会统一转成业务提示，而不是把数据库异常直接甩给前端。
创建预约的 Service 方法大致骨架如下：
@Transactional(rollbackFor = Exception.class) public AppointmentOrder createOrder(CreateOrderRequest request, Long customerId) { ServiceItem service = serviceItemMapper.selectById(request.getServiceId()); Groomer groomer = groomerMapper.selectById(request.getGroomerId()); int startMinute = timeToMinutes(request.getStartTime()); int endMinute = startMinute + service.getDurationMinutes(); boolean scheduleAvailable = scheduleMapper.checkAvailable( request.getGroomerId(), request.getDate(), request.getStartTime()); if (!scheduleAvailable) { throw new BizException("该美容师此时间段未排班或已被占用"); } boolean orderConflict = orderMapper.existsOverlap( request.getGroomerId(), request.getDate(), startMinute, endMinute); if (orderConflict) { throw new BizException("该时间段已存在预约，请选择其他时间"); } AppointmentOrder order = new AppointmentOrder(); // 组装订单字段 orderMapper.insert(order); scheduleMapper.lockSlot(request.getGroomerId(), request.getDate(), request.getStartTime()); return order; }这段代码里的 existsOverlap，在 SQL 里对应的写法是判断已有预约的 start_time 和 end_time 与目标区间的相交关系。SQL 写出来是一行带 AND 的嵌套条件，别写错等于或大于等于的边界。我的习惯是，一个区间的开始严格小于另一个区间的结束，两个都满足才算出交叉，等于号在这种场景下是不存在的，因为一个预约 10:00 结束，另一个 10:00 开始，这不叫冲突。
4. 角色权限落地：拦截器比想象中更实用
4.1 登录态与角色拦截的最小实现
管理后台、美容师工作台、顾客端，三块界面共用一套登录体系，后端通过 Session 中的用户对象判断角色。针对这类规模的项目，一个拦截器是最干净的方案，不需要引入框架，也不用维护几十行拦截规则配置。
拦截器里做的三件事：第一步检查 Session 里有没有登录用户，没有就重定向到登录页；第二步根据路径前缀判断目标接口需要的角色；第三步比对当前用户角色，不匹配就返回 403 页面。路径规划上我会刻意区分前缀，比如 /admin/** 只有管理员能进，/groomer/** 只有美容师能进，/customer/** 登录用户都能进，这样拦截器配置写起来很直观。
@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); LoginUser user = (LoginUser) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } String uri = request.getRequestURI(); if (uri.startsWith("/admin/") && user.getRole() != 0) { response.setStatus(403); return false; } if (uri.startsWith("/groomer/") && user.getRole() != 1) { response.setStatus(403); return false; } return true; } }别小看这套简单实现。很多课程项目里干脆不做权限拦截，所有功能全部平铺在菜单里，演示的时候自己方便，但老师一问"顾客能不能调后台价目表"就当场卡壳。把权限控制这件事真正做出来，哪怕实现得朴素，也说明你理解了多角色系统的边界。
4.2 美容师工作台和顾客端的核心交互
美容师工作台是整个系统里最有"使用价值"的界面，它的核心是一份当日待办列表。我已经确认的预约会按时间从早到晚排开，每条显示顾客昵称、宠物品种、服务项目、预期时长、备注。美容师点"开始服务"时，系统记录 actual_start_time，同时把订单状态从已确认推进到服务中；点"完成服务"时，记录 actual_end_time，状态变为已完成。
要注意的是，这里的状态推进不能只改一个字段。顾客端看到的订单状态要实时变化，门店当天的预约看板也要联动。简单做法是前端每次翻页都重新查询最新状态，后端在状态变更时更新 update_time。这不算什么高深技术，但在实际演示中"美容师点一下，顾客端立刻能看到服务中"这个体验非常加分。
顾客端最需要打磨的是"我的预约"列表和取消预约。取消预约不能无限制，如果订单状态已经是服务中或者已完成，后端必须拒绝取消；如果已经确认但还没开始，顾客可以取消，但系统要同时释放排班表的占用状态，让这个时段能被重新预约。
4.3 管理员视图：统计比想象中简单
管理员后台除了维护服务项和美容师，还要给出一组基础统计指标。我落地了四个统计卡片：当日预约总数、当日完成数、当日营收、当月取消率。营收的计算来源于已完成订单的服务项价格总和，不算退款，不算未到达的爽约单。取消率则是当月取消的单子数除以当月预约总数，这个指标能反映顾客的时间观念，也能反映排班安排是否合理。
这些统计用 MyBatis-Plus 的聚合查询就能写出来，不需要引入额外报表组件。管理员页面再配一张按日期排列的预约明细表，支持按美容师筛选，就足够支撑日常运营了。很多人在统计上过度设计，又是图表库又是定时任务，其实对于预约系统来说，实时查数据库算一次完全没有性能压力。
5. 实测踩坑：时区、逻辑删除与状态机边缘场景
5.1 LocalDateTime 序列化误区和数据库时区
预约系统离不开时间处理，这里最容易出现诡异 bug。踩过的坑有两个：一个是 LocalDateTime 通过 Jackson 序列化到前端时，默认格式是一长串带有字母 T 的格式，前端显示成"2025-06-07T10:00:00"，顾客根本看不懂；另一个是数据库连接串没配置 serverTimezone，导致时间整体偏移若干小时。
解决办法是在 application.yml 里面统一配置 String 序列化的时间格式，同时数据库连接串上写明 serverTimezone=Asia/Shanghai。所有时间相关的 Java 类型，能用 LocalDate 就用 LocalDate，不要用 java.util.Date，避免时区和格式化双重的混乱。预约日期这个字段我用的是 LocalDate，开始和结束时间用字符串"HH:mm"保存，这样做界面显示最简单，区间判断转成分钟数也很顺手。说实话，在预约类业务里，"日期用 LocalDate、时间用 String"往往是比 DateTime 更省心的方案。
5.2 逻辑删除和唯一索引的组合坑
逻辑删除看起来很简单，但和唯一索引组合在一起会有隐蔽的问题。预约单表加的唯一索引里包含状态字段，一条正常预约是状态 1，取消后变成状态 4，两者不会冲突。但如果有一天管理员发现某条预约单是重复数据，想物理删除它，或者开发环境里想手动清理测试数据，一旦删掉状态为 1 的记录，新的预约又插入相同的状态 1，这时候唯一索引就能通过，不会出问题。
真正的坑出现在你没把 status 纳入唯一索引的时候。比如只有 groomer_id、appointment_date、start_time 三个字段的唯一索引，那么一个被取消的预约会一直占着索引位，同一天同一个美容师同一个开始时间再也无法创建新的预约。我在早期设计时踩过这个坑，后来把 status 加进索引，同时把"取消"操作封装成 Service 方法而不是直接 UPDATE 状态字段，就是为了确保所有取消路径都遵循同一套规则，不会绕过检查直接把数据库改坏。
5.3 状态机边缘场景：重复取消、补单与时段释放
预约系统上线后，真正难处理的不是正常流程，而是边缘场景。第一个是重复取消，顾客在待确认状态下点取消，接口执行更新，状态从 0 改成 4。如果前端按钮没有防抖，或者顾客连续双击，第二次请求进来时订单可能已经是取消状态，不能再执行一次取消逻辑。解决办法是更新 SQL 里带上状态条件 UPDATE appointment_order SET status = 4 WHERE id = ? AND status = 0，影响行数为 0 就说明状态早已变化，直接返回友好提示。
第二个是美容师手动补单，门店偶尔会有顾客到店直接洗狗，不经过线上预约。为了让当日营收统计完整，我在美容师端加了一个"补录订单"功能。补单没有排班约束，但也会占用一个时段，核心逻辑依然要检查区间冲突。这个功能真正把系统的线下场景打通了，统计数字也更有说服力。
第三个是时段释放的联动问题。取消预约后，排班表里对应时段要变回空闲，这个动作必须和订单状态更新在同一个事务里。如果先改订单再释放排班，中途抛异常事务回滚，两边数据还能保持一致；如果拆成两个独立方法分别执行，很容易出现订单取消了但排班还锁着，顾客再也约不了这个时段的情况。我在测试时故意让释放排班的方法抛出异常，确认了整个事务确实能回滚，才敢把这个逻辑放上线。
边界条件还有一层：凌晨时段和跨天处理。宠物美容一般不做跨天，但服务结束时间有可能正好卡在排班表收工时间之后。比如排班只到 18:00，某个服务时长 90 分钟，17:00 开始就要做到 18:30，排班表生成时要自动过滤掉这种"结束时间超出可用范围"的起约时间点，否则顾客选完之后美容师就得加班。
回到最开始说的那句话，预约系统的难点从来不是 CRUD，而是资源冲突和状态流转。把排班表、预约单表、状态机三者之间的关系理清，再配合数据库唯一索引兜底并发，这套系统就已经有了真正能用的底子。我在实际测试中反复验证过：两个浏览器同时抢最后一个时段，结果只有一个成功，另一个收到"该时段已被抢走"的提示；美容师取消一个预约后，顾客端立刻能重新约这个时段；即使误删了状态记录，逻辑删除也没有让统计报表崩掉。把这些细节处理干净，比把页面做得花哨重要得多。
最后再分享一个小技巧：开发阶段可以写一个简单的并发测试脚本，模拟十几个线程同时提交同一个美容师同一个时间段的预约，观察有多少能成功。我最初跑出来 5 个成功，说明代码里基本没做并发控制；数据库加上唯一索引之后再跑，稳定只剩 1 个成功。这个测试脚本非常简单，但能让你在演示之前就把最大的隐患暴露出来，建议你在项目验收之前也跑一遍。
