一条业务链路往往穿越四五个函数：入口触发 → 校验 → 结算 → 通知。玩家对象、来源渠道、事务单号这些"全程都要用"的信息，散装传法是每个函数的参数表越写越长，偷懒传法是塞进全局变量——前者参数爆炸，后者全局污染。上下文透传的折中：把链路级信息打包成一张 ctx 表，作为第一个参数沿调用链传递；函数签名统一为 f(ctx, ...)，链路里任何一层都能拿到全量上下文，又没有全局变量的覆盖风险。
上下文构建与链路传递：入口建 ctx，各层只加不改。示例代码如下：
local function makeCtx(actor, source)
return {
actor = actor,
source = source,
ticket = "T" .. os.time(),
logs = {},
}
end
local function ctxLog(ctx, line)
ctx.logs[#ctx.logs + 1] = line
end
local function doSettle(ctx, amount)
ctx.amount = amount
ctxLog(ctx, "结算金额 " .. amount)
giveitem(ctx.actor, "金条", math.max(1, math.floor(amount / 10000)))
end
入口串联：建 ctx、走链路、日志随 ctx 一次落账。示例代码如下：
local function onQuestDone(actor, amount)
actor = getplayerbyname(actor)
local ctx = makeCtx(actor, "quest")
ctxLog(ctx, "任务完成触发结算")
doSettle(ctx, amount)
setplayvar(actor, "HUMAN", "LastTicket", ctx.ticket, 1)
sendmsg(actor, 1, "链路单号 " .. ctx.ticket .. "，共 " .. (#ctx.logs + 1) .. " 步。")
end
本篇的新技术点是"ctx 只加不改"：链路里任何一层都只往 ctx 里追加字段，不修改上游已写的值——ctx 因此成为天然的链路审计记录。
三种传法对比（五层调用链、4 项链路信息）：散装传参每层签名 4 个参数，加一项信息改五个函数签名；全局变量传法零参数但双触发互相覆盖；ctx 表构建 0.002ms、每层透传零成本（传引用），单次链路额外内存约 200 字节，日均 5 万条链路合计 10MB 峰值——生命周期与链路等长，用完即被 GC。
链路只有两层（入口直接调一个函数）不值得建 ctx，散装传参更直接。ctx 表是引用传递：下游对 ctx.actor 的重赋值会影响上游，链路里"只加不改"要靠约定执行，关键值（单号、金额）在写入后可以立即取出存局部变量。另外，ctx 不要常驻——它是链路的随行行李，链路结束就该被 GC，把它存进全局表等于把行李搬进了候车室。
全站技术干货持续更新：996 引擎 / Lua 实战帖，语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 活动排期凭感觉：周末连开三个重头活动，玩家疲于奔命参与率反跌；工作日大空窗，在线曲线断崖。玩法日历设计：以周为单位…
设计初衷 网络波动掉线让玩家损失战斗进度：世界BOSS打到一半掉线，回来残局已清；副本中掉线，门票作废。掉线补偿设计把掉线当…
底层原理 祭坛围一圈火把、世界BOSS周身一圈水晶，这类环绕阵列需要等角度分布坐标：圆心 (cx, cy)、半径 r、数量 …
设计初衷 排行榜只有顶端可见：进不了前一百的玩家在榜上查无此人，名次没有参照，追赶没有对象。影子榜设计：为每名玩家生成以自己…
业务场景 打错路线或主力减员后想重来，队长单方面重置常引发队内矛盾，误触重置的投诉也不少。投票重置封装：重置需全队表决、同意…
底层原理 存档在写入与传输中可能因意外损坏，读档前需要一道完整性判定。校验和的思路：把数据逐字节累加压缩成一个整数指纹，读档…