概念进程内多 Lua VM 之间的数据共享机制解决问题skynet 每个服务是独立 Lua VM如果 100 个服务各 load 一份 500KB 的配置表就是 50MB 浪费。演进过程sharedata老方案云风早期设计实现思路由一个 sharedatad服务把 table 序列化成 C 层的 lightuserdata​ 存起来其他 VM 通过 sharedata.query(name)拿到这个指针每个 VM 用 metatable 代理​ 从 lightuserdata 里查字段并建 proxy 缓存已查过的 key配置表 → C 层 lightuserdata ←→ 各 VM 通过 metatableproxy 访问优点惰性展开初次 query 快热更后旧数据易回收缺点每次访问要走 metatable → C → 回 Luaproxy 随服务数膨胀访问慢、内存占用随服务数涨sharetable2019 年后新方案直接改了 Lua VM 的实现允许多个 VM 共享只读的原生 Lua table且不参与 GC优点等价于访问本地 Lua table无 metatable、无 proxy、不进 GC实测比 sharedata 快 5~25 倍缺点热更麻烦——旧 table 要等所有引用服务退出才能释放C 层内存占用更大选型口诀 不常更新的大配置用 sharetable常更新的小配置用 sharedata数值表、道具表、技能表 → sharetable一次加载反复读运营活动配置、开关类 → sharedata热更友好