Walmart 支持多包裹更新后，订单系统该先改哪里？

新公告改变了接口能力，没有替你修复整条链路

Walmart 美国站 11 月 2 日公告说明，订单管理中的 Ship order lines API 支持多包裹发货更新，也支持修改和取回多个运单信息。公告还要求卖家检查下游系统是否能够保存和展示这些信息。这份消息的范围是特定接口能力，不等于所有站点、全部履约产品同时改变。

对家具、套装或需要分箱配送的商家，最容易被忽略的环节往往不是发货按钮，而是按钮后面的数据关系。仓库知道发了三箱，客服系统却可能只读取第一条运单；顾客收到其中一箱后，订单页面已经显示完成。接口支持更多信息，只是消除了一个技术瓶颈，业务流程仍需要自己接住。

依据 [1] Walmart Developer

应当拆开的是订单状态与包裹状态

下面是本站建议的内部建模方式，不是 Walmart 的字段定义：订单保留购买项目与预期包裹数量，包裹记录自己的运单、承运方和状态，再把包裹与订单项目关联起来。只有满足业务预先定义的完整条件，才汇总成整单完成。状态缺失时应显示待核对，而不是自动推断已经送达。

一个自拟场景可以说明区别：同一套桌椅分为桌面、桌腿与椅子三个包裹。前两箱签收，第三箱仍在运输。此时可以向顾客解释两箱已到、一箱在途，并指明剩余部件；不能只因为一个包裹签收就关闭整个售后问题。若包裹拆分是临时发生的，也应保留拆分原因与操作时间，供后续追溯。

先验收异常分支，再验收顺利送达

上线前值得用隔离数据演练的，不只是一次提交成功。团队应分别检查：第二个包裹稍后补录、运单号更正、接口回调重复到达、一个包裹退回，以及顾客先收到部分商品。测试要同时查看仓库、订单页面与客服界面，避免某一端接受了多条运单，另一端仍把后来的状态覆盖到同一个位置。

对重复回调，我们建议先使用稳定的业务标识判断同一状态是否已经处理，再决定是否提醒顾客。对更正运单，应记录旧值与新值的关系，不能静默抹去历史。这里提出的是系统可靠性原则；实际调用格式、可编辑范围和错误码仍要以当前官方接口文档及账户权限为准，不能把本文当成完整接入规范。

依据 [1] Walmart Developer

资料日期也要拆开，别把旧指南说成新政策

配套的 Marketplace Learn 页面标注的是 2026 年 8 月 20 日更新；11 月 2 日才是本次接口公告日期。两份资料解决不同层次的问题。引用时应保留这种差别，也不宜因为看到一篇指南就宣布其他履约服务已经支持相同方式。文档更新日期本身并不是首次开放能力的证明。

我们的优先级建议是：先确认实际站点和配送方式，再检查数据能否无损往返，最后才优化客服文案。若商家本来只有单箱商品，这项能力未必值得立即投入大量开发；若售后争议经常来自分箱，完整包裹关系就可能比重新设计一个物流进度条更有价值。判断投入大小，应当以真实订单中的问题频率为依据。

依据 [2] Walmart Marketplace Learn