库存可用区块：库存、配送与履约

库存可用区块回答了买家最后一个操作性问题：**我能否获得这件商品，通过什么方式，以及何时能获得？**它将库存、配送、自提、预购备货和停产等信息集中在一个可提取的单元中，而不是分散在徽章、结账提示和配送政策页面之间。

为什么此元素重要

可用性不是安抚性文案，而是一个购买约束条件。选择好产品的买家仍可能放弃购买，如果页面无法回答所选变体是否可售、配送能否到达指定地点、或者能否在真实截止日期前送达等问题。精确的可用性在最关键的时刻减少了不确定性。

其心理机制关乎控制感，而非人为制造的紧迫感。“仅剩 2 件"可以帮助某人评估风险——前提是这个数字真实且及时。同样的信息如果持续多日不变、刷新后重置、或指向一个无法为该买家服务的仓库，则会损害信任。一个有用的区块应提供给读者采取行动所需的事实：当前状态、目的地、方式、时间、条件以及下一步可行操作。

机器可提取意味着爬虫、购物智能体、数据馈送或辅助技术能够保留变体与其履约事实之间的关联。绿色圆点配上"有货"在语义上是薄弱的：对哪种颜色、哪个地点、哪种方式、什么时间有货？一个有标签的区块可以保留完整的答案。

信息的新鲜度很重要，因为库存是动态变化的。内容系统应从商业数据源获取状态，而可见的时间戳和后备策略使得过期或不可用的数据可被检测。搜索引擎和 AI 系统必须看到与买家相同的实际状态；结构化数据无法修复自相矛盾的页面。

何时使用

当库存或履约情况影响读者是否能完成预定操作时，请使用库存可用区块。它适用于实体产品页面、库存影响选择的商品列表页面、票务或限量优惠页面，以及为智能体设计的商业数据端点。它也同样适用于自提、本地配送、定制生产周期、预购备货、预售和停产产品。

当尺码、颜色、包装、成色、卖家或地点改变结果时，应为每个可购买的变体单独渲染区块。如果产品系列显示"有货"而所选尺码不可用，这是误导。如果市场上有多位卖家，每个优惠都需要自己的价格、可用性、配送承诺和卖家身份。

下列常见但容易混淆的内容应保留在此元素之外：

• 服务团队的下一预约时段属于预约信息，而非库存可用性。
• 营业时间属于营业时间和联系方式信息；“正在营业"并不意味着商品有货。
• 软件功能的上线状态属于产品或版本发布文档，除非访问确实受容量限制。
• 促销的到期日是优惠条件，而非库存状态。
• 通用的配送政策说明适用于所有订单的规则；库存可用区块则将规则应用于具体商品、目的地和时间。
• 零售商诸如"发货快"的营销宣传不是预估，不应占据配送字段的位置。

元素编写规则 具有优先权：根据用途选择区块，而不是根据其徽章、卡片或手风琴样式。如果其主要功能是说明所选商品是否能获得以及如何获得，那么它就是库存可用区块。

放置位置

将主要区块放置在购买区域中，在买家选择了所有影响库存的变体之后、数量控件和购买操作之前。这个顺序让页面在呈现"加入购物车"之前先计算出一种真实的状态。如果变体控件位于价格上方，则将区块放置在这些控件之后，并用当前选择更新其无障碍名称。

在分类页面或列表页面上，直接在匹配的产品卡片内使用紧凑状态。除非卡片能够准确计算目的地相关日期，否则应链接至详情页面查看具体日期。在购买指南或评测中，将编辑限定性状态放置在商家和验证时间旁边；不要暗示发布方控制着库存。

当区块和价格指向同一个变体和卖家时，它们可以相邻放置。它不得与矛盾的徽章、针对不可用商品的已启用购买按钮、无关的倒计时器或基于其他目的地的配送声明相邻。请勿在状态及其下一步操作之间放置推荐语、促销轮播或交叉销售。不要将停产状态隐藏在评价下方，同时保留之前的购买控件可见。

移动端顺序必须保持：所选变体、库存状态、配送或自提选择、条件，然后是操作。粘性购买栏可以重复简短的状态，但必须来自同一数据源且不得与完整区块相矛盾。

构成要素

1. 上下文： 标识事实所适用的确切产品、变体、卖家和地点。
2. 库存状态： 使用一个受控状态，如有货、库存不足、缺货、预购备货、预售或停产。
3. 数量说明： 显示核实的数量或非数值的阈值标签；绝不制造稀缺性。
4. 目的地： 指明预估所使用的国家、地区、邮政编码或选定门店。
5. 履约方式： 区分配送、本地配送、自提和数字交付。
6. 配送或就绪时间窗口： 显示绝对日期或有上下限的时间范围，而非"很快”。
7. 截止时间与条件： 在相关时说明时区、下单截止时间、工作日假设、会员要求或最低订单金额。
8. 缺货政策与操作： 说明补货、替代品、预购备货、通知或归档策略。
9. 时效性与数据源： 记录状态核定时间以及提供该状态的权威服务。
10. 商业操作： 与状态匹配：购买、预售、加入等待名单、查找其他门店或查看替代品。

