5.1 元表的概念与查找链

5.1 元表的概念与查找链

本节摘要：元表是挂在值（主要是表）上的一张"后备行为表"：当常规操作找不到答案——键不存在、运算数不认识、要转字符串——虚拟机就来问元表。__index 是其中最常用的钩子，它有表（委托）与函数（计算）两种形态，构成了继承与默认值的机制底座。本节讲清挂载规则、完整查找链、raw 系列的穿透用法，并回答寄宿视角的核心问题：为什么把行为设计成"外挂"。

缺页处理权

从一次"扑空"讲起：

> local t = {}
> print(t.missing)
nil
​

键不存在，返回 nil，理所当然。但 Lua 给了这个扑空一次上诉机会：如果 t 挂着元表、元表里有 __index 钩子，虚拟机就去问它。这一个钩子撑起了 Lua 的继承、默认值、懒加载、命名空间回退——半门语言的"高级感"都源于此。

先认识挂载操作。setmetatable(t, mt) 给 t 挂元表并返回 t，getmetatable(t) 取回：

> local defaults = { timeout = 3, retry = 1 }
> local cfg = setmetatable({}, { __index = defaults })
> print(cfg.timeout, cfg.retry)
3	1
> cfg.retry = 5                  -- 写自己的，不惊动元表
> print(cfg.retry, defaults.retry)
5	1
​

读的时候兜底到 defaults，写的时候落在自己身上——读委托、写自立。这十个字是 __index 语义的浓缩，后面的一切（继承、原型、缓存回填）都是它的变奏。

三条挂载规则先钉牢：

其一，元表挂"值"不挂"类型"。每张表可以有自己的元表，也可以共用一张（类继承就是这么省内存的：一万个实例共享一张类元表）。不存在"所有表统一改行为"的全局开关——元表永远是某张表自己的事。

其二，哪些类型有元表。表可自由挂载；字符串天生挂着一张（指向 string 库，所以 ("x"):upper() 能用，4.1 节的伏笔在此兑现）；userdata 由宿主 C 侧挂；number、boolean、nil、function 没有用户可见的元表。

其三，元表是普通表。它只是字段名恰好以下划线开头的普通表，getmetatable 拿到后你可以 inspect 它、甚至运行时改它——热更新换行为的门缝就在这里（第 9 章推门）。

查找链：一次索引的完整旅程

t.k 在虚拟机里的完整判定过程如下：

两种形态各看一个完整例子。

表形态：委托与回退。配置系统要"全局默认、模块覆盖、现场覆盖"三级：

local global_default = { timeout = 30, level = "info", encoding = "utf-8" }
local module_cfg = setmetatable({
    timeout = 5,                       -- 模块级覆盖
}, { __index = global_default })
local runtime_cfg = setmetatable({
    level = "debug",                   -- 现场级覆盖
}, { __index = module_cfg })

print(runtime_cfg.timeout, runtime_cfg.level, runtime_cfg.encoding)
-- 5（模块级）	debug（现场级）	utf-8（全局默认）
​

三级配置像水往低处流：现场没有问模块，模块没有问全局。整条链就是一张"元表链表"，没有魔法。

函数形态：默认值与懒加载：

local lazy = setmetatable({}, { __index = function(t, k)
    local v = compute_default(k)          -- 假装这个计算很贵
    t[k] = v                              -- 回填缓存，下次走第一步直接命中
    return v
end})

local function compute_default(k)
    return ("default-of-%s"):format(k)
end
print(lazy.zone, lazy.zone)      -- 第二次读同值更快（已回填）
​

函数形态拿到 (t, k) 两个参数，能做任何计算再返回，还顺手把结果写回本体——缓存回填是它的招牌动作。第 9 章 C API 一节的 userdata 方法表、OpenResty 一些库的懒初始化，都是这个形态。

raw 系列：穿透钩子

四兄弟：rawget(t, k)、rawset(t, k, v)、rawequal(a, b)、rawlen(t)。它们执行操作时完全绕开元方法，只走第一步：

