交付数据里的垃圾信息限制状态是什么意思

随登录凭据一起，交付内容里可能会带来批次供应商提供的辅助信息，垃圾信息限制状态就是其中一项。它原始的样子是一个数字，本身对买家什么也说明不了，所以交付时会用文字把它解释出来。这个字段有好几种状态，弄混的代价不小。

前五个值是状态码，后两个是时间。正因如此才需要文字解释：原始形态下 −3 和 −4 长得几乎一样，含义却不同，而用肉眼把状态码和日期分开同样做不到。

并不是每个商品都会带这个状态：这是供应商的数据，供应商没有传的地方，状态就仍旧未知。空字段的读法和「未检查」一样 — 是信息缺失，而不是信息里比较好的那一种。

字段本身描述的是交付那一刻，而不是你打开订单那一刻。读表格最后一行时这点很要紧：过去的日期意味着限制曾经存在并且已经结束，而不是它马上就要开始。

这是最常见的读错。「未检查」这个状态只说明一件事：没有人看过。它既不主张有限制，也不主张没有限制，不能往对自己有利的方向解读。如果这个状态对你的任务是关键的，就挑那些已经标注了状态的商品，或者在 30 分钟窗口里自己去查这一批。

反过来的情形也有：字段显示了一个日期，而这个日期已经过去。这是「已解除」状态 — 限制曾经存在，但期限已满。这里过去的日期不是问题的信号，而是问题已经结束的信号。

靠自己在窗口内查清状态很难：限制不是在登录时显露，而是在动作时显露，30 分钟不够做这种检查。所以交付里的状态不是你那次检查的副本，而是验收时唯一拿得到的信号。

「未检查」和「无垃圾信息限制」之间的差别是要花钱的。前者是信息缺失，后者是检查的结果。挑商品要按后者来挑，而不是按「字段里看不到坏消息」来挑。

商店的保障负责两件事：交付那一刻账号与商品描述相符，以及所交付数据的完整性。垃圾信息限制状态是这些数据的一部分，所以查它的时间和查登录的时间一样：购买之后的 30 分钟以内。

• 马上看状态，而不是导入软件之后再看 — 更换窗口是从购买那一刻开始算的。
• 垃圾信息限制和登录是否有效是两回事：账号可能进得去，同时又受到操作限制。
• 商店明确说明，交付之后账号的表现不作保证：接下来发生什么，取决于怎么用它。
• 如果数据与商品描述不符 — 客服机器人、订单号、商品编号。

状态最好和数据行的字段构成一起读：两者都能直接在交付内容里看到，不需要登录账号。登录是为了验证有效性，而配套和限制读起来更早也更快。

关于期限还有一个要紧的细节：日期在未来的限制，不会因为你登录了账号就取消。它只会在指定的那天到期。保障负责的是数据与商品卡片相符，而不是保证根本没有限制。

结论很朴素：垃圾信息限制状态是拿来做计划的，不是拿来硬闯的。带有明确解除日期的账号，合理的做法是放到那一天再用，而不是马上就上手 — 在限制期内加负载不会有好结果。

• 日期在未来 — 合理的做法是把这个商品放到那天，之前不要预热。
• 「永久垃圾信息限制」是没有期限的状态：根本不该指望它解除。
• 「垃圾信息限制已解除」 — 限制曾经有过并且已经结束；验收时这是正常状态。
• 「未检查」 — 就按状态未知来规划，因为它确实就是未知。

按状态做计划比想象中简单：它把一批账号分进三个筐 — 现在就能用、放到某个日期、根本不要指望。在验收时把数据行分进筐里，比在导入到一半时才发现限制便宜得多。

另外要单独记住带 FROZEN 标签的那个分类：那里账号的状态直接写在商品名称里，也已经算进了价格。这和垃圾信息限制不是一回事，但逻辑相同 — 是购买之前就知道的商品属性，而不是缺陷。

供应商随批次给出的数据比买家看到的多。有一部分字段是有意截掉的，在数据行进入订单之前就截掉了，这不是信息丢失，而是一道过滤：进入交付的是与账号有关的东西，而不是采购内部流程的东西。

• 「success」 — 供应商系统应答的辅助标志。
• 「raw」和「raw_item」 — 供应商的原始应答全文，未经处理。
• 「item_id」 — 供应商那一侧商品记录的内部编号。
• 「price」 — 供应商的内部价格字段；你看到的价格在商店的商品卡片里。

知道这道过滤只有一个理由。如果你拿收到的数据行去和别处从供应商那里看到的对照，字段集合是对不上的 — 这在预期之内。缺的那些字段没有丢，它们只是与你的账号无关。

公开 API 给出的是同一套字段：目录的应答里没有供应商的辅助标志。照文档写出来的脚本看到的，和买家在个人中心看到的完全一致 — 交付内容的构成不取决于购买方式。

验收时由此得出一条简单规则：不要在交付里找那里本来就不会有的字段。所有与账号有关的东西 — 就是商品名称里写明的那个格式下的登录凭据，外加垃圾信息限制状态。与这套构成不符，才是写给客服的理由，而不是去供应商那里找缺失的字段。消息很短：订单号、商品编号，以及缺了哪个字段。