位置更新可以连续发生，配送阶段却未必跟着改变

一段配送记录不断出现新消息，是否说明包裹在不断跨入新的配送阶段？Uber Direct的Courier Update Webhook文档给出的对象是配送员位置更新。原文说，分配配送员、配送status进入pickup之后，这类event.courier_update每20秒发送一次，载荷中带有位置和最新配送信息。[1]

这里同时存在周期与阶段。周期解释文档安排何时继续发送位置消息，阶段解释这笔配送处于怎样的流程位置。连续消息可以发生在同一阶段之内，所以“又来了一次更新”不能自动转述为“又完成了一个配送环节”。本文只读公开文档，没有接收真实消息，也不把20秒当成现场一定准点的网络表现。

载荷的结构进一步把两个对象连起来。外层记录这次位置更新事件，data则带有最新配送信息副本；表格分别说明location中的纬度、经度，以及data里的status。位置和状态可以在同一条消息中出现，却没有因此变成同一种信息。坐标变化本身不能代替取件完成或交付完成的相应记录。

时间也需要放回这一结构。Fields Definition把外层created解释为事件产生时刻，Data Object Definition里的created则是配送建立时刻。假设同一笔配送后来产生多次位置更新，整理者可以同时记录配送的建立时间与每条消息的产生时间。这个假设不含真实坐标和订单，也没有要求修改接口；它说明为什么两处同名created不宜被摘成没有对象的一个“创建时间”。

用于客服或交接资料时，这种读法可以把描述写得具体：谈位置就说明是一次位置事件，谈进度就沿用配送状态的定义，谈时间就指出它属于事件还是配送。它帮助理解已取得的信息，不替任何实际货件判断在哪里、为何停留或何时送到。本篇也不从位置数据推断配送员的行为原因。

采用范围限于本次读取的Uber Direct文档，首次发布日期未知。页面示例带有演示数据，本文未将其中地址、电话、时间或内外不一致的live_mode标记作为真实事实使用；也没有提供接口接入、签名认证、追踪或权限配置。持续更新具有自己的资料含义，只有保留位置事件与业务阶段的关系，才不会把信息刷新写成履约已经推进。