设计示例

每个变体都同时使用文字和颜色，保留所选商品上下文，并显示时间戳或实时数据源约定。

有货且提供履约选择。 当商品当前可售时使用。区分线上库存和门店库存，并为每种符合条件的履约方式显示一个预估。

库存不足。 仅在超过受控阈值时使用。仅在安全且足够及时的情况下显示精确数量；否则显示"库存不足"并保留时间戳。

缺货，预计补货。 除非接受预购备货，否则禁用立即购买操作。仅在营销或供应数据支持的情况下显示预计时间范围。

预购备货或预售。 保持这两种状态的区分。说明付款授权或扣款时间、预计发货或发布日期、取消条款，以及混合购物车是否分开发货。

停产。 移除活跃的购买控件和活跃优惠标记。保留有用的规格和支持信息，仅在关系经核实后标注官方替代产品。

门店自提。 指明门店名称、可取时间、预约保留时长及任何身份验证要求。当买家需要前往时，“附近有货"是不够的。

参数

下文中的"来源"指渲染器获取该值的位置。商业系统仍对底层声明负责。

受控状态映射到商业系统的真实情况，而非展示效果：in-stock、limited、out-of-stock、backorder、preorder 或 discontinued。渠道特定的值如 collection-only 属于 method，因为一件商品可以有货同时仅限自提。

语法与代码示例

以下三种形式编码了相同的所选 SKU、状态、配送范围、数据源和操作。项目在使用相应语法投入生产之前，必须先注册对应的 Hugo 或 WordPress 适配器。

可移植 Markdown 指令

