【实战案例】帮派资金负数：一次 -2 亿金币的事故复盘

实战应用：用在哪里

行会基金是行会玩法的心脏：捐献进账、建筑扣款、工资发放都动这笔钱。某天凌晨，一个行会的基金被查出来是 -2 亿金币——钱可以凭空多，但不该凭空少，这起事故的排查过程值得整个后端组记住。

事故现场

-- 事故代码：建筑升级的扣款函数
function Guild.upgrade(guild, cost)
    local fund = getguildvar(guild, "fund") or 0
    fund = fund - cost
    setguildvar(guild, "fund", fund, 1)
    Guild.startBuild(guild)
end

问题出在扣款前没有校验余额：两个管理同时点升级，第二个请求在第一个扣款后仍然执行，把基金扣成了负数。getguildvar 读到的是旧值，减去成本后直接写回，检查余额的那行代码被某次重构删掉了，评审时谁也没注意到。

修复与对账

function Guild.upgradeSafe(guild, cost)
    local fund = getguildvar(guild, "fund") or 0
    if fund < cost then return false, "基金不足" end
    setguildvar(guild, "fund", fund - cost, 1)
    Guild.startBuild(guild)
    GuildFundLog.write(guild, "upgrade", -cost)
    return true
end

修复三件事：余额前置校验、扣款与日志成对出现、全行会基金做一次历史对账。对账脚本扫描出 4 个被扣成负数的行会，全部按日志回滚补偿，玩家的补偿邮件三天内发完。

验证与监控

基金流水与余额每日对账，负余额告警阈值设为零——出现一次就是事故。

踩坑记录

复盘发现最初删掉校验的原因是"升级按钮已经做了置灰"，前端限制替代不了服务端校验，这条教训写进了评审清单。资金类变量的每次变更都要求流水成对：改了钱就必须有日志，没有日志的扣款在代码评审阶段直接打回。事故的补偿花了两天，而校验代码只需要一行，这笔账怎么算都清楚。

上线要点

资金类接口统一走封装函数，业务层不允许直接读写基金变量。对账脚本每天凌晨跑一次，差异超一枚金币即告警。事故复盘的结论要在团队内宣讲：前端状态是提示，服务端校验才是规则。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。