任何售卖时效性商品的店铺，最终都会遇到同一个问题：配送日期选择器到底该放在哪里？
能找到的答案大多在讲怎么做，而不是放在哪里——这边一段主题代码，那边一个结账扩展。位置本身被当成细节。它不是细节。它决定了哪些顾客会给你日期、哪些顾客不留日期就走完流程，以及你在多少次情况下是在最不该知道的时候才发现。
一共三个位置。没有哪个是最好的。
你的 Shopify 套餐允许什么
从这里开始，因为它会在个人偏好介入之前先砍掉一部分选项。
| 位置 | 套餐 | 实现方式 |
|---|---|---|
| 商品页 | 全部 | 商品表单内的 theme app block |
| 购物车 | 全部 | 购物车页或抽屉中的 theme app block |
| 结账页 | 仅 Shopify Plus | Checkout UI extension |
Checkout UI extension 只在 Plus 的结账流程中运行。这是平台边界，不是应用的限制，没有哪个应用能绕开它卖给你。
有一点值得在这里理清楚，因为时间线容易让人误会。checkout.liquid 和 Additional Scripts 对非 Plus 店铺停止运行的时间是 2026 年 8 月。Plus 店铺早在 2024 年和 2025 年就已完成迁移。所以，如果你是因为最近结账页定制坏掉才找到这个问题，那你几乎可以确定在非 Plus 套餐上——对你来说，解决办法是商品页或购物车位置，而不是一个你根本无法运行的结账扩展。
商品页
日期位于加入购物车的表单内，因此在商品进入购物车之前就已选定。
当日期本身是购买决策的一部分时，选它。 周六约满了，为周六订的蛋糕就没有购买意义。一束赶不上 14 号的花不是一笔订单，而是一次失望。在顾客做选择的那一刻就展示可用情况，决定了这是一笔成交还是一次退款。
它也是唯一能扛住 Buy Now 的位置。因为它就在商品表单内部，使用动态结账按钮的顾客同样会带着日期走。
它的代价。 你在购物车还不存在的时候就要求顾客做出承诺，这是最早阶段的摩擦。而且在多商品订单上形态是错的：一次买四样东西的顾客不会想选四个日期，除非这些商品确实分开发货。
购物车
整张订单一个日期，在所有商品都进篮之后选定。
当日期适用于整张订单而非单个商品时，选它——每周的生鲜配送、一次餐饮订单、一次排定的集中送货。
它的代价，这一条最容易让人栽跟头。 Buy Now 按钮会完全跳过购物车。使用它的顾客直接落到结账页，你放在购物车页的选择器从未渲染过，那张订单到手时没有任何日期。你不会看到报错。你会看到一张排不进班的订单。
还有购物车形态的问题。Shopify 官方文档中那套购物车日期选择器方案只在购物车页面有效——帮助文章明确写着它不适用于抽屉式或弹窗式购物车。不少店铺是在因为别的原因换成抽屉式购物车之后，才发现这一点。
结账页 — Shopify Plus
选择器出现在最后一步，作为结账流程本身的一部分。
当日期是确认而非选择时，选它，或者当你希望通往购物车的路径保持干净时。它也是唯一能覆盖全部订单的位置，无论顾客走哪条路进来，因为所有人都要经过结账页。
实际操作中的坑。 把功能打开还不够。选择器只有在以下条件同时成立时才会出现：配送日期已启用、至少存在一条可用规则、结账开关已打开，并且区块已在 Shopify 的结账编辑器中放好。其中三项在应用里，第四项在 Shopify 里——这就是为什么「我打开了但什么都没发生」是这个位置最常见的问题。
它的代价。 顾客处在漏斗中最深的位置。在这里才发现某个日期不可用，是代价最高的时刻——这正是容量必须在更靠前的环节也生效、而不只是在最后一步把关的原因。而且它需要 Plus。
按商品还是按订单？
位置和日期粒度是两个决策，但彼此制约，各自独立决定往往导致店铺把这套东西返工两次。
按订单意味着整个购物篮一个日期。适合生鲜、餐饮、每周礼盒——凡是某天装一辆车出去的业务。购物车和结账页两个位置天然契合，因为到那时篮子里有什么已经确定。
按商品意味着每一行各带自己的日期。适合商品生产周期确实不同的店铺：现货靠垫明天就能发，旁边那张软包椅子要十周。这实际上只在商品页行得通，因为那是唯一一个顾客只看着单件商品及其交期的地方。
常见错误是采用按商品的日期，却在购物车里收集它们。同一个问题要问顾客好几遍，而收上来的答案又很难与一条配送路线对上。如果商品一起发出，一个日期才是诚实的模型。如果确实不一起发，就在商品层面把话说清楚。
没人提起的故障
去任何一个 Shopify 社区问一圈，你会反复看到同样的两个帖子：我在购物车选的日期没出现在结账页，以及日期没有保存到订单上。
这才是配送日期真正的风险，它与位置无关——它关乎这个值能否在一次次传递中存活下来。日期在店铺前台被采集，要传到结账页，要写进订单，还要到达你真正干活时看的地方：后台视图、订单标签、配送路线用的 CSV 导出。
任何一环断掉，选择器看上去依然正常。日历渲染出来了，顾客选了，订单也完成了。你是在打包台上才发现的。
在评估一种方案时——主题代码片段、应用，还是自研扩展——该问的不是「日历显示了吗」，而是：下一笔测试订单，然后在后台查这张订单、查它的标签、查 CSV 导出。 三处都有日期，这条链才算接住了。
如何选择
| 你的情况 | 位置 |
|---|---|
| 日期决定这单成不成（蛋糕、鲜花、活动） | 商品页 |
| 整张订单一个日期（生鲜、餐饮、每周礼盒） | 购物车 |
| Buy Now／动态结账用得很多 | 商品页，或 Plus 上的结账页 |
| 使用抽屉式或弹窗式购物车 | 商品页或结账页——依赖购物车位置前请先实测 |
| 日期是对先前选择的确认 | 结账页（Plus） |
| 希望每张订单都带日期，没有例外 | 结账页（Plus），并在更靠前的环节约束容量 |
| 不在 Plus，且结账页定制刚坏掉 | 商品页或购物车——结账这条路对你没有开放 |
多数店铺最终落在商品页或购物车。Plus 店铺通常会用两个位置，而不是一个。
在 OrderRules 中是怎么做的
三个位置读取的是同一套可用规则、备货时长、截单时间、休息日和容量。没有第二份配置需要维护，结账页也不可能与商品页显示得不一致，因为它们读的是同一个来源。
- 先前选定的日期会一路带下去。在结账页顾客是确认而不是重选；当商品各自带有日期时，结账页以只读方式展示以供确认。
- 容量处处生效。 已约满的日期在商品页选择器、购物车和结账页都会置灰。
- 日期会到达你真正干活的地方——保存到订单、作为订单标签添加，并包含在配送路线用的 CSV 导出中。
- 在 Plus 上，结账页位置是增量而非替代。在其他所有套餐上，商品页和购物车选择器与以往完全一样。
如果你的约束是某一天能做多少，而不是哪几天送货，那是另一项设置——见下单日期与配送日期，讲的是把每日上限按配送日期而不是下单日期来计。
坦白说的边界
有一点值得挑明，因为无论把选择器放在哪里它都成立。
容量在结账环节强制执行，在包括快捷结账在内的所有常规情况下都成立。它没有做的是加锁。结账校验读取的是已预订情况的快照，因此当某个日期只剩最后一个名额时，两位顾客在大致同一秒完成结账，是可能都通过的。
这需要在只剩最后一个名额的日期上出现几乎同时的结账，所以很少见。但并非不可能，因此当某个日期的容量很小时，值得留出一个名额的余量，而不是卡在精确上限。告诉你不是这样的应用，是在宣称平台并未提供的能力。
接下来读什么
- 结账页的配送日期 — Plus 位置，以及它需要的四个条件
- 配送日期入门 — 任何套餐都可用的商品页与购物车选择器
- Theme app block 设置 — 把区块放进你的主题
- 配送容量上限 — 日期约满时为什么会置灰
- 最好的 Shopify 配送日期选择器应用 — 如果你还在挑工具