取件窗与送达窗：城市配送的一段预约为何有两个时间范围

顾客看到一个配送预约时段，商户资料中却可能同时保存取件与送达两组时间。Uber Direct的Delivery Window文档解释了这种结构：delivery windows是有开始和结束的时间块，用来指导何时请求配送员履行配送订单。[1] 两个窗口围绕不同地点展开，并非同一时间被重复填写。

取件窗口对应希望配送员到达取件地点的时间范围。pickup_ready_dt表示开始，pickup_deadline_dt表示结束。文档在开始时间的解释中联系商品准备就绪，在结束时间的解释中联系可取件时段的边界。把它们放在一起，表达的是取件阶段的范围，而不只是一枚孤立的时间戳。

送达窗口则对应希望配送员到达送达地点的时间范围，dropoff_ready_dt和dropoff_deadline_dt分别表示开始与结束。[1] 同样写着ready与deadline，所属地点却发生了变化。因此，整理配送说明时，如果只留下一个没有标明阶段的“截止时间”，读者可能无法判断说的是取货还是交付。本文仅解释资料含义，不提供这些时间的设置方法。

这两组范围也不等于实际事件。一个计划中存在取件开始时间，并不证明配送员已经抵达；一个送达窗口已经列出结束时间，也不证明订单已经交到顾客手中。文档把它们定义为希望配送员到达的时间块，实际发生了什么需要另有事件记录。这里的分析只区分计划与事实，没有对任何真实货件判断是否延误。

文档将设置方式分为ASAP与Scheduled，后者称为商户驱动的预约方式。它还分别展示即时与预约情形的说明。这个分类提示，配送时间资料可以服务不同的订单情境，并非每个订单都要被解释成同一种预约表达。本篇不采用文档中的分钟数、参数约束或最优配置建议，也不由两个窗口推导固定运输耗时。

对于城市配送服务介绍，完整保留“地点阶段”和“起止范围”，能够说明商户正在表达什么期待：商品何时可供取走，以及希望何时送到另一地点。它与报价有效期、配送员已分配状态或交付证明分别有不同对象。本文依据Uber官方公开文档，原页发布日期未知，未调用配送接口或体验实际订单，因而不作速度、责任或准时交付承诺。