核心难点是生命周期管理：需用 userdata 存指针、metatable 绑 __index/__gc，避免泄漏或崩溃；sol2 必须显式声明构造函数；tolua++ 依赖 .pkg 中头文件与模块顺序。
用 luaL_newmetatable + lua_pushcclosure 手动绑定最可控
直接暴露 C++ 类给 Lua 的核心难点不是“怎么写”，而是“谁负责生命周期”。手动绑定能明确控制对象创建、方法调用和析构时机，避免野指针或重复析构。关键在于两件事：把 C++ 对象指针塞进 Lua userdata，并用 metatable 关联 __index 和 __gc。
常见错误是只注册方法不设 __gc，导致 C++ 对象泄漏；或者把原始指针直接存进 Lua 而不加类型检查，结果 Lua 误传 nil 或其他类型进去，static_cast 崩溃。
- 用
lua_newuserdatauv(L, sizeof(MyClass), 0)分配 userdata 内存，然后在上面 placement-new 构造对象 - 调用
luaL_newmetatable(L, "MyClass")创建唯一 metatable（名字必须全局唯一） - 把 C++ 成员函数包装成 static C 函数，用
lua_pushcclosure(L, myclass_method, 0)推入栈，再挂到 metatable 的__index表里 - 务必设置
__gc元方法：它接收 userdata，从中取出指针并显式调用析构函数 +operator delete
sol2 绑定时别漏掉 sol::constructors()
如果你选 sol2，它默认不生成任何构造函数绑定 —— 这意味着 MyClass.new() 在 Lua 里根本不存在，但编译器不会报错，只会运行时报 attempt to call a nil value。
真正要写的是：
lua.set("MyClass", sol::usertype<MyClass>(
sol::constructors<MyClass(), MyClass(int)>(),
"value", &MyClass::value,
"do_something", &MyClass::do_something
));
注意点：
立即学习“C++免费学习笔记（深入）”；
-
sol::usertype不会自动推导构造函数，必须显式列出所有想暴露的构造签名 - 如果类有虚析构函数，
sol2能正确处理；但若没有，且你绑定了继承体系，得手动加sol::base_classes, sol::bases<base>() - 成员变量绑定用引用（
&MyClass::x），绑定函数也必须是普通成员函数或 static，不能是 lambda（无法取地址）
用 tolua++ 时路径和 .pkg 文件顺序决定符号可见性
tolua++ 不是运行时反射，而是预处理生成 C++ 绑定代码。它的核心配置文件（.pkg）里，#include 的顺序和 tolua_module 的嵌套层级，直接决定 Lua 中能否访问某个类的父类方法或同名重载函数。
典型症状：Lua 调用 obj:foo() 报错 attempt to call a nil value，但 C++ 编译通过、头文件也包含了 —— 很可能是 .pkg 里没先声明父类，或 tolua_beginmodule 层级包错了。
- 确保所有基类在派生类之前出现在 .pkg 中，且用
tolua_usertype显式声明 - 重载函数必须用
tolua_function逐个绑定，不能靠名字自动匹配；参数类型要写全，比如int和const int&算两个不同函数 - 生成的 .cpp 文件需加入项目编译，且链接时确保
tolua库已包含（不是头文件就够了）
析构逻辑最容易被忽略的三个地方
无论用哪种方式，C++ 对象销毁和 Lua GC 的节奏不同步是最大隐患。不是“绑上了就安全了”，而是稍不留神就 double-free 或访问已释放内存。
- 手动绑定时，
__gc元方法里必须检查 userdata 是否已被析构过（比如加一个bool alive标志位），因为 Lua 可能多次调用__gc -
sol2默认用 shared_ptr 管理对象，但如果你传入裸指针（如sol::object构造时用了sol::light），那就完全失去自动管理，必须自己保证生命周期长于 Lua 引用 - 从 Lua 返回 C++ 对象指针给 C++ 层使用时（比如回调），千万别直接存指针 —— 应改用
sol::reference或sol::protected_function_result持有引用，否则下一次 GC 就可能回收
