SpringBoot3Vue3 会议室预订系统时段冲突三模式检测 会前定时提醒与 cancelByBiz一句话冲突检测保证「不会撞房」消息中心保证「会前能叫人」cancelByBiz保证「改期后不会按旧时间继续轰炸」。开源仓库GitCode · RuoyiOfficeAtomGit · RuoyiOffice和「会议室总览文」有何不同已有专题讲过会议室建档、预约网格、是否审批等产品闭环。本文只打两块最容易在二开里写砸的技术点时段冲突的三种重叠模式漏一种就撞车审批通过后的会前定时提醒对接统一消息中心 改期取消模块总览可对照业务链一眼看清保存/提交预定 → 校验开始时间非过去 → validateTimeConflict三模式 SQL → 按会议室配置决定是否走 Flowable │ ├─ 驳回 / 取消 → cancelMeetingReminder └─ 审批通过 onProcessApproved → registerMeetingReminder cancelByBiz(旧提醒) MessageSendApi.send(sceneCode, planSendTime)提醒失败只打日志不回滚已通过的审批——与「单据状态先提交、副作用可失败」同一纪律。一、时段冲突三种重叠必须全覆盖设已有预约区间[S1, E1)新建[S2, E2)。任意一种成立即冲突模式条件口语查询意图左交叉新开始落在旧区间内S1 ≤ S2 E1右交叉新结束落在旧区间内S1 E2 ≤ E1包含新区间包住整段旧预约S2 ≤ S1 且 E2 ≥ E1实现上对同一会议室、状态为「待使用/使用中」的单据做OR三段条件更新时要排除自身 id否则改自己的备注也会「和自己冲突」。// 概念伪代码与实现结构一致wrapper.eq(roomId).in(useStatus,待使用,使用中).and(w-w.or(/* 新开始落在旧区间 */).or(/* 新结束落在旧区间 */).or(/* 新包含旧 */));// update 时 filter id ! self常见坑坑后果对策只判断「开始时间相等」交叉重叠漏检三模式全写闭开区间不一致11:00 结束与 11:00 开始误报/漏报统一半开区间约定并单测边界把「审批中」也当占用并行申请全被挡产品决策占用以审批通过/待使用为准本实现看 useStatus更新不排除自己改标题即冲突id ! current建议补 4 条单测左交叉、右交叉、包含、背靠背10:00-11:00 与 11:00-12:00 应允许。二、会前提醒接到统一消息中心审批通过后resolveRemindMinutes(reminderType) // 如 15/30/60 分钟字典可配 planSendTime meetingStartTime - minutes 若会议已开始 → 直接 return cancelByBiz(bizType, bookingId) // 先清旧的待发送 组装 params主题、房间、时间、主持人… MessageSendApi.send( sceneCode 会议提醒场景, bizType / bizId, receiverUserIds, planSendTime, params )接收人默认主持人 申请人 与会人。去重交给消息中心业务侧把能解析的 userId 塞进列表即可。为什么必须先 cancelByBiz场景不做 cancel做了 cancel会议从 14:00 改到 16:00 再批过14:00 与 16:00 各推一次只剩 16:00 前那一次驳回后再次提交通过可能叠多条 WAIT旧 WAIT 取消再注册流程取消人已不开会仍收到提醒onProcessCancelled里取消bizType固定为会议室预订业务类型bizId用单据主键——与消息中心「按业务取消」契约对齐。提醒与主流程解耦try{registerMeetingReminder(booking);}catch(Exceptione){log.error(注册会议提醒失败不影响审批结果,e);}消息中心故障时会议室占用关系仍然成立运营可事后补发或修 Job。三、和消息中心文章的衔接统一消息中心提供sceneCode、实例、SendLog、定时 Job、cancelByBiz。会议室模块是业务调用方只负责算planSendTime、拼 params、选接收人。会议室侧消息中心侧何时提醒、提前多久到点谁发、哪个渠道冲突检测不参与审批状态回调只消费 send/cancel API场景模板文案「您有会议将于 {startTime} 在 {roomName} 开始」配在消息场景/原生模板改文案不用发版 Java。提醒类型与分钟数字典如oa_meeting_reminder_type与后端switch对齐不提醒 / 会前 5 / 15 / 30 / 60 分钟等。前端选项变更时务必同步resolveRemindMinutes否则出现「选了 30 分钟却按 15 推」的幽灵 bug。planSendTime若已早于当前时间例如会前 60 分钟但用户在开场前 10 分钟才批过策略可以是立即发一条或放弃提醒。本实现选择「会议未开始仍按 plan 注册若开始时间已过则不再注册」——批得太晚可能收不到会前短信产品上可在通过瞬间补发「即将开始」。四、前端体验要点Vue3提交前可用「空闲查询」减少硬错误最终以服务端冲突校验为准。提醒类型用字典如会前 15/30/60 分钟与后端resolveRemindMinutes同一套值。改期重新走审批时提示用户「原提醒将自动取消并按新时间重注册」。列表展示占用状态避免用户以为「审批中也占坑」或相反。落地检查清单冲突三模式 背靠背边界有单测更新排除自身 id审批通过注册提醒驳回/取消调用 cancel注册前先cancelByBiz保证幂等消息场景码、模板、渠道已在租户配置提醒失败可观测日志关键字且不影响占用过去时间不可订已开始会议不再注册提醒FAQQ1审批中的单要不要占时段A产品策略。占则并行申请困难不占则可能两人同时批过——若选不占通过瞬间必须再做一次冲突检测防 TOCTOU。Q2提醒只站内信还是短信A由消息场景勾选渠道业务只传sceneCode。紧急管理层会议可勾短信。Q3与会人是外部邮箱怎么办A消息中心对裸地址仅短信/邮件需在接收人解析里区分系统用户与外部地址或会议模块先建访客账号。Q4循环会议A本期模型是单次预订。循环需生成多条 booking 或独立日程服务每条各自冲突检测与提醒。Q5时区A服务端统一存租户时区或 UTC展示再格式化planSendTime与meetingStartTime必须同一时钟。和 RuoyiOffice 的对应关系能力位置概念冲突检测 / 提醒注册OAMeetingRoomBookingService流程通过/驳回/取消钩子FlowBill 回调定时消息 / 取消MessageSendApi前端预约与列表web-antd 会议室视图完整后端GitCode / AtomGit前端GitCode · vben相关SpringBoot3Vue3 接口访问日志、统一消息中心场景编排、会议室预约总览。总结三模式冲突检测是预订正确性的底线更新务必排除自己。会前提醒应走统一消息中心的定时发送而不是业务里手写 sleep/本地 Timer。cancelByBiz 先取消再注册解决改期、重批、驳回的提醒残留。提醒是副作用失败可补不能绑架审批已通过的事实。⭐ GitCode · AtomGit 点星夏日活动攒积分。在线体验RuoyiOffice商业版源码授权联系页 · 企业微信RuoyiOffice关键词SpringBoot3、Vue3、会议室预订、时段冲突、MessageSendApi、cancelByBiz、会前提醒、Flowable