【Lua实战】观察者模式：属性变更的订阅通知

实战应用：用在哪里

升级之后要做三件事：刷新等级榜、推送装备评分、校验穿戴门槛，全都挤在 playlevelup 触发里顺序硬编码，加一个需求就往里塞一段，某次榜单模块报错把校验也带死了。观察者模式把三件事拆成三个订阅者，互相隔离。派发层只认订阅表，业务增减发生在注册环节，触发函数从三十行缩到一行。

订阅表与隔离派发

订阅者按名字注册进表，派发时逐个 pcall 保护，单个订阅者报错只记录并跳过，不影响其余订阅者执行。

local subs = {}
local function subscribe(name, fn)
    subs[name] = fn
end
local function dispatch(actor)
    for name, fn in pairs(subs) do
        local ok, err = pcall(fn, actor)
        if not ok then
            sendmsg(actor, 0, name .. " 模块刷新失败，已跳过")
        end
    end
end

触发挂接与订阅者注册

playlevelup 触发只做一次派发，等级榜与评分推送各自注册，新增观察者零改动触发函数。

function playlevelup(actor)
    dispatch(actor)
end
subscribe("rank", function(actor)
    local p = class(actor)
    setplayvar(actor, "HUMAN", "RANK_LV", getbaseinfo(p, 6), 1)
end)
subscribe("score", function(actor)
    sendluamsg(actor, 7103, 0, 0, 0, "rescore")
end)
subscribe("wear", function(actor)
    setontimer(actor, 153, 1)
end)

验证与监控

三个订阅者分别注入报错，核对另外两个照常执行；升级触发到派发完成的耗时埋点，超过 100 毫秒告警；订阅表名字重复注册时后一个覆盖前一个，注册日志留痕。新观察者的接入流程走一遍评审：注册名、执行耗时、失败影响三栏写清才准进表。一次升级批量测试里连升三级，三批观察者各触发一轮，派发层压力可控。回归脚本在测试号上伪造升级事件连跑一千次，派发耗时曲线平稳无抬升。监控派发失败计数，单模块失败率超 1% 即定位修复。

踩坑记录

pcall 吞掉错误后没有留痕，榜单模块静默失败三天才被发现，err 参数必须写日志或计数。pairs 遍历顺序不定，穿戴校验依赖评分先算完的场景不能用表遍历次序，改成带优先级的数组遍历。观察者里做重活会拖慢升级结算，等级榜刷新挪进 1 秒延迟定时器，玩家先看到升级光效再看到榜单变化。订阅者名字手滑写重，两个模块只活下来一个，注册时对重名直接报错。派发层本身不做任何业务判断，加了逻辑的派发层会让后来者不敢动，保持薄是这条架构的生命线。