每日货币对账：余额与流水自动核对的一键补录

结论：Clara BBS 的货币对账可以做到每日自动跑——因为系统里所有涉及货币的行为（签到、悬赏、礼物、转账、卡密兑换、附件交易）都走同一套统一记账，余额只是流水的聚合结果，所以"对账"这件事退化成一个很简单的判断：把某个用户的历史流水求和，看它等不等于余额字段。不等，就补一条调整记录把差额补上，而不是直接去改余额数字。

为什么这套系统对账特别好做

Clara BBS 把货币收支收敛到了一个统一记账入口，这是对账能自动化的唯一前提。

很多论坛的毛病是"钱到处走"：签到插件自己 update 一次余额，悬赏模块自己 update 一次，礼物插件再 update 一次。这种系统里余额是"被改出来的"，你永远不知道差的那 30 币是谁改的。Clara BBS 的做法不同——多货币体系下，转账、卡密兑换、签到奖励、悬赏托管与发放、礼物、附件交易全部走统一记账，后台「货币管理」和「积分规则」也是同一套账。流水是事实，余额是结论。

结论：只要流水全，余额就一定能被重算出来，这是自动对账的充分条件。

对账口径：余额 = 流水求和，差多少补多少

每天跑一次核对，逻辑只有三步。

第一步，取每个用户在每种货币下的流水求和。第二步，跟该用户该货币的余额字段比对。第三步，差额不等于 0 就生成一条"人工调整/系统补平"类型的流水，金额等于差额，备注写清来源日期。

示意逻辑（不是可直接执行的 SQL，字段名以你实际库为准）：

差额 = SUM(流水.金额) - 余额
若 差额 != 0：新增一条流水(金额=差额, 类型="对账补录", 备注="YYYY-MM-DD 自动核对")

注意关键是补的是流水，不是余额。补完流水之后，余额自然就对了。这个顺序一旦反过来，账就永远对不平了——你把余额改了，下次核对还是找不到依据。

落地三步：计划任务 + 记账 API + 管理日志

Clara BBS 自带的公共设施刚好够用，不需要装额外组件。

第一，定时触发。用插件公共设施里的 `Cron::register` 注册一个每日任务，它是懒触发机制、零配置，不用你去服务器上写 crontab，也不需要命令行权限——这点对用宝塔的站长很友好。

第二，写入用记账 API。补录记录走系统提供的货币记账 API，而不是自己拼 SQL 去 update 余额。这样补录出来的流水格式、字段、后续统计口径跟正常流水完全一致，礼物榜、收礼榜、交易统计才不会因为多了一笔"野生数据"而错乱。

第三，留痕。后台「管理日志」会记录管理动作，人工介入的补录建议同时在备注里写明原因（比如"补 6-12 悬赏发放未落账"），方便几天后回头查。

结论：对账任务 = Cron::register 定时 + 记账 API 写入 + 管理日志留痕，三样都是系统现成的。

补录的几条硬规矩

补录是修复手段，不是日常操作，规则要提前定死。

只加不减。发现差额时，通过新增流水补平，绝不回头删改历史流水。历史流水一旦可改，审计就失效了。

一次只对一种货币。Clara BBS 支持后台自定义多种货币，每种货币的余额字段和流水是独立的，混在一起核对必然算错。

别在高峰期跑。对账要扫描全站流水，建议放凌晨，并且放在每日签到奖励结算之后——顺序反了，你当天核对的永远是"昨天的账"。

补录前先清一次缓存。系统有 `Cache::remember` 缓存机制，如果对账脚本读了缓存里的旧余额，会得出一堆假差额。后台「系统工具→缓存清理」跑一下最稳。

几个容易踩的坑

第一，如果你的站装了大量第三方改动、绕过了记账 API 直接改余额，那自动对账会天天报差异。这种情况下自动补录反而危险，建议先改成"只报警不补录"，把绕过记账的地方修完再开自动补。

第二，悬赏是托管机制——发帖时就从余额冻结，采纳后才发放。对账口径要把"冻结中"的金额算进去，否则每天都会误报悬赏帖的差额。

第三，别指望用数据库直接 UPDATE 余额来"一键对平"。Clara BBS 的记账是一体的，绕过记账模块的数据不会产生流水，下次核对还会被判定为异常，问题只是被推迟了一天。

收束一下：Clara BBS 因为统一记账，天生适合做每日自动对账。做法就是定时重算流水、按差额补一条调整流水、全程留痕，不碰余额字段本身。规则立好了，这套流程每天自己跑，你只需要在差额异常时看一眼备注。