【案例复盘】周年庆福利重复领取的事故复盘

实战应用：用在哪里

周年庆礼包开领 30 分钟，3000 名玩家多领了一份礼盒，回收与舆情处理耗掉两天。事故根因简单得刺眼：活动面板与庆典 NPC 两个领取入口各自实现了判断，幂等键名一个写 ANNIVERSARY，一个写 ANNI_7，互相不认识。

事故还原与幂等补丁

双入口在领取高峰同秒并发，两套判断都通过了。补丁把领取收敛成唯一函数，幂等键全局唯一，先置位后发放，两个入口改为同一函数调用。复盘除了修 bug 还修流程：福利类需求的开发清单新增幂等键登记与入口清单两项，评审对照清单走查。

function claimAnniversary(actor)
    if tonumber(getplayvar(actor, "HUMAN", "ANNI_7_FLAG") or "0") == 1 then
        sendmsg(actor, 0, "周年礼包已经领取过了")
        return
    end
    setplayvar(actor, "HUMAN", "ANNI_7_FLAG", 1, 1)
    giveitem(actor, "周年礼盒", 1)
    sendmsg(actor, 0, "领取成功，礼盒已放入背包")
end

存量回收与安抚补偿

按领取流水找出多领名单，回收多余礼盒并补偿 50000 金币礼券，回收全程短信告知，名单留档备查。

local function rollbackExtra(actor, extra)
    local p = class(actor)
    p:takeitem("周年礼盒", extra)
    giveitem(actor, "金币", 50000)
    sendmsg(actor, 0, "多领的 " .. extra .. " 个礼盒已回收，补偿已发放")
end

验证与监控

双通道并发压测同秒领取 200 次，零重复；正常单通道领取 500 次零误拦；回收名单与流水逐条核对。监控每日各入口的领取量对比，两入口比例突变就是新的口径裂缝。压测脚本模拟两入口同秒各点一次，连续 200 轮断言只成功一次，固化为回归用例。

踩坑记录

回收脚本第一版按标记名单全量回收，把只领过一份的正常玩家也扣了礼盒，第二版以流水差额为准才止住误伤。礼盒当初没做绑定，多领的部分被转手卖掉，回收追到二手买家引发新一轮投诉，福利类道具默认绑定写进了规范。补偿金额 50000 是按礼盒市价折算的，低于预期又引发一轮不满，补偿定价要按情绪价值算不是按市价算。两个入口是两个同事同一天各自开发的，代码评审只看了各自逻辑，入口清单类需求从此要求先登记幂等键。giveitem 与置位的顺序在补丁里定死为先标记后发放，与补偿脚本共享同一封装，避免下一个活动再各写一遍。