2026 年 4 月 25 日，Mastodon 实例 catgirl.cloud 上的用户 sophie 发帖称：“Web requests should not be measured in Hz”，理由是 Hz 通常用于周期性频率，而打到 Web 服务器上的请求更像随机事件，所以应改用 Bq，也就是贝可勒尔。
这是一条技术圈玩笑，不是行业标准变更，也不是正式规范提案。但它有意思的地方在于，笑点并不靠胡说。Hz 和 Bq 在量纲上都可表示“每秒一次”，差别在于使用语境：前者常和周期振荡绑定，后者来自放射性衰变计数。Web 请求恰好处在中间地带。
sophie 的玩笑踩中了单位语境的灰区
在工程实践里，请求速率常写成 requests per second、RPS，监控系统也会把它画成每秒变化的曲线。有人把它口头说成“多少 Hz”并非完全错误，因为 Hz 的基本单位就是 s⁻¹。问题在于，Hz 在日常技术语境里更容易让人联想到 CPU 时钟、屏幕刷新率、正弦波和周期信号。
Bq 同样是 s⁻¹，但它定义的是每秒发生一次原子核衰变事件。衰变不是按节拍来的，而是随机事件计数。这让它在语感上更贴近“请求到达服务器”的场景。
| 单位/说法 | 常见语境 | 用来描述 Web 请求是否成立 | 更准确的判断 |
|---|---|---|---|
| Hz | 周期频率、振荡、刷新率 | 量纲成立 | 语境容易误导 |
| Bq | 放射性衰变计数 | 量纲成立 | 玩笑上更贴切，工程上少用 |
| RPS | Web、API、负载测试 | 行业惯用 | 最清楚、最不惹歧义 |
| CPM | 盖革计数器、每分钟计数 | 可类比 | 梗成立，监控报表不常用 |
因此，这条帖子的判断不能写成“Hz 不能表示每秒事件数”。更准确的说法是：Hz 可以表示，但对非周期随机事件，Bq 的语境反而更有戏剧性的准确。
泊松过程让这个梗不止停在文字游戏
评论区很快把讨论延伸到 Poisson processes，也就是泊松过程。很多系统里的到达事件会被近似建模为随机到达过程，泊松过程是排队论、网络流量和可靠性分析里常见的入门模型之一。Web 请求也常被这样近似处理，尤其是在讨论平均到达率、排队长度、突发流量之前。
但这里有一个限制：不能说所有 Web 请求都服从泊松分布。真实流量会受推荐算法、缓存、爬虫、营销活动、时区和故障重试影响。一次热门链接传播带来的请求，往往成簇到达；一个前端 Bug 触发的重试风暴，更不会像理想泊松过程那样温顺。
这正是后端和运维工程师会会心一笑的地方。Prometheus 和 Grafana 里展示的 rate、irate、requests_total，本来就经常把离散事件压成平滑曲线。曲线让系统可读，却也掩盖了请求本身“啪、啪、啪”到来的颗粒感。sophie 后续回复里提到“Prometheus→Grafana→Geiger counter monitoring stack”，把这层荒诞感补齐了。
盖革计数器梗成立，但工程世界不会改口
评论区的主要延展，是把网站访问监控想象成盖革计数器：每来一次访问就响一下，有人提到 clicks，有人说 CPM like a real Geiger counter，还有人顺手把广告行业的 CPM 双关进去。CPM 在广告里通常是 cost per mille，每千次展示成本；在盖革计数里则可指 counts per minute，每分钟计数。
这类笑话的受众很明确：写后端、做 SRE、维护仪表盘的人最容易懂。因为他们每天都在把“真实事件”转换成“可视化指标”，再从指标里判断系统是否健康。对他们而言，单位不是装饰，而是模型假设的一部分。
接下来不用观察什么标准组织会不会采纳 Bq。更现实的观察点是：团队内部写监控文档时，是否把 RPS、QPS、rate、event count 说清楚。用错单位通常不会让系统宕机，但会让新人误解指标，尤其是在讨论采样窗口、突发流量和告警阈值时。
这条 Mastodon 帖的重要性不在“改用 Bq”，不重要之处也正在这里：它不会改变工程惯例。它真正提醒的是，技术语言越熟，越容易把近似当成本体。一个好笑话能让人重新看一眼默认说法，这已经够有价值。