共计 1553 个字符，预计需要花费 4 分钟才能阅读完成。
一、方法概述
本方法旨在通过一套基于延时消息队列的自动化校验与提醒机制，提高网约车平台预约单司机的履约效率。核心流程包括“司机上线校验”和“司机迟到风险预测”两个主要环节，通过多次、分阶段的主动干预，确保司机准时提供服务，并在出现风险时自动执行改派，保障用户体验。
二、系统端核心处理流程
阶段一：订单创建与派单
S1（用户下单）：用户通过网约车平台下单，平台代理层组装下单信息并请求订单系统。
S2（订单创建）：订单系统处理请求，成功创建订单并返回订单号给平台代理层。
S3（发起派单）：平台代理层接收订单号，组装派单信息并请求派单系统。
S4（筛选司机）：派单系统接收请求，开始筛选合适司机。
S5（司机接单）：系统通知司机，司机成功接单后，订单状态更新为“待服务”。
阶段二：基于延时消息的多级司机上线校验
系统根据当前时间距离预约用车时间的长短，动态决定校验次数和时机。
S6（判断校验时机）：
是 (>120 分钟)：通过消息中间件（RocketMQ）发送延时消息，首次消费节点为：预约用车时间 – 120 分钟。
否 (≤120 分钟)：依次判断是否大于 90、60、30 分钟，并对应执行 3 次、2 次或 1 次校验。若已小于 30 分钟，则立即执行校验。
S7-S11（多级校验执行）：这是一个循环校验流程，具体如下表所示：
校验次数 触发条件 (距用车时间) 校验动作 (S8, S9, S10, S11) 未通过处理
第一次 120 分钟时 司机是否上线？是：转入迟到校验（S12）。
否：短信 / 电话提醒司机，并发送第二次延时消息（触发于 -90 分钟）。
第二次 90 分钟时 司机是否上线？是：转入迟到校验（S12）。
否：短信 / 电话提醒司机，并发送第三次延时消息（触发于 -60 分钟）。
第三次 60 分钟时 司机是否上线？是：转入迟到校验（S12）。
否：短信 / 电话提醒司机，并发送第四次延时消息（触发于 -30 分钟）。
第四次 30 分钟时 司机是否上线？是：转入迟到校验（S12）。
否：系统自动改派订单，记录原因为“预约单上线校验未通过”，标记司机有责并进行相应处罚。
阶段三：司机迟到风险预测与处理
司机上线后，系统预测其能否准时到达上车点。
S12（开始迟到校验）：司机在线校验通过后，立即启动迟到风险预测。
S13（计算预计到达时间 ETA）：系统根据司机的实时订单状态，智能计算 ETA。
情况 1：司机无其他订单。
ETA = 从司机当前位置到预约上车点的预计用时。
情况 2：司机存在“服务中”订单。
ETA = 完成当前订单（从当前位置到当前订单终点）+ 从当前订单终点到新预约单起点 的总用时。
情况 3：司机有其他“待服务”订单，但无“服务中”订单。
计算预计出发时间 = 最后一笔待服务订单的预约用车时间 + 该订单的预估服务时长。
ETA = 预计出发时间 + 从最后一单的下车点到新预约单的上车点用时 – 当前时间。
S14-S16（风险判断与处置）：
S14/S15（是否迟到）：判断 当前时间 + ETA 是否晚于 订单预约上车时间。
否（准时）：无风险，司机继续服务。
是（迟到）：计算预计超时时间。
S16（风险分级处置）：
预计超时时间 > 缓冲时间（Buffer）：系统判定司机无法准时到达，自动改派订单。
预计超时时间 ≤ 缓冲时间（Buffer）：系统向司机端发送 PUSH 提醒：“系统检测到您存在迟到风险，请尽快赶往乘客上车点”。
三、司机端操作流程
A1（订单展示）：司机接单后，订单出现在“待服务”列表，并标注为“接机员服务”。
A2（查看详情）：司机可点击“接机员”按钮，查看接机任务的详细信息。
A3/A4（订单改派）：
在满足条件的前提下，司机在服务开始前可主动改派订单。
不改派：正常提供服务。
改派成功：系统会向指定的接机员发送短信，通知订单已改派。短信内容包含：航班号、预计到达时间、乘客信息（姓名、手机号）以及新司机信息（姓名、手机号、车辆信息）。
