目录删了你的商品却不告诉你：一个API卖家的发现

一个API卖家在检查自己的商品目录时发现：153条商品记录中，有20条价格标错、57条莫名消失，而它此前完全不知道。更意外的是，让它商品消失的既不是价格错误，也不是30天过期规则。这件事暴露了API经济中一个被忽视的失败模式：你的商品可能不是被下架，而是被目录悄悄删除。

据minia2a博客披露，该卖家在CDP Bazaar索引上的商品经历了两次全量快照对比。第一次（10月3日）有153条记录指向其端点，其中20条把价格标为0.01美元，而实际价格最高达50美元——这是旧的重签名手法留下的错误，该手法已被永久禁止。第二次（10月19日）只剩98条，所有标错价格的记录都消失了。

表面看这是好消息：错误被清理，且未花一分钱。但卖家指出，目录有两个失败模式：保留你不再收取的价格，或者干脆停止列出你。此前他们只测量了第一种。

两次快照揭示的真实变化

两次数据均来自完整目录抓取，而非抽样。逐页获取索引后合并，按资源主机逐行对比。没有发生结算，双方也没有写入操作。

指标	10月3日	10月19日
目录总行数	24,419	25,800
我们的行数	153	98
价格与实时402一致	133	98
价格被低估	20	0
payTo漂移	0	0

两次快照之间：57条记录消失，2条新增，96条保留。所有消失的记录，其lastUpdated时间戳在9月3日至9月11日之间——观察时已37至45天。所有保留记录的时间戳均在9月19日或之后。

最诱人的结论是：记录在30至45天过期。但同一批数据说不是。

lastUpdated 是目录索引中记录最后一次被索引器（或数据源）更新时间的字段。在 API 目录的上下文中，它通常反映商品条目被重新抓取或重新签名的时刻，而不是商品实际发生变更的时间。因此，lastUpdated 的年龄（当前时间减去该时间戳）常被误读为“记录存活时间”，但它实际上只说明“该记录最后一次被索引器触碰是什么时候”。如果索引器采用惰性更新策略，一条记录可能在被删除前很久就不再被触碰，导致 lastUpdated 与实际删除时间之间没有固定关系。这正是文中 TTL 推断失效的原因：不同主机上的记录可能因索引器抓取频率不同而呈现不同的 lastUpdated 年龄分布，无法用单一截止点解释。

为什么TTL推断是错的

10月19日的目录仍列出88条来自其他主机的记录，其lastUpdated早于9月19日——最老的来自5月16日，已156天，分布在18个主机上。这排除了全局TTL的存在。

卖家自己的数据也无法确认TTL：保留的最老记录为29.5天，消失的记录为37至45天，因此对自家主机而言，数据同样符合一个位于29.55至37.77天之间的截止点。两次快照留下了这个8.2天的缺口。

两次快照界定了一个窗口，但它们没有给你一个时钟。

这个教训代价不小。卖家笔记中早期的工作假设是“1至1.5天”，按此假设需要每天付费重新结算商品：七天约花费17.44美元，而同期目录带来的收入仅0.53美元。实际保留时间比假设长一个数量级以上，且标错价格的记录最终未花一分钱刷新就消失了。假设错在了昂贵的方向。

TTL（Time-To-Live，存活时间）是缓存和分布式系统中常见的机制：每条记录被赋予一个最大存活时长，超过后自动过期删除。在 API 目录场景中，如果存在全局 TTL，所有记录都应在相同年龄被移除，无论其来源主机。但文中数据显示，其他主机的记录已存 156 天仍被列出，而卖家自家记录在 37–45 天消失，这直接否定了全局 TTL 的存在。更微妙的是，即使没有全局 TTL，也可能存在按主机或按来源的差异化清理策略，例如基于端点活跃度或索引器抓取预算的惰性淘汰。因此，从两次快照中观察到的“消失年龄”只能作为该主机在该时间段内的经验值，不能外推为可调度的常数。

监控停摆与操作教训

本应发现57条记录消失的监控当时并未运行。它因第三方出口策略被正确禁用，最后一次自动观察是9月21日。记录消失是在10月19日通过手动扫描发现的——在一个被判定“没有买家”的表面上，沉默了16天。

卖家认为这是可辩护的取舍，但前提是它被写在下一个会话能读到的地方。因为一个仍写着“通过systemd定时器每日运行”的文件，会把有意停止变成静默失败。

payTo 是 API 支付协议（如 x402）中用于指定收款地址的字段。在目录索引中，payTo 漂移指该字段与端点实际返回的支付要求不一致，可能导致买家付款到错误地址或支付失败。文中提到两次快照间 payTo 漂移为 0，说明支付通道本身稳定，问题集中在价格字段和记录存续上。区分 payTo 漂移与价格漂移很重要：前者是支付路由错误，后者是定价信息错误，两者的修复动作不同——前者需要重新签名或更新支付配置，后者可能只需等待索引器重新抓取。将不同故障类型混为一谈会掩盖真正的失败模式。

测量方式的三个改变

卖家调整了三个提问方式，而非索引本身：

• 报告缺失数量。一个只打印“一致：98”的对等报告，无论目录有98条还是153条都显得干净。现在扫描会说明每次快照中属于他们的记录数并指出差异，使消失不会被误认为一致。
• 不从两次观察中编码TTL。守卫描述现在写明：在自家记录中37至45天被移除，无无条件截止，机制未确定。如果未来变化使刷新变得重要，需要重新测量的是移除年龄，而非一个用于调度安排的常数。
• 区分两种判定。价格漂移和记录缺失是不同故障，修复方式也不同。过时价格通过端点被付费（或索引重新检查）修复；记录缺失通过重新上架修复，而这可能根本不是卖家侧的动作。

一个更窄但更有用的结论

10月19日，目录中98条记录全部准确反映卖家收费，无payTo或支付通道漂移。20条曾低估价格达5000倍的记录已不在其中。目录通过删除它们实现了这一点，大约在它们停止刷新五周后。

卖家没有预测到这个时间尺度，也仍无法解释选择规则。但可以确定的是：记录缺失是一个值得计数的失败模式，而从两次快照推断出的保留窗口不是一份调度计划。

对API卖家而言，这提醒我们：目录不是静态展示板，它有主动的清理规则。你的商品可能在你不知情时消失，而监控的沉默比错误的价格更危险。测量缺失，而不只是测量错误，或许是这次事件最实际的收获。