加载整个 lib/ 实际要花多少
这个服务唯一入口文件的第 46 行： foreach (glob(__DIR__ . '/lib/*.php') as $f) { require_once $f; } 那是 65 个文件、1.5 兆字节，每个请求都要加载一遍。计数器图片、统计页面、404 — 一视同仁。昨天这件事发生了 20,734 次。 要紧的是那个小数字 把这一切从头加载一遍，关掉字节码缓存，大约要…
当缓存朝错误的方向增长
这个服务的缓存目录里有四个小文件。最大的一个 35 字节。它们合起来装着三个计数器编号，而且每一次计数器请求都会读它们。 它们存在，是为了让计数路径不必向数据库提四个几乎总是回答「没有」的问题。这个计数器排除站长自己的访问吗？统计外链点击吗？跟踪站内路径吗？自己重新加载吗？对超过 99 %…
加索引反而更慢的时候
存放每日数字的那张表只有一个键：计数器和日期合在一起。代码里有五处向它提的是另一个问题 — 不是「这个计数器随时间的变化」，而是「这些日子里的所有计数器」。首页的展示区、排行榜、站点地图、一张 90 天的图表，还有状态数字。日期列上没有索引时，它们每一个都要读完全部 114,113 行。 加上那个索引，展示区快十倍。我们没有加。下面是做出这个决定的测量。 一个查询快了很多…
数据库结构实际存在哪里
这个服务所做的一切都在版本控制里。至少代码是。它运行其上的数据库是 32 张表，其中 15 张在仓库里任何地方都没有定义 — 没有 CREATE TABLE，没有结构文件，什么都没有。一份备份能把 32 张表连同结构一起还原；仓库里缺的，是这份结构的第二份、独立的副本。 这些数字来自把运行中的数据库与仓库里的 736 个文件、5,671,710 个字符做比对。它们不是估计。…
为什么我们数不出回访者
Stats4U 里任何地方都没有回访者的数字。它缺席不是因为没人顾得上。它曾经被造出来，用真实数据跑过一次，又在 2026 年 8 月 27 日撤了回去，因为它给出的数字是 100.0% 首次访问 — 而且它会对每一个计数器、每一天、永远都这么说。 原因是散列里的一味配料。 日期是配料之一 不用 Cookie…
为什么我们的配置几乎全是注释
这台服务器上的 .htaccess 有 478 行。其中 98 行是规则。309 行是注释。 每一行做事的代码配三行解释。这个比例不是计划出来的；当写规则的规则是理由必须挨着它时，自然就会这样。 为什么一条重写规则需要一个段落…
我们如何检查每一份译文
这个博客有 64 篇文章，十一种语言：704 行，约 220 万字符。没有一篇文章在任何一种语言里缺失 — 这个说法只有在有东西强制它时才有意义。 确实有东西在强制。译好的一行写入之前，先与英文原文比对，不通过的行根本不会被写入 — 它会被报告出来，留给人看。 每项检查是干什么的 相同的链接目标。 内部路径在翻译时不能改变：/privacy 在每种语言里都还是…
为什么我们不给老用户发信
本服务的计数器表里存着 4,148 个电子邮件地址。它们属于过去二十年间创建的计数器，那时候计数器带着一个地址栏，人们就把它填了。 有三个人要求收信。 这两个数字就是这篇文章的全部。它们之间的差距不是一个需要填平的问题。它就是设计。 拥有一个地址，不等于有权使用它 这些地址是为一个目的收集的 — 找回对计数器的访问 —…
会跟着深色模式走的计数器
计数器是别人页面上的一张图片。当那个页面有深色模式时，图片并不知道：它是在服务器上画好的，那时访客的系统偏好甚至还不是一个事实。深色页面上一枚白色徽章是常见结果，看起来像个洞。 这里有十五个样式照样能应付。不是去问页面，也不靠 JavaScript——一行都没有参与。图片自己就切换了。 怎么做到的 SVG…
为什么 AI 不跑在我们的服务器上
为本站提供服务的那台机器上，没有跑任何语言模型。摘要是在第二台设备上算出来的，它去取任务、做完计算，再把句子送回来。 理由是算术。一个 3B 模型占用一个多 GB 的内存，每次回答要花几秒。而整个应用里最重的一次数据库查询是 581 毫秒。把两者放在同一块板子上，意味着 379 000 个计数器的图片要排在一个文本生成器后面等——而它们才是真正的产品。 代价和收获…
一句摘要必须跨过的门槛
这个摘要功能被送上过 2 061 个计数器。它写出了 262 句话。其余所有的任务都以同一个结果收场，而那并不是一条错误消息，尽管它是按错误归档的：数据太少。 一百次里有八十七次，答案是：没有。这不是缺陷，也不出人意料；这跟当初杀死看门人早期版本的是同一个发现，只是从另一个方向走来。 门槛在哪里…
AI 可以写什么，不可以写什么
在一个公开的统计页面顶部，这里可能有两三句话，描述这个计数器本月做了什么。它们是一个语言模型写的。模型在这里什么也不编造，而让这句话成立的那套安排值得描述一番——因为搭建这个功能的显而易见的做法，并不具备这个性质。 服务器跑 SQL，决定哪个数字值得一提，然后写提示。模型把一个事实变成一句所要语言的话。之后服务器把回答读回来，只要里面有一位数字不是来自提示，就把它扔掉。…