商城订单一多，客服经常要回答这些问题：为什么付款后一直没发货？为什么物流单号查不到？这笔退款卡在哪一步？
如果只能打开订单详情，再找仓库、财务和技术分别确认，一笔咨询就可能转好几个人。基于 Tigshop Java 版，可以扩展订单异常处理台，把需要跟进的订单集中列出来。
这个功能可以先从三四条明确规则做起，不必一上来搭复杂工单系统。
一、先定义哪些情况需要提醒
比如已付款超过约定时间仍未发货、创建运单后长时间没有揽收信息、退款提交后一直没有最终结果。
每条规则都要明确起算时间和排除条件。预售商品的发货时间可能更晚，用户申请暂缓发货也可能属于正常安排，不能全部按普通订单判异常。
阈值建议放在后台配置，并区分自然时间和工作时间。否则周末积压的订单周一全部变红，客服看了一屏提醒，却不知道先处理哪笔。
二、新增异常记录，保留原订单流程
异常处理台可以单独保存订单号、异常类型、触发时间、负责人和处理状态。原订单继续按现有交易流程运行，异常记录负责提示和跟进。
同一笔订单可能同时存在不同问题，因此去重条件可以按订单、异常类型和当前处理周期设计。定时任务重复扫描时，更新现有记录，不能每隔几分钟就生成一条相同提醒。
Java 后端可以结合定时扫描和业务事件处理：扫描发现超时，订单发货或退款完成后，再重新判断对应异常是否已经解除。
三、后台要让客服知道下一步做什么
只放一个红色“异常”标签，用处有限。客服需要看到超时多久、最近一次处理记录、当前负责人，以及建议检查的方向。
例如退款长时间未完成，可以展示退款申请时间和最新通道结果，引导有权限的人员查询；不能为了消除红点，直接把退款状态改成成功。
处理操作可以包括认领、添加备注、转交和标记已解决。涉及补发、退款或者重新推送的动作，则继续调用原有业务入口，并保留相应权限检查。
四、区分已跟进和已解决
客服填写“已联系仓库”，不等于订单已经发货。可以把“已跟进”和“已解决”分别记录，避免写了一条备注，订单就从列表消失。
一些异常能够自动解除，比如原本超时未发货，后来已经完成发货；另一些需要人工确认，比如物流显示签收，用户却反馈没收到。两类情况采用不同的关闭方式，记录解除原因。
提醒频率也要控制。新异常通知一次，超过处理期限再升级提醒，通常比每次扫描都推送更实用。
五、先试用，再调整误报规则
上线初期先让客服试用，观察哪些规则误报多、哪些信息仍然要跨部门追问。误报较多时，先核对阈值、订单分类和排除条件。
验收重点检查重复扫描、多人同时认领、异常自动解除和权限隔离。跨班交接时，接手人员应该能从记录里看出问题进展、最近操作和待办事项，不用重新问一圈。
六、SQL 示例：扫描超时订单并建立去重约束
超时阈值由业务配置计算，再以查询参数传入。以下仅演示普通现货订单的筛选结构，实际状态和排除条件需要按项目补齐。
SELECT id, paid_at
FROM demo_order
WHERE status = 'PAID'
AND fulfillment_type = 'NORMAL'
AND hold_shipping = 0
AND paid_at < #{deadline}
AND id > #{lastId}
ORDER BY id
LIMIT 200;
采用游标分页，并为扫描范围设置合理索引。每轮重新开始游标，避免永久跳过后来变成超时的订单。生成异常记录前再次校验状态，防止扫描结束后订单已经发货。
CREATE UNIQUE INDEX uk_order_exception_cycle
ON demo_order_exception(order_id, exception_type, cycle_no);
cycle_no 表示一次异常发生周期。重复扫描应更新本周期记录；问题解决后再次发生，才创建新周期。并发插入触发唯一冲突时，仅按这项约束加载现有记录，不要把所有数据库异常都当成重复处理。
客服认领也用条件更新：只有负责人为空且状态仍待处理，才能写入当前客服 ID。影响行数为零时提示已经被认领。异常关闭继续核对订单事实，不能靠修改异常记录来伪造发货或退款成功。