> local defaults = { x = 1 }
> local t = setmetatable({}, { __index = defaults })
> print(t.x, rawget(t, x))
​

上面有个故意留的错——rawget(t, x) 里 x 是裸名字，应为字符串 "x"。正确写法与输出：

> print(t.x, rawget(t, "x"))
1	nil
​

rawget 揭穿真相：t 本体上确实没有 x，是 __index 给的。什么时候需要穿透？三个典型场合：调试（分清值是自己的还是继承的）、实现 __index/__newindex 本身（钩子内部再走钩子会无限递归）、性能敏感的内层循环（rawget 省掉一次判定）。rawset 则常在 __newindex 里落真值（5.2 节的只读表会用到）。

⚠️ 常见坑：__index 链成环——A 的元表指向 B、B 的元表又指回 A。虚拟机会沿链死循环（或直到栈溢出报错 "loop in gettable"）。手工搭链时给层级做个上限检查，或用函数形态显式控制上溯深度。

元表的元表：__metatable 保护位

一个反直觉的事实：getmetatable 默认返回元表本身，于是拿到元表的人可以改它——类的公共方法表就这样暴露在所有人面前。想锁住，元表里放 __metatable 字段：

local secret_class = {}
local mt = setmetatable({}, {
    __metatable = "locked: instance of secret_class",
})
setmetatable(secret_class, mt)

print(getmetatable(secret_class))     --> locked: instance of secret_class
setmetatable(secret_class, {})        -- 报错：cannot change a protected metatable
​

getmetatable 返回 __metatable 字段的值（替代真身），setmetatable 对带保护位的表直接抛错。库里发放的对象想防篡改（框架实例、宿主下发的 userdata）用这招；代价是调试也看不到真元表了，开发期与发布期要能切换。宿主侧的 userdata 大量使用这个机制：引擎对象的方法表既可被脚本调用、又不可被脚本替换——能力开放与行为防篡改是两件事，元表保护位是后者的开关。

字符串元表之谜的完整答案

第 4 章留了个"先当语法记住"的写法：("abc"):upper()。现在给完整机制：字符串类型的值共享一张语言内置的元表，其 __index 指向 string 库。于是任何字符串值上查方法（本体不是表、没有字段），都会走 5.1 节的查找链咨询这张元表，进而在 string 库里命中函数——冒号调用把字符串自己作为第一个参数传入，恰好就是 string.upper(s) 的签名。

> print(getmetatable("abc").__index == string)
true
​

这就解释了两件事：其一，string 库的所有函数既能 string.upper(s) 也能 s:upper() 调——后者只是查找链的路由结果；其二，给 string 库加函数等于给所有字符串加方法（function string.shout(s) return s:upper() .. "!" end 之后 "hi":shout() 可用）——扩展语言手感的正规姿势，LuaJIT 的 string 扩展库、很多工具库都这么干。同款机制在数字、布尔上不存在（它们没有元表），在 userdata 上由宿主全权定制——一条查找链，三种应用深度。

为什么把行为做成外挂

现在回答本章开头的问题：为什么 Lua 把"行为定义"外挂成元表，而不是像主流语言那样把方法、运算符、继承做进类型系统？

第一层答案是体积与简单：类型系统里的继承、重载、虚函数表，每一个都是编译器与运行时的大件；元表只是"一张普通的表、几个约定名次的字段"，运行时增加的成本近乎为零，手册一页写完。

第二层答案是宿主的可定制性。设想你是游戏引擎作者，想让脚本作者能写 entity.position + entity.velocity * dt——位置与速度是 userdata。如果没有元表，你只能等语言官方加运算符重载；有了元表，你给 userdata 挂上 __add 与 __mul 的 C 实现，表达式立刻可用。宿主不需要改语言，语言把改语言的能力发给了宿主——这是"行为外挂"在寄宿架构里的真正意义。Redis 没用上这层（脚本无自定义类型需求），OpenResty 的 lua-resty 库群与所有游戏引擎的脚本绑定全部踩在这层上。

