【高级技巧】多路复用：一条消息承载多事件的路由表

底层原理

引擎的消息号是稀缺资源：签到提醒、邮件提醒、活动预告各占一个号，三十种小消息把号段瓜分殆尽，前后端协议表越养越厚，每加一个小功能都要两端同步加号。多路复用换个分法：消息号只分大类，大类内部用子命令字段细分——sendluamsg(actor, 9995, subCmd, ...) 的第二个参数就是天然的子命令位。前后端各持一张路由表，新事件只是注册一行路由，协议号永不再动。路由表本质是一张"子命令到处理函数"的映射，查询 O(1)，扩展开放、修改封闭。

高级封装

路由表三件套：注册、分发、兜底。示例代码如下：

local routes = {}
local function registerRoute(subCmd, fn)
    routes[subCmd] = fn
end
local function dispatch(actor, subCmd, p1)
    local fn = routes[subCmd]
    if fn == nil then
        return false
    end
    fn(actor, p1)
    return true
end

业务侧注册与入口分发：未知子命令走兜底告警而不是静默丢失。示例代码如下：

registerRoute(1, function(actor, p1)
    actor = getplayerbyname(actor)
    sendmsg(actor, 1, "事件1 签到奖励到账：" .. p1)
end)
registerRoute(2, function(actor, p1)
    actor = getplayerbyname(actor)
    sendmsg(actor, 1, "事件2 邮件提醒：" .. p1)
end)
local function onChannelMsg(actor, subCmd, p1)
    if not dispatch(actor, subCmd, p1) then
        sendmsg(actor, 1, "未知子命令：" .. tostring(subCmd))
    end
end

本篇的新技术点是兜底分支即监控：未知子命令的每一次出现都是两端协议失配的信号，静默吞掉等于蒙住自己的眼睛。

性能对比

协议维护成本对比：三十种小消息独立开号，协议表 30 行、每次加功能前后端各改一处并发版；多路复用后 1 行大类加 30 行路由注册，新事件零协议变更，只发服务端即可热上。分发开销：路由表一次哈希查询 0.0002ms，万次分发 2ms，远低于维护两套协议表的对账人力。号段资源：复用后协议号占用从 30 个收敛到 1 个。

适用边界

复用只适合语义相近的小消息（提醒、通知类），大 payload 与高频事件（战斗包、移动同步）仍应独立开号——塞进复用通道只会让路由表变成性能瓶颈。子命令号段同样要登记管理，否则撞车事故从协议层转移到路由层，问题只是换了个地方。另外，路由处理函数要各自做好 actor 空值防御，入口分发器不做统一校验。