2026-06-16｜订单关注 V3：发运集维度状态检测架构升级

1. V2 版本存在的问题#

前期订单关注 V2 采用订单级状态检测模式。但在实际业务中发现：

• 一个订单可能包含多个发运集（bundleIdMini）；
• 不同发运集具有独立物流状态；
• V2 仅保存订单级状态；
• 多个发运集状态会发生覆盖；
• 无法识别具体哪个发运集发生变更；
• 任意发运集到货即完成关注逻辑不合理。

2. V3 改造目标#

• 检测粒度升级至发运集维度；
• 发运集状态独立存储；
• 发运集状态独立推送；
• 支持预计发货时间变更通知；
• 支持发货通知；
• 支持到货通知；
• 所有发运集均完成后才自动结束关注。

1. 数据模型升级#

新增 bundle_snapshot_json 字段，用于存储发运集级状态快照。快照结构采用 JSON 形式保存每个发运集的状态与预计发货时间，实现精细化状态比对。

2. 发运集维度检测架构设计#

重新设计订单关注核心检测流程：

1
读取历史快照
2
→ 批量查询当前状态
3
→ 逐订单逐发运集比对
4
→ 推送通知
5
→ 写回快照

检测粒度由 订单号 → 状态 升级为 订单号 → 发运集 → 状态。

3. Mapper 层改造#

新增 batchSelectBundleStates() 实现按发运集维度批量查询：orderTid、bundleIdMini、stateName、deliverPredictDate、finalCustomer、productNames、expressNum，并统一订单关注与订单交付查询的数据来源。

4. Service 层改造#

完成发运集快照能力设计：

• parseBundleSnapshot() / toBundleSnapshotJson()
• batchGetBundleSnapshot() / batchUpdateBundleSnapshot()
• autoCompleteIfAllTerminal()：判断所有发运集均完成后自动结束关注

5. Scheduler 重构#

重构订单关注调度逻辑，实现：发运集检测、发货状态推送、到货状态推送、预计发货时间变更推送、发运集消失处理、全发运集终态自动完成。

发货通知#

包含：订单编号、最终客户、发运集编号、产品名称、发货时间、物流单号

到货通知#

包含：订单编号、客户名称、发运集编号、产品名称、到货时间

预计发货时间变更通知#

包含：原预计发货时间、新预计发货时间、当前状态、发运集编号

问题 1：多发运集状态覆盖#

• 原有结构只能保存单一订单状态
• 解决：升级为订单号 + 发运集双层结构，实现发运集独立检测

问题 2：自动完成逻辑不准确#

• 原有逻辑任意发运集到货即完成关注
• 解决：新增全部发运集终态判断机制，仅全部完成后自动结束关注

问题 3：推送内容缺乏定位信息#

• 用户无法判断具体哪个发运集发生变化
• 解决：推送文案增加发运集编号、产品名称、客户名称等关键信息