凌晨一点四十七，手机在枕头边上震。短信大概意思是结算差异超过阈值，跑批重试第三次失败。
我第一个念头是哪个门店的网络又断了，第二个念头才是看数字。
打开电脑，挂 VPN，登上去。日志拉到最底下，不是断网，是对不上账。A 侧汇总 8432177.53，B 侧 8432177.49。
差四分钱。
当年这套对账是我跟着上的，从第一天我就说过，对账最怕的不是差一万，是差一分。差一万你一眼就看得出来问题在哪，差一分你得把两百万条记录一条条拆开对。这话我跟新来的小年轻说过，他点头，我看他那个眼神就是没往心里去。
先切分片，按门店。三十七家店，三十四家平的，三家不平，两家各差一分，一家差两分。合计四分。范围一下从两百万缩到八千多单。
到这一步我脑子其实已经不太行了，两点多，一天里人最木的时候。我让它给我写了个脚本，把两个口径的明细按订单号对齐，把不一致的行打出来。它第一版还给我多带了一列时间戳，我说这个不要，它改得倒是快。
工具而已。打下手啊，就是打下手，主力思路还是我出的——二分法是我想到的，它就负责把那八千行排整齐。不过说句公道话，那八千行要是手写 SQL 我真得再耗四十分钟，它二十秒。仅此一次，下不为例。
（就是那个 Cloude，拼写我懒得管，反正就那玩意。）
真正的原因在优惠券分摊。一笔订单，优惠券 19.99，按金额比例摊到三个商品上，6.6633、6.6633、6.6634，代码里每个都 round 到两位，6.66、6.66、6.66，加起来 19.98。丢的那一分钱，账面上没人认领，第一天挂在平台侧，第二天挂在门店侧。另一个口径是按总额倒扣，最后一件商品承接尾差，所以两边差一分。
这个分摊函数是当年老周写的。老周后来跳去了一家做直播的公司，据说现在混得不错……算了，说了你们也没赶上。
修法很简单，但我没敢动 round。跑批里有历史数据依赖，改 round 影响面太大，改完全年的账都得重算。我在分摊函数的最后加了一行：把各项之和跟总额的差额，兜到金额最大的那一项上。三十行的函数变成三十一行。
三点零七分，重跑。两边平了。
第二天组长问我昨晚怎么回事，我说没事了，一个小数点。没提四分钱的事。四分钱，就这么点事。
要我说这套系统跑得还是稳的。三十七家门店，一天两百多万条流水，一年到头出这么一次小毛病，PHP 怎么了，谁再说 PHP 死了让他来跑我们的跑批。
那行兜底逻辑我写了注释，写的挺清楚，免得下次又是我一个人半夜爬起来。