联系支持

我们通过电子邮件回复,通常两天内。

为防止滥用,Google reCAPTCHA 会检查这次提交,其间会向 Google 传输数据。脚本只在你打开此表单时才加载。

← 全部文章

那些本可能被发回去的编号

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

检查的是一张表。

另外那张表

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

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

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

我们没有办法确定这是否已经发生过。通过这条路进来的访问,和其他任何访问看起来毫无区别。

两处改动

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

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

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

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

广告