【Lua实战】assert 的正确用法：断言不是校验

实战应用：用在哪里

assert 常被当作输入校验的快捷方式，这是误用——断言的语义是"代码的正确性假设"，校验的语义是"用户输入的合法性"。两者的失败对象不同：断言失败是 Bug，校验失败是业务，混用的代价是错误处理的分层全乱。

断言与校验的分界

---误用：用 assert 校验玩家输入
-- function Buy.speedUp(actor, count)
--     assert(count > 0, "数量必须为正")      -- 玩家输入失败=Bug?
--     assert(checkitemw(actor, "金币", count * 100))
-- end

---正确：输入走校验返回，内部假设走断言
function Buy.speedUp(actor, count)
    if type(count) ~= "number" or count <= 0 or count > 99 then
        sendmsg(actor, 1, "购买数量须在 1 到 99 之间")
        return false
    end
    -- 内部不变式：走到这里配置表必然存在
    assert(BUY_CFG[count], "配置缺失: " .. tostring(count))
    return true
end

玩家输入的非法是业务的日常，走校验分支返回提示；配置表缺失是代码的不变式被破坏，走 assert 让 Bug 在测试期炸出来。分界线的判断法：失败的对象是玩家就校验，失败的对象是开发者就断言。assert 的第二参数是错误消息，带上下文的断言消息（哪个配置、什么值）让 Bug 的定位一步到位。

断言的成本

---热路径的断言成本控制
local function hotCalc(a, b)
    -- 常量消息的 assert 成本极低，可留
    assert(b ~= 0, "除零")
    return a / b
end

---带拼接消息的 assert 每次都构造字符串
-- assert(valid, "bad state: " .. tostring(state))  -- 热路径禁用

---封装：只在调试模式校验的断言
local DEBUG = false
local function dassert(cond, msg)
    if DEBUG and not cond then
        error(msg, 2)
    end
end

assert 的成本差异在消息参数：常量消息几乎零成本，带字符串拼接的断言每次调用都分配新串——热路径的断言要么用常量消息，要么走 DEBUG 开关的封装，发布的版本里 dassert 直接退化为空操作。assert 与 pcall 的配合是模块边界的标准姿势：边界处 pcall 兜住内部断言的爆炸，转化为对外的错误码，断言炸在内部、体面地死在边界。断言的覆盖对象挑三类：不变式（循环不变量）、前置条件（函数入参的类型假设）、后置条件（返回值的自检），三类之外的检查交给校验与测试。

验证与监控

断言的触发在生产环境的错误聚合里单列一档：断言失败即 Bug 级告警，与普通错误的处置分级不同；断言的覆盖密度统计，核心模块的不变式断言要求每百行一个以上。

踩坑记录

assert 曾经包住玩家的每个输入，恶意构造的输入让断言疯狂爆炸，错误日志被业务失败淹没，输入与断言的分界重构。带拼接消息的断言留在每帧调用的热路径，字符串分配让 GC 压力翻倍，dassert 的开关封装替代。pcall 兜底曾经把断言错误静默吞掉，Bug 上线三个月无人知晓，错误聚合对断言类消息单独告警。

上线要点

断言与校验的规范进编码评审：assert 的消息必须能定位代码位置。DEBUG 断言的开关与测试的覆盖率联动，测试跑 debug 版，发布跑 release 版。断言失败的告警走 Bug 级通道，响应的时限按故障级执行。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。