那次会让 180 个地址消失的整理

八月里有两天各带着十三篇和七篇文章。这个月其余每一天都带三篇。把它抹平看起来是五分钟的活，而它会让 180 个正常工作的地址停止服务。

一个未来的日期会做什么

这里的定时就是查询里的一个条件：只有发布时间已过的文章才会被取出。正是它让排队成为可能，同时也意味着一篇被挪到未来的文章不再存在。它自己的地址回 404，它离开列表，它离开站点地图。三者彼此一致，这是正确的设计，也正是问题所在。

每篇文章住在十二个地址上：十一条语言路径，加一条会协商的。十五篇被挪到前面，就是 180 个地址在新日期到来之前一直回 404。

谁会注意到

日志能精确回答。二十篇里有十五篇已经被采集器取过 — 每篇 21 到 38 次，其中五篇有 Googlebot，十二篇有 bingbot。这些是已经在某个索引里的页面。把它们变成错误好几天，不是整理，而是撤回再重新提交。

剩下的五篇从来没有被任何东西取过。挪动它们一点代价都没有，而这正是这次测量有用的那一半：不是定时危险，而是它只在还没有人看过之前是免费的。

答案的另一半

那五篇里有四篇照样挪不了，理由和采集器毫无关系。它们说今天、昨天、前一天 — 四篇加起来十三处这样的说法。一篇日期晚了三天却说「昨天」的文章，就是错的，而且一次错在十一种语言里。

往前挪的替代方案是往后挪，那更糟：这些文章就是在它们所标的那天写的。为了让日历看起来齐整而把它们提前，是对读者撒的一个小谎，只为讨好一张图。

我们改做了什么

对过去什么都不做，为将来做一件工具。新文章现在取每天三个的格子里下一个空位，而这件工具拒绝挪动一篇已经发布的文章，除非同一条命令说两遍 — 并且在那之前先报出会熄灭多少个地址。

不齐整的日子照旧不齐整。它们就是发生过的事。

这件事的一般化

一次改动的代价不在改动本身，而在被改的东西身上已经发生过什么。发布日期是一列里的一个数字，直到有人取过它所属的那个页面为止；在那之后，它是一个承诺。

这两半都在同一份日志里，而两半都不在代码里。