模块的可变状态直接暴露在表字段里,任何代码都能改——红名单被误写、计数器被清零,都是“公开可写”惹的祸。闭包隔离的原理:把状态放进构造函数的局部变量,只通过返回的函数访问——Lua 的上值只能被捕获它的闭包读写,外部既看不见也改不了。这比“靠命名约定劝退”强一个量级:约定靠自觉,闭包靠语言机制。
红名计数器模块:状态私有两种操作公开,非法调用零入口。示例代码如下:
local function makeRedNameTracker()
local counts = {}
local function add(name)
counts[name] = (counts[name] or 0) + 1
end
local function get(name)
return counts[name] or 0
end
local function clear(name)
counts[name] = nil
end
return { add = add, get = get, clear = clear }
end
local tracker = makeRedNameTracker()
业务接入:计数只能通过 add 累加,无法从外部清零或篡改。示例代码如下:
local function onKill(actor, victim)
actor = getplayerbyname(actor)
local evil = tonumber(getplayvar(actor, "HUMAN", "Evil")) or 0
if evil >= 300 then
tracker.add(victim)
sendmsg(actor, 1, victim .. " 的恶行已被记录(累计 " .. tracker.get(victim) .. " 次)。")
end
end
本篇的新技术点是“三个闭包共享同一份上值”:add、get、clear 是三个函数却读写同一个 counts——捕获发生在定义时,同源闭包天然共享,外部却拿不到引用。
公开表与闭包隔离对比:公开表 version 一次恶意清零直接生效且无日志;闭包版外部任何赋值都不存在入口,配合 add 内的审计行可追到每次变更。性能成本:闭包调用比直读表字段多 0.0002ms 每次,万次调用多 2ms——状态访问频率每秒百次以下毫无压力。内存:闭包三元组加状态表约 200 字节每模块。
闭包隔离适合状态敏感、读写路径固定的模块(计数器、限频器、配额器);需要被外部遍历或批量导入导出的数据不适合藏进闭包——补一个导出函数即可,但要清楚导出就重新暴露了状态。另外,闭包状态不落库,重启即重置——需要跨重启的状态要自己接落库钩子,闭包只管“运行期的访问控制”。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 生存向属性的堆法单一:全堆血防就能站桩——挨打没有反馈,进攻方也没有取舍。反伤与荆棘设计:引入"被打反伤"机制并配…
设计初衷 活动做过就下架:老玩家念着当年的中秋灯会,新玩家永远错过——内容资产利用率极低,新玩法的开发压力却全压在增量上。活…
底层原理 一条业务请求(聊天、交易、入队)前面总挂着同样的横切逻辑:鉴权、限频、日志——每个入口各写一遍必然重复。中间件模式…
底层原理 求区间和(第 3 到 17 名的战力总和):前缀和预处理后查询 O(1),但单点更新要 O(n) 重算整张前缀表;…
设计初衷 玩家的江湖故事散落在各系统的角落:成就页有里程碑、战绩页有击杀、名人堂有荣誉——拼不出一个完整的"人"。玩家传记设…
业务场景 玩家跑商只能身上背货:负重有限、路线自己跑、货物分站下不去。马车货运封装:驿站雇马车按固定线路多点卸货,载重按马车…