:::availability{status=in-stock sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
:::

Hugo 短代码

{{< availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api" >}}
## Availability

In stock online and ready to dispatch.
Action: [Add navy Trail Jacket, size M to cart](https://example.com/cart/add/TJ-NV-M)
{{< /availability >}}

所有参数均为命名参数。该示例有意避免混用位置参数和命名参数。

WordPress

[availability status="in-stock" sku="TJ-NV-M" destination="US-10001" method="shipping,collection" earliest="2026-08-31" latest="2026-09-01" cutoff="2026-08-28T14:00:00-04:00" checked="2026-08-27T09:42:00-04:00" source="inventory-api,fulfilment-api"]
In stock online and ready to dispatch.
Action: <a href="https://example.com/cart/add/TJ-NV-M">Add navy Trail Jacket, size M to cart</a>
[/availability]

原生 WordPress 区块应将这些值存储为类型化属性，而非单一的富文本块。初始状态优先采用服务端渲染；客户端个性化可在获得同意或用户输入后优化目的地和预估。

好与坏的示例

好的示例

海蓝色 Trail Jacket，M 码 — 线上有货。 使用标准配送至 10001，预计 8 月 31 日至 9 月 1 日送达。美东时间 8 月 28 日 14:00 前下单。门店自提可用性需单独查询。库存与配送预估于 2026 年 8 月 27 日美东时间 09:42 核定。

这个示例效果好，因为它将状态与所选变体、目的地、方式、日期范围、时区和验证时间绑定。读者无需解读图标或打开通用政策即可采取行动。

坏的示例

🟢 抓紧！现在有货——卖得很快。即将配送。仅剩几件！

这个示例效果差，因为"有货"没有指明变体、卖家或渠道；“即将"没有目的地或日期；“几件"没有受控阈值；且紧迫感无法被核实。绿色图标也传递了文字中缺失的含义。将图标换成红色并不能弥补事实的缺失。

结构化数据标记与无障碍

对于真实可购买的商品，该区块可以通过 Offer 或 AggregateOffer 提供 Product.offers 数据。将受控的可见状态映射到对应的 Schema.org 可用性 URL，例如 InStock、OutOfStock、BackOrder、PreOrder、Discontinued 或 LimitedAvailability。价格、货币、卖家、商品成色和 URL 必须描述同一个优惠。不要仅仅因为其他变体或卖家有货就使用 InStock。

配送信息可以通过 OfferShippingDetails 提供：目的地、处理时间、运输时间、费用和符合条件的配送方式必须与可见承诺一致。对于停产商品，不要输出活跃的 Offer，也不要在可见操作变为等待名单后遗留过期的优惠标记。

结构化数据是商业状态的输出，而非第二个库存数据库。尽可能从同一个已核实的优惠生成可见区块、数据馈送和 JSON-LD。如果它们无法按相同的时间表更新，应在同步完成之前发布最不宽松的可防御状态。

无障碍要求每个状态都有文字标签；颜色、动画和图标可以增强但绝不能定义状态。将更新与所选变体关联。当变体或目的地变更异步更新区块时，不要意外移动焦点或阅读位置；通过配置合适的活动区域简洁地宣告结果。避免每秒重复宣告倒计时。

配送控件需要明确的标签，例如"配送邮政编码"和"更改自提门店”。日期必须包含文字的月份名称以防数字顺序造成歧义，截止时间需附带时区。已禁用的购买控件需附带邻近文字说明原因并提供有效的下一步操作。保持完整状态无需悬停即可查看，并在 JavaScript 失败时提供服务端渲染的后备方案。

编写规则

以 2 到 6 个词的受控状态开头：“线上有货”、“可预购备货"或"已停产”。接着说明后果：可立即发货、预计发布日期或已不再销售。每个所选优惠使用一个区块，而非每个仓库记录使用一个区块。

使用绝对的配送日期或有上下限的日期范围。如果预估因目的地而异，请注明目的地名称。如果没有可靠的预估，说明需要什么条件才能计算。通常、“很快”、“快速"和"应该到达"不能替代有来源的时间范围。

保持主要区块包含一行状态、1 至 4 行履约信息、一条政策语句（需要时 10–45 个词）以及一个主要操作。库存不足标签需要有经批准的阈值；精确数量需要有当前的来源。通过系统集成持续审查状态，并在每次内容 QA 周期中测试其后备方案。

使用冷静、操作性的语言。绝不包含编造的稀缺性、匿名的销量声称、无关的折扣、推荐语、保修详情、完整的退货条款或通用的配送政策文案。绝不将预售称为"有货”、将不可用商品表示为"可订购"而不说明是预购备货，或承诺履约系统无法支持的日期。

对于停产商品，应说"已停产"而非"当前不可用”。说明是否仍可获取支持、配件、手册或官方替代产品。

使用此元素的文章类型

postTypes 前置字段是实现矩阵的数据来源。

QA 检查清单

• 状态适用于所选 SKU、卖家、渠道和地点，而非产品系列整体。
• 库存、可售性、履约方式和配送时间是独立字段，且互不矛盾。
• 库存和履约来源具有权威性、受到监控，并在组件协议中注明。
• 核定时间存在且包含时区，并满足业务的新鲜度容忍度要求。
• 精确数量和库存不足标签使用受控规则，而非促销性紧迫感。
• 每个配送预估都注明或继承可见的目的地，并使用绝对日期或有上下限的时间范围。
• 预购备货和预售状态说明付款时间、预计发货或发布日期以及取消条件。
• 缺货和停产状态移除或替换即时购买操作。
• 可见内容、数据馈送、结账行为和 Offer 结构化数据描述同一种状态。
• 状态通过文字传达，动态变更得到适当宣告，控件具有明确的标签。
• 区块在无颜色、悬停、动画、个性化或 JavaScript 的情况下仍然有意义。
• 移动端和粘性购买处理源自同一数据源，并保持正确的阅读顺序。
• 所有三个语法示例映射到相同的类型化字段，不丢失来源或新鲜度数据。

常见问题解答

库存可用区块是否应显示精确的库存数量？

仅在库存系统具有权威性、数量更新足够及时且公开该数量不会带来运营或安全风险时才能显示。否则请使用受控状态，例如有货、库存不足、预购备货或缺货。切勿使用未经核实的数量制造紧迫感。

商品缺货时，区块应如何显示？

明确标注缺货，说明是否预计补货，如有核实的日期或时间范围则予以显示，并提供相关的下一步操作，例如到货提醒。当结账无法接收订单时，不得显示可购买的 Offer 或活跃的加入购物车操作。

预购备货和预售应如何区分？

预购备货指的是已有商品暂时无法立即履约；预售指的是尚未正式发售的商品。准确标注状态，说明付款时间，并给出预计发货或发布日期，同时注明任何不确定性。

库存可用区块是否需要 Offer 结构化数据？

不需要。即使没有结构化数据，可见区块也必须准确。当页面描述的是真实可购买的优惠时，其可见状态应与 Offer 的 availability 值及任何配送详情保持一致。编辑性提及和不可用的目录记录不得标记为活跃优惠。

配送预估是否可以按位置个性化？

可以，前提是已识别目的地，并且仍保留非个性化的后备方案。向辅助技术宣告动态变更，避免将 IP 定位视为确定性信息，并保持服务端渲染的库存状态对爬虫和无 JavaScript 用户准确无误。