recharge 是充值到账的引擎触发:充值回调验签通过后引擎唤起这个触发,首充礼包、VIP 成长、充值活动的所有逻辑都在这里分发。触发体要解决的核心问题只有一个:同笔订单绝不能发两次货。
---充值触发 actor:玩家 order:订单信息
function recharge(actor, order)
local orderId = order.id
if getplayvar(actor, "HUMAN", "order_" .. orderId) == 1 then
release_print("重复充值回调 " .. orderId)
return
end
setplayvar(actor, "HUMAN", "order_" .. orderId, 1, 1)
-- 首充判断与发放
if getplayvar(actor, "HUMAN", "first_charge") == 0 then
setplayvar(actor, "HUMAN", "first_charge", 1, 1)
giveitem(actor, "首充礼包", 1, 1, "首充奖励")
end
addvipexp(actor, order.amount)
end
幂等的实现是订单号进持久化变量:处理前查标记、处理后打标,两个动作夹住发放逻辑。支付平台的回调重试机制(同笔订单可能推送 3 到 5 次)是幂等的现实压力,没有这层标记的重发事故每家公司都发生过。首充的判定同样用持久变量,首充标记与订单标记是两把不同的锁。
-- 充值金额与订单的核对:金额以服务端订单为准
function verifyOrder(actor, order)
local expect = queryOrderAmount(order.id)
if expect ~= order.amount then
release_print("金额不符 " .. order.id)
kick(actor)
return false
end
return true
end
客户端上报的金额不可信,订单的金额以服务端支付平台的记录为准,金额不符的订单拒绝发放并断开连接。充值的发放走邮件兜底:发放逻辑的任何异常都转化为等值邮件补偿,宁可多查一步不让玩家白花一笔钱。
充值触发的幂等拦截数监控,拦截数大于零说明回调重试在发生,属正常;发放失败数大于零即为事故。
首充标记的读取曾经没做类型转换,变量返回字符串 "0" 被当作真值,所有玩家的首充都判定为已充过,tonumber 的兜底写法因此成为变量读取的固定套路。充值触发的执行时序与到账通知的并发曾经造成 VIP 经验双计,VIP 经验的累加收敛到幂等标记保护的同一段代码里。
充值触发的所有发放动作必须落在幂等保护区内,保护区外的任何 giveitem 都是资损的候选。充值的金额单位在支付平台与游戏侧要统一(分还是元),单位的换算错误是充值事故的经典成因。触发的处理时长要短,长逻辑(排行更新、公告)异步化,充值的到账延迟玩家零容忍。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 脚本的规范靠人盯盯不过来:命名风格漂移、全局变量乱用、缩进混着来——风格检查器把这些规则的执行自动化。提…
实战应用:用在哪里 拍卖行的出价是一场与时间的博弈:出价的按钮、倒计时的紧迫、截拍瞬间的悬念——拍卖界面的要点是出价的流程、…
实战应用:用在哪里 强化连败七次是什么体验?幸运值机制给失败的玩家一个隐性的承诺:每次失败累加幸运值,幸运值越高下一次的成功…
实战应用:用在哪里 审计日志的价值在于不可抵赖:被改过的日志比没有日志更危险——纠纷的追溯、内部的追责都建立在「日志没被动过…
实战应用:用在哪里 活动结束给 3 万玩家发奖励:一次性群发让邮件表瞬间多 3 万行、投递的队列堵塞正常的通信。批量邮件的分…
实战应用:用在哪里 面对面的交易是传奇最经典的交互:两人面对面、各自放入物品与金币、双方确认后成交。交易的协议要点是会话的建…