【语法算法】Lua+元方法__index为表：代理转发的表本质

【语法算法】

__index 元方法有两种形态：填一个函数，或者填一张表。填函数的写法大家熟，但"填表"这个形态才是继承、默认值和代理转发真正的地基。今天拆的问题是：当 t.k 查不到时，Lua 到底把这张表拿来做了什么？为什么 setmetatable(son, {__index = father}) 一行就能让 son 拿到 father 的全部字段？它和函数形态的边界又在哪里？

一、查不到时的"二次寻址"

__index 为表的语义一句话讲完：rawget 失败后，把这次查找原封不动地转发到那张表上。注意是"转发查找"而不是"拷贝字段"——father 里有什么，son 就能读什么，且 son 从不写入 father。查 son.name 时，解释器先在 son 自己的哈希部分找；找不到，发现元表挂着 __index 且它是表，就转去查 father.name；再找不到，还会继续沿 father 的元表往上递归——这就是原型链查找。整个过程对读取是自动的，对写入完全不生效：son.name = "x" 永远落在 son 自己身上，此后 son 自己有值就遮蔽（shadow）父表的值，父表同键改动对 son 不再可见。还要注意 __index 只在键不存在时触发——键存在但值为 nil 与键不存在在 Lua 里是同一个事实，所以"显式置 nil 的字段"会重新落回父表，这是做字段删除回退时的关键细节。

local father = { hp = 100, atk = 25 }
local son = setmetatable({ atk = 40 }, { __index = father })
print(son.hp)    -- 100  转发到 father
print(son.atk)   -- 40   自有字段优先（遮蔽）
son.atk = nil    -- 遮蔽解除, 重新转发 → 25
son.hp = 999     -- 写入只落在 son, father.hp 仍是 100

二、用它做只读代理与默认值合并

因为"读转发、写落地"的天然分工，__index = 表 顺手就能做两件工程常事。其一是默认值合并：把默认配置放底层表，实例配置放顶层表，读取时实例没有的键自动落到默认值，写入时全部收敛到实例——默认配置从头到尾不可被污染，比手写"遍历 pairs 补默认值"省一次拷贝，且默认表后续加字段自动对所有实例生效。其二是只读代理：给底层配置表配一个空 __newindex 函数抛错，顶层只暴露 __index 转发，读畅通、写被拦。相比"函数形态的 __index"，表形态省一次 Lua 函数调用、转发在 C 层完成，是官方文档明确推荐的更快路径。唯一要防的是环：如果 a 的 __index 指向 b、b 又指回 a，一次查不到的访问就无限递归直接栈溢出；搭多层继承时必须保证链单向无环，深度也建议控制在三四层内——每层转发都有一次元表查找的开销，链太长读热路径会退化。

local DEFAULT = { volume = 50, quality = "high", fps = 60 }
local function newCfg(over)
    return setmetatable(over or {}, { __index = DEFAULT })
end
local cfg = newCfg({ volume = 80 })
print(cfg.quality)   -- high，来自默认表
cfg.volume = 30      -- 写入仅落在 cfg

flowchart TD
    A["读 son.k"] --> B{son 自身有 k?}
    B -->|有| C[返回 son.k]
    B -->|无| D{元表 __index 是表?}
    D -->|是| E["转发查找 father.k"]
    E --> F{father 有 k?}
    F -->|有| G[返回 father.k]
    F -->|无| H[沿 father 元表继续递归, 链尾返回 nil]
    D -->|是函数| I["调用 __index(son, k)"]

三、与函数形态的分界线

什么时候用表、什么时候用函数？判断标准只有一条：查找规则是否需要"计算"。纯转发、纯继承、纯默认值——全是静态规则，用表；需要按键名做运算（比如 __index 里拼路由表、做大小写不敏感匹配、首次访问时懒加载字段并回写缓存）才升级成函数。函数形态签名固定为 __index(t, k)，返回什么 t.k 就是什么，它有表形态给不了的"按需构造"能力，代价是每次缺失访问都过一次 Lua 调用栈。工程上还有两个常见误区要避开：第一，修改 father 的字段后 son 的读取立即同步变化，因为转发是实时的、零拷贝的——想"快照"就自己 pairs 拷一份，别指望元表冻结；第二，pairs(son) 只遍历 son 自身字段，不会沿 __index 递归，"打印全部配置"这种需求要自己写递归遍历或显式合并。表形态 __index 的本质就一句话：它是把"读"的失败路径重定向到另一张表的地址改写——理解成一次零拷贝的查找回放，继承、默认值、只读代理就全都是它的自然推论。

四、标准类构造器里的表形态

表形态最著名的工程落地就是 Lua 社区通用的类构造器模板：Class.__index = Class。这个写法初看很怪——类表给自己挂 __index 指向自己——拆开看就通了：实例是 setmetatable({}, Class) 造出来的空表，访问 obj:method() 时实例里当然没有方法，查找失败触发元表，__index 指向的正是方法所在的类表，于是一次转发命中方法。方法永远只有一份存在类表里，实例只存自己的状态字段，内存与查找两优。要继承，就再叠一层：setmetatable(Child, {__index = Parent}) 让 Child 自己的查不到的方法转发到 Parent，两层表形态 __index 一竖一横，构成"方法查子类优先、退父类"的完整链。读链深度即维护成本，社区惯例是提供 Class.super 引用方便显式调用父类构造器，而不是无限加深链长。写自己的构造器模板时有个易错点要提醒：__index 必须挂在元表上、元表必须挂到实例上，两个 setmetatable 少一个都查不到方法；调试时拿 getmetatable(obj).__index 一查便知转发目标对不对。把模板吃透后你会发现：所谓面向对象，在这门语言里只是表形态 __index 的一次标准应用——没有 class 关键字，两条转发规则就撑起了全部对象系统。下次在项目里看到 __index，先问自己它是表还是函数、转发目标是谁、链有多深——三个答案凑齐，这段对象代码的行为就再无悬念。