【高级技巧】元表锁：__metatable的隐藏与保护

底层原理

元表暴露在外就能被 setmetatable(t, nil) 摘掉——只读保护、继承链都可能被外部破坏。元表的 __metatable 字段是官方锁：设置后 getmetatable(t) 返回的是 __metatable 的值而非真实元表，外部对 t 再调 setmetatable 直接报错（cannot change a protected metatable）——它锁住的不是表的数据，而是"保护机制本身"：元表不可查看、不可替换。

高级封装

加锁与验证。示例代码如下：

local function lockTable(t)
    local mt = {
        __index = function() return nil end,
        __newindex = function() error("只读表禁止写入", 2) end,
        __metatable = "protected"
    }
    return setmetatable(t, mt)
end
local cfg = lockTable({ rate = 50 })
print(getmetatable(cfg))

输出 protected——外部拿到的不是真实元表而是占位值，祖玛掉落配置的保护逻辑不可窥探。示例代码如下：

local ok, err = pcall(setmetatable, cfg, nil)
print(ok, err)
local ok2, err2 = pcall(function() cfg.rate = 99 end)
print(ok2, err2)

两条 pcall 都失败——摘元表报受保护元表不可更改，写字段报只读禁止写入，锁与保护双层生效。

性能对比

__metatable 字段本身零运行时成本（只在 getmetatable 与 setmetatable 调用时生效）；对比裸只读表：被摘掉元表后写入畅通无阻——加锁的差别不是速度而是能否被绕过。加锁成本仅一次 setmetatable 调用，微秒级。

适用边界

三个不适用场景：一是内部模块自己持有的表（自己也要改），加锁后自己也写不了——锁是给外部边界用的；二是 __metatable 挡得住常规 setmetatable，挡不住调试库的层级探查——它防误用不防蓄意；三是需要继承链可扩展的场景（子表要挂新元表），锁死后灵活性归零。