在上门服务类系统中，智能排班和时间冲突校验几乎决定了整个系统能否稳定运行。
一旦排班出错，轻则客户体验下降，重则直接造成投诉和订单损失。
本文将结合开源上门预约系统源码的常见设计，拆解排班与冲突校验的实现思路，并给出可落地的代码示例。
一、为什么智能排班是上门预约系统的核心能力？
与到店预约不同，上门服务存在几个天然复杂点：
- 服务人员数量有限
- 每个服务项目时长不同
- 服务地址存在路程成本
- 同一时间只能服务一个客户
这意味着系统在创建预约时，必须同时判断：
这个时间点，有没有合适的人能接这单？
这正是智能排班要解决的问题。
二、智能排班的基本设计思路
在大多数开源上门预约系统中，排班逻辑通常遵循以下顺序：
- 匹配技能（会不会做）
- 匹配时间（有没有空）
- 校验冲突（是否重叠）
- 返回可选人员列表
系统并不“聪明”，只是把业务规则变成了可执行的判断条件。
三、核心数据模型设计
1️⃣ 服务人员表（staff）
CREATETABLEstaff(idBIGINTPRIMARYKEY,nameVARCHAR(50),skill_tagsVARCHAR(255),statusTINYINTCOMMENT'0停用 1可接单');2️⃣ 排班表（staff_schedule）
CREATETABLEstaff_schedule(idBIGINTPRIMARYKEY,staff_idBIGINT,work_dateDATE,start_timeTIME,end_timeTIME);3️⃣ 预约订单表（appointment）
CREATETABLEappointment(idBIGINTPRIMARYKEY,staff_idBIGINT,appointment_timeDATETIME,durationINTCOMMENT'服务时长（分钟）',statusTINYINT);这三张表，基本支撑了整个排班判断逻辑。
四、第一步：根据技能筛选服务人员
publicList<Staff>findStaffByService(LongserviceId){returnstaffMapper.selectByService(serviceId);}这一层只解决一个问题：
“谁具备这项服务能力？”
五、第二步：判断是否在工作时间内
publicbooleaninWorkTime(LongstaffId,LocalDateTimetime){StaffScheduleschedule=scheduleMapper.findByDate(staffId,time.toLocalDate());returntime.toLocalTime().isAfter(schedule.getStartTime())&&time.toLocalTime().isBefore(schedule.getEndTime());}如果不在排班时间内，直接排除。
六、第三步：时间冲突校验（核心难点）
时间冲突校验，本质是时间区间是否重叠的问题。
判断公式：
新预约开始时间 < 已有预约结束时间
且 新预约结束时间 > 已有预约开始时间
SQL 冲突校验示例
SELECTCOUNT(1)FROMappointmentWHEREstaff_id=?ANDstatusIN(1,2)ANDappointment_time<?ANDDATE_ADD(appointment_time,INTERVALdurationMINUTE)>?只要返回值大于 0，就说明存在冲突。
七、综合排班算法示例
publicStaffmatchStaff(LongserviceId,LocalDateTimetime,intduration){List<Staff>staffList=findStaffByService(serviceId);for(Staffstaff:staffList){// 是否在排班时间内if(!inWorkTime(staff.getId(),time)){continue;}// 是否有时间冲突booleanhasConflict=appointmentMapper.existsConflict(staff.getId(),time,duration);if(!hasConflict){returnstaff;}}returnnull;}这就是一套可落地的智能排班核心逻辑。
八、优化方向：让排班“更智能”
在真实业务中，排班往往还会进一步优化：
- 距离优先（就近派单）
- 服务评分优先
- 当前订单量最少优先
- 多人可选，用户自主选择
这些都可以在上述逻辑基础上逐步叠加。
九、并发下如何避免“抢单冲突”？
在高并发场景，必须加锁防止两个用户同时预约同一时间段：
SELECT*FROMappointmentWHEREstaff_id=?FORUPDATE;或通过 Redis 分布式锁控制。
十、总结
智能排班和时间冲突校验，并不是复杂算法，而是：
清晰的业务规则 + 严谨的时间判断
一套成熟的开源上门预约系统源码，往往已经把这些坑都踩过，并沉淀成稳定可复用的逻辑。
如果你正在搭建上门服务平台，与其从零踩坑，不如基于成熟的源码方案进行二次开发，让系统更快上线、更稳定运行。
