【高级技巧】闭包计数器实现函数节流：播报限频封装

底层原理

闭包捕获的 upvalue 存在函数原型（F:\底层文件 的 Proto 结构）关联的 UpValue 上，不占全局表、多个闭包实例各持独立副本。利用这一特性把计数器与时间窗封在闭包内部，就能给任意函数套上节流壳：窗口内超过限额的调用直接丢弃。攻城战 500 人同时拾取装备，每条拾取都 sendmsg 播报，单帧 500 次聊天接口调用；节流后每 100 毫秒窗口只放行 10 条，其余静默。

高级封装

通用节流壳：计数器与窗口起点都是 upvalue，多业务各自实例化互不干扰。示例代码如下：

local function throttle(fn, maxCalls, windowMs)
    local count = 0
    local windowStart = 0
    return function(...)
        local now = os.clock() * 1000
        if now - windowStart >= windowMs then
            windowStart = now
            count = 0
        end
        if count >= maxCalls then
            return nil
        end
        count = count + 1
        return fn(...)
    end
end

给拾取播报套壳：100 毫秒窗口最多放行 10 条。示例代码如下：

local rawPickMsg = function(actorName, itemName)
    sendmsg(nil, 1, actorName .. " 拾取了 " .. itemName)
end
local pickMsg = throttle(rawPickMsg, 10, 100)

500 人同时拾取时 rawPickMsg 被 500 次引用，pickMsg 只放行窗口内前 10 条，其余返回 nil 不打扰聊天频道。

性能对比

同屏 500 人同时拾取的攻城场景：未节流时每帧 500 次 sendmsg，聊天接口累计耗时约 25 毫秒，消息刷屏导致玩家主动关闭聊天框；节流后每帧最多 10 次调用约 2.5 毫秒，耗时降到原来的1/10规模。节流壳自身开销：一次 os.clock 与两次比较约 0.001 毫秒，500 次调用累计 0.5 毫秒，远小于省下的接口耗时。

适用边界

三个不适用场景：一是不可丢弃的消息，交易凭据、系统邮件、奖励到账通知被节流丢弃就是资损，节流只用于播报类可丢消息；二是需要保序的业务，窗口内丢弃会造成下游看到的消息序与实际序不一致；三是窗口边界敏感的计数场景，滑动窗口需求（任意 1 秒内不超 N 次）用固定窗口实现会漏判边界突发，需改环形队列记录时间戳。