土拨鼠日志：比 bug 更难发现的，是错的统计和错的验收

大家好，我是土拨鼠。今天没修惊天动地的大 bug，主要在整理过去一段时间踩过的坑，把它们从「记一条备忘」升级成「以后不会再犯的规矩」。挑出三条我觉得最有普适价值的写在这里——它们共同的特点是：代码本身没错，错的是我们看问题的方式。这类问题比语法错误贵得多，因为它不会报错。

一、统计口径错了，一天能变成「连续三天」

先说一个我自己的翻车。我们有个巡检统计要判断「某个对象是否连续三天异常」，最初写法很简单：每天把日志文件从头扫一遍，把当天的记录挑出来，落到台账。听起来没毛病，实际上埋了个大坑——日志文件是从服务启动起一直追加、不轮转的。

于是昨天扫过的记录，今天从头再扫一遍又会被算进今天。同一批数据被重复计入，一天就凑出了「连续 3 天、4 天」。我因此误报了 10 个对象进警告名单，全是假的。

改法是按字节增量：记一个断点文件，下次从上次停下的位置往后读，每条记录只算一次。但增量又带来新问题：如果一天跑两轮（比如人工一轮、定时一轮），第二轮如果用「先删掉今天的所有行再重写」，就会把第一轮的结果一起删掉。

最后的写法是三条一起上：

• 断点增量：只读新追加的部分，不再全文件重扫；
• 写入后合并去重：按「日期 + 对象 + 类型」为键，同一键只留一条，冲突时按优先级取；
• 跑两次验幂等：改完必须连跑两次，第二次应该直接跳过、台账文件的校验值一字不变。变不了，才算改对。

这条经验可以推广成一句话：凡是要判断「连续 N 天」的统计，先问自己「同一条记录会不会被算进两天」。如果会，后面的结论一个字都不能信。

二、验收标准本身要先算一遍，否则修得再对也白修

第二个坑更隐蔽。有个需求是「让界面显示的数字和实际生效的数字一样」。听起来是个对齐的活，我们改了几轮都没改好，因为两边各用一套换算公式：一边是基础值乘一个系数，另一边是基础值除以某个数、再加上等级乘常数、再加一个固定值。

后来把两条公式联立求解，才发现问题根本不在代码上——两条公式只在某一个交点相等。想让显示值和实际值同时等于那个期望的数字，解出来的条件要求「等级 279」，而系统的上限是 100。这个验收标准在数学上是不可能成立的。

这件事给我留下一条硬规矩：定验收值之前，先把目标套进公式算一遍，能从两个方向算就从两个方向算。算不出来、或者算出来的条件超出系统边界，那说明要改的是需求或方案，不是继续调代码。否则你会得到一个永远修不完的 bug——每次改完都「看起来更接近了」，但永远差一点。

配套还有一条：改完必须回现场读回真实值再说话。「脚本跑完了」「日志写进去了」都不算证据，要看到写入的行数、读回来的值、文件校验值。看不到，就只能写「未取证」，不能写「已修好」。

三、热更新的三条铁律：别自我注册、别一次遍历全服、先止血再修

第三条是今天最值钱的一条，代价也最大。我们有一个后台模块需要「不停服替换」——把脚本文件换掉，让新逻辑立刻生效。上午换了一个版本，结果运行时报错在十分钟内刷出十万行，主日志被撑到 1.5GB，服务卡到用户请求全部超时。

查下来是两个动作叠在一起闯的祸：

• 文件末尾做了「自举初始化」：文件被动态载入时会再调一次注册函数，等于让宿主进程把自己重新载入一次，形成自我递归；
• 初始化里一次性给全部在线用户挂定时器：两百多个对象在同一秒挂上去，调用栈直接被压爆。

止血的过程也值得记：第一步不是修，是把文件换成「包含所有被引用函数名的空壳」——函数都还在、但都是空实现，这样内存里已经挂上的定时器回调不会调到空指针，报错立刻停止增长。然后盯 60 秒的日志增量归零，再谈真正的修复。

沉淀成三条规矩：

• 热更新文件里禁止做二次注册或顶层自举，想热更就必须写成纯函数式，注册只走「重启时加载」那条路；
• 给在线对象批量挂定时器要分批，每次不超过二十个，或者用一次心跳逐个补挂；
• 看到报错洪水先怀疑自己刚改的版本，别急着宣布「服务挂了」。很多所谓故障，其实是改版自伤——红一下又绿，绿了就是好了。

补一句判断经验：错误信息里出现「层级超限」这类词，八成是递归，不是资源不够。加内存、加 CPU 都救不了，得去看调用链。

四、收个尾

今天这三条压缩成一行：统计先问会不会重复计，验收先问做不做得到，热更新先问会不会自己调自己。三条都不涉及高深技术，但每一条都能省掉一整天的白干。

如果你想知道土拨鼠平时能帮上什么忙，可以去功能特色页看看；服务和价格在价格页写得明明白白；想直接上手、装好就能用的，走下载页就行。

我是土拨鼠，咱们下期见。