Shopify 新品首发与限量发售商品页配方
新品首发与限量发售商品页的任务是：开售时让顾客立刻看清能不能买、限买几件、名额怎样分配、买不到之后怎么办；开售前与售罄后则不制造「现在就能买」或「还会再有」的错误印象。它属于 product template type，是标准商品页的变体：媒体、概述、规格与评价沿用标准组合，本文只写发售规则带来的差异。
等候名单、预热节奏、分配方式与稀缺声明的经营规则见新品首发与限量发售；售罄后转为先收款后发货时，改读预售与订阅商品页。
三种状态由谁承载
一次发售在店面上经历三种状态。关键判断是：开售前不要把商品页当作预热页。
| 状态 | 承载页面 | 顾客任务 | 主要行动 |
|---|---|---|---|
| 预热（开售前） | Page（Campaign Landing）或活动集合 | 知道卖什么、什么时候开售、怎样提前收到提醒 | 加入候补名单 |
| 开售 | 商品页（本文） | 判断并在限购内买到 | 加购与结账 |
| 售罄 | 商品页（本文） | 知道是否补货、是否转预售 | 订阅到货通知，或无行动 |
为什么预热不放在商品页：帮助中心 Flash sales 页写明，商品一旦发布且有可售库存，顾客就能完成结账；主题改动隐藏「加入购物车」不应被依赖，预览用的商品应与活动中实际销售的商品分开。所以开售前对外展示一个已发布、有库存、只是藏起按钮的商品页并不可靠。较稳妥的做法是：
- 商品保持不对外发布，到点定时发布。帮助中心 Future publishing 页写明，商品、集合、博客文章与页面都可以定时发布；商品必须处于 Active 状态，按店铺时区发布，不能为单个变体设定发布时间。该页没有说明发布前访问商品地址会看到什么、能否经其他途径购买，开售前用无痕窗口实测。
- 预热放在 Page：单品或少量商品的发售，用一个 Page 讲开售时刻、价格、数量、限购与分配规则，并收集候补名单，组合按 Campaign Landing 配方。开售时 Page 改为指向商品页的入口；Page 本身也可定时发布。
- 预热放在活动集合：一次放出多件商品、开售后需要列表与筛选时，用活动与编辑型集合页；开售前集合里不能出现可购买的商品，同样以定时发布控制。
- 一定要提前展示商品页时：只用不可售的预览商品，与开售时销售的商品分开（Flash sales 页的建议），并在开售后撤下预览商品，避免两个同名商品同时被搜索到。
是否需要 alternate：默认不需要
按Alternate template 的判断规则逐条对照（核心条件：组成稳定不同、被一批资源持续复用、仅靠资源内容和 Section 设置不能表达）：
| 状态 | 与标准商品页的差异 | 能否靠内容与设置表达 |
|---|---|---|
| 预热 | 不在商品页发生（见上节） | 不涉及商品模板 |
| 开售 | 购买区旁多一段发售规则摘要：数量、每单限购、分配方式、取消超限订单的规则 | 能：一个规则摘要 Section 放进默认 product.json，文案来自商品元字段或 Section 内容，没有内容的商品不显示 |
| 售罄 | 售罄状态与到货通知 | 能：沿用库存状态与到货通知的统一词表，与任何商品相同 |
结论：一次或偶尔的首发、限量发售，差异只是一个可按内容显隐的 Section，属于判断规则中「差异只是单个 Section Setting」与「只有一个临时页面且默认模板已能完成」的情形，不新建 alternate。另一个实际理由是：alternate 需要逐个商品分配，发售结束后还要改回，多一道容易遗漏的操作。没有内容时 Section 能否完全不输出，取决于所用主题的实现，本文未核验，上线前在编辑器与前台各确认一次。
满足以下全部条件时，再考虑建立如 product.drop.json 的 alternate（后缀是主题自己的命名）：
- 品牌按固定节奏反复发售，一批商品长期共用同一种组成；
- 组成在结构上不同，而不只是多一个 Section，例如以抽签报名入口替代购买区、去掉推荐与交叉销售、固定加入发售时间线；
- 这些差异无法通过默认模板中按内容显隐的 Section 表达，或会让默认模板的设置变得难以理解；
- 商家清楚何时分配、何时改回默认模板。
官方 Alternate templates 页写明：alternate 按 template-name.template-suffix.file-type 命名，可分配给关联资源、在主题编辑器预览或用 ?view= 参数渲染，不能用 alternate 替换默认模板（核验于 2026-10-10）。
页面内容清单
| 优先级 | 页面内容 | 回答的问题 | 来源边界 |
|---|---|---|---|
| 核心 | 可售状态 | 现在能不能买这个变体 | 运行时数据：Liquid variant.available；不在文案里写死「有货」 |
| 核心 | 投放数量与是否补货 | 有多少、卖完还有没有 | 发售规则；可能补货时写「首批」而不写「限量」，见概念正文的稀缺一节 |
| 核心 | 每单或每人限购 | 我最多能买几件 | 发售规则；页面写的限制必须由系统执行，见下文「限购与防机器人」 |
| 核心 | 分配方式 | 先到先得还是抽签、名额怎样预留 | 发售规则；抽签报名在开售前进行，可能涉及抽奖规则，需要合规确认 |
| 核心 | 超限与疑似批量订单的处理 | 会不会被取消、怎样退款 | 开售前公布的规则，不能事后新增 |
| 核心 | 退换与发货时间 | 买到之后怎样 | 保证详情与配送信息；超卖延误按预售概念正文的发货时间规则处理 |
| 可选 | 剩余数量提示 | 还剩多少 | 只读真实可售量；读不到就删除 |
| 可选 | FAQ | 限购、取消、补货怎么处理 | FAQ 中与本次发售有关的子集 |
| 售罄后 | 补货决定与到货通知入口 | 还会不会有、怎样收到通知 | 确定补货才放通知入口，见下文「状态与退化」 |
页面组合
开售状态的顺序是待验证假设，差异集中在购买区前后：
| 序 | 模块 | 回答的问题 | 缺失时 |
|---|---|---|---|
| 1 | 媒体 | 商品是什么样 | 同标准商品页 |
| 2 | 购买区 | 选哪个变体、能不能买 | 不可删除 |
| 3 | 发售规则摘要 × Callout | 数量、限购、分配、取消规则 | 不可删除；必须在购买按钮附近、结账之前可见 |
| 4 | 概述与规格 | 是否适合我 | 同标准商品页 |
| 5 | FAQ | 限购、补货、取消 | 没有真实处理规则就不写答案 |
| 6 | 评价 | 别人怎么说 | 首发新品无评价时删除，不用旧款评价冒充 |
| 7 | 推荐与交叉销售 | 还可以看什么 | 开售高峰期默认删除，减轻页面负担 |
最小成立组合：媒体 → 购买区 → 发售规则摘要。
默认不出现：开售后仍在商品页显示的倒计时（截止时间不存在时）；写死的「仅剩 N 件」；「售完不补」之后又出现补货入口；关键限购条件只放在 FAQ 或弹窗里；为凑热闹叠加的订阅弹窗。
内容 × 展现形式
| 内容 | 首选形式 | 适用条件 | 退化方式 |
|---|---|---|---|
| 发售规则摘要 | 购买区旁的 Callout 或短列表 | 有投放数量、限购或分配规则 | 一两句静态说明 |
| 开售时刻（预热页上） | 带时区的静态时间，可附 Countdown Timer | 开售时刻由定时发布真实执行 | 只保留静态时间 |
| 剩余数量 | 购买区内的文字提示 | 读取真实可售量 | 删除 |
| 售罄状态 | 购买区内的状态文字与禁用按钮 | 变体不可售 | 按变体显示，不把单一尺码售罄写成整款售罄 |
| 到货通知 | Inline Form | 确定补货 | 不补货时删除，只写「已售罄」 |
限购与防机器人
页面上写的限制必须由系统执行，只在主题里把数量选择器的上限调小、或隐藏按钮，挡不住直接调用加购或结账的请求；这一点与 Flash sales 页「不应依赖主题隐藏加购来阻止购买」的提醒同理（此处是据该页作出的推论）。
| 需求 | 平台事实（核验于 2026-10-10） | 页面怎样写 |
|---|---|---|
| 每单限购 | Cart and Checkout Validation Function API 页把「在闪购中指定数量限制」列为用途，示例按商品元字段中的上限限制购物车中该商品的数量，错误在结账中显示，也通过 Storefront API 的 Cart 对象暴露；每个店铺最多启用 25 个校验函数。函数以应用形式部署，各套餐的可用性本次未核验 | 写「每单限购 N 件」，与函数读取的上限同源 |
| 跨订单的每人限购 | 上述页面的示例只针对当前购物车，没有描述按顾客历史订单累计限购 | 只能靠开售后审核实现时，写明审核与取消规则，不写成系统即时拦截 |
| 防脚本抢购 | Bot protection 页写明：仅 Shopify Plus 可用；只作用于 Online Store 渠道；在 reCAPTCHA 与 hCaptcha 中选择；单次活动最长 60 分钟；可保护全部商品或最多 500 个指定商品；按店铺时区开始；只用于削弱自动结账机器人，不针对其他与机器人有关的欺诈 | 页面不必提及；不承诺「杜绝机器人」 |
| B2B 数量规则 | Liquid variant.quantity_rule 返回变体的数量规则，没有规则时默认 min=1、max 为空、increment=1；它面向哪类顾客，本次所读页面未写明 | 不据此实现面向普通顾客的限购 |
加购被拒或超过限购时，购买区保留所选变体并说明原因，契约见购买区；结账前后的验证方法见购买验证。
状态与退化
- 开售前：商品不对外可见；预热页上的开售时刻与定时发布的时间一致，且为店铺时区。
- 开售瞬间：页面减负，去掉推荐、轮播与第三方脚本，性能检查见店面性能；缓存的预热页要在开售时同步改为指向商品页。
- 部分变体售罄：按变体显示状态，其他变体照常可买；Liquid
variant.available与variant.inventory_policy（deny为缺货停售，continue为缺货继续销售）决定按钮状态。限量发售的变体应为缺货停售，否则会超卖。 - 全部售罄、不补货：显示「已售罄」，不放到货通知入口；商品页可作为内容资产保留或下架，下架时注意外部链接与集合与发布中的可见性。
- 全部售罄、确定补货：显示「售罄，可订阅到货通知」，有真实到货计划才写日期。在已读官方页面范围内未找到面向顾客的官方到货通知订阅，实现需要另选方案，同意与隐私要求见库存状态与到货通知。
- 售罄后转预售：删除发售规则摘要，改按预售与订阅商品页组合，写明预计发货时间、收款时点与取消规则。
- 超卖：并发下单造成的超卖按事先公布的规则处理，防范见库存管理基础；页面不显示与实际可售量矛盾的「有货」。
- 跨市场：投放数量与限购是否按市场分配，在规则摘要中写明；没有该市场数据时不展示其他市场的条件。
- 无 JavaScript：可售状态、限购与规则摘要都是服务端输出的静态文字。
Shopify Theme 实现
| 层次 | 建议职责 |
|---|---|
| 资源 | 商品与变体保存价格、库存与库存策略；投放数量、限购上限、分配方式等发售规则可以放在商品元字段，见自定义数据，让规则摘要与校验函数读同一份数据 |
| Template | 默认 product.json；满足上文四个条件时才建立 alternate |
| Main Section | 购买区必须提交具体变体；售罄状态与禁用逻辑在这里实现 |
| Sections | 发售规则摘要作为紧邻购买区的独立 Section，没有规则内容时不显示；官方 JSON 模板页写明每个模板最多 25 个 Section、每个 Section 最多 50 个 Block |
| Blocks | 单条规则、单个问题 |
| Settings | 选择显示哪些规则字段；不提供手写库存数量或「仅剩 N 件」的设置 |
| 预热页面 | Page 或集合，按 Campaign Landing 或活动集合配方实现，用定时发布控制上线时刻 |
发布检查
- 开售前用无痕窗口确认：商品地址、集合、搜索与站点地图中都看不到可购买的商品，也无法下单；
- 定时发布的时间、预热页上的开售时刻、邮件与社媒公布的时刻为同一时刻、同一时区；
- 限购由系统执行：在购物车中超过上限时被拒，提示与规则摘要一致；
- 每个变体的库存策略为缺货停售，售罄后按钮与状态文字按变体正确变化；
- 预览商品（如使用）已在开售后撤下；
- 售罄后的决定（不补货、补货、转预售）已写好页面文案并同步给客服；
- 开售时段有值班与监控，页面已减负。
待继续完善
- 校验函数在各套餐上的可用性、跨订单每人限购的官方做法未核验。
- Future publishing 发布前商品地址返回什么、是否可经其他渠道购买，未在店铺中实测。
- 抽签式发售的报名页与抽奖规则的关系需要合规确认，可参考抽奖活动与正式规则页面配方。
- 缺少经真实发售验证的页面组合与开售记录。