第三层答案是面向对象不必内建。类、继承、多态，用元表加表能全部搭出来（5.3 节动手）。语言核心不为范式背书，范式以库的形式存在——不喜欢面向对象的团队可以完全不用，喜欢深度范式的团队能搭出自己想要的那一种。Lua 社区因此同时容纳了"纯函数风格"与"完整 class 框架"两个流派，互不干涉。

💡 关键直觉：把元表读作"值班表"。表自己处理不了的事（键扑空、遇到陌生运算符、要自我介绍），就翻值班表找当班的人。值班表可以共用（类）、可以逐级上交（继承链）、可以现场换班（热更新）——而表的本体数据从头到尾没被污染。

安全访问链：查找链的日常应用

多层嵌套表取值（cfg.net.upstream.host）中间任何一层缺席就报错。5.1 节的查找链给三种解法，各有立场：

-- 解法一：守卫链（1.4 节）——简单粗暴，层数多时啰嗦
local host = cfg and cfg.net and cfg.net.upstream and cfg.net.upstream.host

-- 解法二：默认值元表——给嵌套层挂"缺键回退空表"，读永远不炸（但写要小心）
local function auto_table()
    return setmetatable({}, { __index = function(t, k)
        local v = auto_table()           -- 子层也自动
        rawset(t, k, v)
        return v
    end })
end

local cfg2 = auto_table()
cfg2.net.upstream.host = "10.0.0.8"      -- 读写都自动建层
print(cfg2.net.upstream.host, cfg2.net.upstream.missing)   -- 10.0.0.8	table
print(cfg2.net.upstream.missing ~= nil)  -- true——注意：读不存在的键也建了层

-- 解法三：局部 helper——显式、无魔法，团队代码的首选
local function dig(t, ...)
    for _, k in ipairs({ ... }) do
        if type(t) ~= "table" then return nil end
        t = t[k]
    end
    return t
end
print(dig(cfg, "net", "upstream", "host"))    --> nil（cfg 为空时安全返回）
​

解法二的"读也建层"是把双刃剑：访问路径自动生长，遍历时会看到一堆空表——auto_table 适合"写多读少、结构可生长"的场景（构建配置树、测试夹具），不适合当通用读取器。解法三的 dig 函数无魔法、可测试、错误可定位，是多数团队的归宿。三个解法共享同一个知识点：访问的每一步都经过查找链，链上的行为就可以被设计——这就是元表视角看世界的日常。

链的健康检查

继承链搭好后，运行时偶尔要回答"这个方法到底从哪层来"。两个诊断函数：

local function where_defined(obj, key)
    local t = obj
    while t do
        if rawget(t, key) ~= nil then return t, rawget(t, key) end
        local mt = getmetatable(t)
        t = mt and (type(mt.__index) == "table" and mt.__index or nil)
    end
    return nil
end

local Base, Child = {}, {}
Base.greet = function() return "from base" end
setmetatable(Child, { __index = Base })

print(where_defined(Child, "greet") == Base)     --> true
​

where_defined 沿 rawget 手工重走查找链，返回"定义所在的那张表"——排查"方法被哪层遮蔽"时就用它。把它挂进调试工具箱，继承链的可观测性问题就解决了一半（另一半是 5.3 节的层次克制）。

本节要点回顾

• 元表是挂在值上的后备行为表：普通表自由挂载、字符串天生挂、userdata 宿主挂；元表本身是普通表，运行时可查看可替换；
• 读委托、写自立：__index 只在"本级扑空"时咨询，写操作默认落本体；
• 查找链三步：本体 → 元表 index 钩子 → 钩子形态分表（委托、可链式上溯）与函数（计算、可回填缓存）；
• raw 四兄弟绕过钩子只走本体，用于调试、钩子实现与性能内圈；
• 链有成环风险，手工搭链控制深度；
• 行为外挂的三层意义：核心小巧、宿主可定制行为（userdata 挂 C 钩子）、范式以库的形式存在（面向对象不内建）。

下一节盘点元方法全家福——从读写拦截到运算符重载再到生命周期。