计数器编号现在会对两张表都做检查

这里的每个计数器都有一个编号。它写在嵌入代码里、写在统计页地址里，也写在站长贴过它的每一个页面上。编号是这样发出去的：在 100 到 9 999 999 999 之间取一个随机数，然后检查它有没有被占用。

检查的是一张表。

另外那张表

长期没有访问记录的计数器会被移进一张归档表。这是普通的整理工作——它让活动表保持小巧，让针对它的查询保持快速。2026 年 8 月 24 日，归档表里躺着 212 771 个编号，而其中没有任何一个存在于生成器会去检查的那张表里。

也就是说，它们每一个都可能被重新发出去。

相对一百亿个可能的编号，这大约是 0.002% 的碰撞概率：大约每 47,000 个新计数器里有一个，会拿到一个曾经属于别人的编号。也就是说很少见，但并不抽象。计数器被归档，正是因为它的页面安静了下来——但安静下来的页面不见得已经被删除。如果那段老嵌入代码还留在某个被遗忘的侧边栏里，而那个页面来了一个访客，这次访问就会落进陌生人的统计里，落在一个几年之后才创建的计数器上。

这是否真的发生过，从数据里无法确定：通过这条路进来的访问，和其他任何访问看起来毫无区别。能够确定的是另一件事——它不会再发生了。

两处改动

生成器现在两张表都查。而删除计数器——从同一天起站长可以自己完成的操作——会留下一块墓碑：一行只有编号的记录，确保它永远不会被再次发出。删除会在一次事务里清掉二十张表里的数据，不留副本，这本来就是删除的意义；编号是唯一一个必须继续被烧掉的东西。

为什么这件事一直没被发现

生成器是在只有一张表的时候写的。归档表是后来出现的，出于另一个原因，解决另一个问题，而没有任何东西把这两个念头连起来。两部分分开看都是对的。

这类事情多数长这个样子。不是某个人在某个具体位置犯了错，而是没有人站在能看见那个后果的位置上。唯一的防线是刻意去找，而找到这一个的问题相当平常：在动手做删除功能之前——计数器编号还住在哪些地方？