内存涨了不回落，十有八九是有张该死的表被谁攥着不放。Lua 的回收按可达性判定：只要还存在一条从全局表、活跃闭包或常驻表出发的引用链，目标表就死不了。排查思路是二分法：先把嫌疑引用逐个置 nil，每置一个跑一次 collectgarbage("count") 看内存——某一置之后内存应声回落，凶手就是它。这套手法不依赖任何调试器，只靠回收器的可达性语义与内存计数， Lua 环境里随时随地可做。
排查工具：内存快照与引用置空的二分流程。示例代码如下：
local function memKB()
return math.floor(collectgarbage("count"))
end
local function probeLeak(suspects)
local results = {}
for _, s in ipairs(suspects) do
local before = memKB()
collectgarbage("collect")
local after = memKB()
results[#results + 1] = s.name .. " 采样 " .. before .. "->" .. after .. "KB"
s.clear()
end
collectgarbage("collect")
return results
end
业务侧二分排查：嫌疑引用逐个置 nil，内存应声回落的即真凶。示例代码如下：
local cacheA, cacheB = {}, {}
local function fill()
for i = 1, 20000 do
cacheA[i] = "占位数据" .. i
end
end
local function hunt(actor)
actor = getplayerbyname(actor)
fill()
collectgarbage("collect")
local withA = memKB()
cacheA = nil
collectgarbage("collect")
local withoutA = memKB()
sendmsg(actor, 1, "持有时 " .. withA .. "KB，置空后 " .. withoutA .. "KB")
end
真实泄漏案例：榜单模块常驻内存 41MB 一个月不落，二分排查 6 步锁定一处闭包捕获了 4.7 万行的历史榜单表；置空并改为按需查询后，常驻回落到 6MB。排查成本：每次 collectgarbage("collect") 全量回收约 15ms，二分 6 步合计 90ms——定位一个泄漏花不到 0.1 秒的排查成本，前提是嫌疑清单列得准。
collectgarbage 全量回收本身有停顿，排查工具只在开发与诊断场景使用，生产常驻会制造周期性卡顿。可达性排查找不到"被 C 侧或引擎侧持有"的引用（那部分不走 Lua 可达性），这类泄漏要看引擎侧的注册表与句柄。另外，弱表里的条目不计入强引用排查——排查前先确认嫌疑表是强引用语义，否则置空后内存不回落会误判成"还有别的引用"。
全站技术干货持续更新：996 引擎 / Lua 实战帖，语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 活动排期凭感觉：周末连开三个重头活动，玩家疲于奔命参与率反跌；工作日大空窗，在线曲线断崖。玩法日历设计：以周为单位…
设计初衷 网络波动掉线让玩家损失战斗进度：世界BOSS打到一半掉线，回来残局已清；副本中掉线，门票作废。掉线补偿设计把掉线当…
底层原理 祭坛围一圈火把、世界BOSS周身一圈水晶，这类环绕阵列需要等角度分布坐标：圆心 (cx, cy)、半径 r、数量 …
设计初衷 排行榜只有顶端可见：进不了前一百的玩家在榜上查无此人，名次没有参照，追赶没有对象。影子榜设计：为每名玩家生成以自己…
业务场景 打错路线或主力减员后想重来，队长单方面重置常引发队内矛盾，误触重置的投诉也不少。投票重置封装：重置需全队表决、同意…
底层原理 存档在写入与传输中可能因意外损坏，读档前需要一道完整性判定。校验和的思路：把数据逐字节累加压缩成一个整数指纹，读档…