Go GopherLua 多个 goroutine 能不能共用同一个 LState

不能把同一个 GopherLua LState 直接交给多个 goroutine 并发调用。官方 README 明确说明，LState 不是 goroutine-safe；更稳妥的模型是“一个 goroutine 独占一个 LState”，需要协作时通过 Go channel 传递普通数据。

官方地址：https://github.com/yuin/gopher-lua

一、一个 LState 不应被多个 goroutine 同时使用

LState 不只是一个配置对象，它里面还包含 Lua 栈、调用帧、全局环境和运行时对象。两个 goroutine 同时执行 DoString、Call 或 PCall 时，可能交错修改这些状态，结果轻则返回混乱，重则出现数据竞争或不可复现的错误。

这里的关键不是“给调用点加不加锁”，而是所有权。若用 sync.Mutex 把整个 LState 包住，确实可以避免同时进入，但多个 goroutine 最终仍会排队使用同一个 Lua VM，生命周期、错误恢复和性能边界都更难判断。除非业务明确接受串行执行，否则不建议把它当作并发设计。

二、把共享点拆开：每个 worker 独占 LState

最小改造是让 worker 在自己的 goroutine 内创建 LState，并在退出前关闭它。channel 只传递字符串、数字或自定义任务结构等普通数据，不把 *lua.LState、*lua.LFunction、userdata 和带元表的 table 送到另一个 worker。

type Job struct {
	ID    string
	Input string
}

func worker(proto *lua.FunctionProto, jobs 

生产代码还要为停止信号设计退出路径，例如把 jobs 换成带 context.Context 的 select，并保证所有 worker 都能执行到 Close。如果一个请求必须等待 Lua 结果，结果 channel 还应带上请求 ID，避免超时后出现错配。

三、共享只读字节码，不共享运行时状态

“每个 worker 一个 LState”不等于每个 worker 都要重复解析 Lua 源码。GopherLua README 给出的边界是：多个 LState 可以共享编译后的只读字节码，因为 Lua 脚本不能修改它；运行时仍然要在各自的 LState 中创建函数并调用。

因此可以把编译步骤放在 worker 启动前，得到一个 *lua.FunctionProto，再把这个只读对象传给多个 worker。不要把某个 LState 中已经创建好的函数、线程或 table 当成“编译结果”跨状态复用。图中的共享部分只有字节码，栈和全局变量仍按 worker 隔离。

四、对象池与 NewThread 的边界

如果创建 LState 的成本需要控制，可以做一个受锁保护的对象池，但“取出到归还”期间必须由单个 worker 独占，不能把同一个实例同时借给两个 goroutine。归还前应清理本次任务写入的全局变量、栈和临时资源；如果脚本会改变全局环境，最好按任务隔离或直接新建状态。

L.NewThread() 创建的是同一个 Lua VM 内的协程对象，适合 Lua 层的 yield/resume 协作，不等于给 Go 并发创建了一个线程安全的 LState。它仍然属于父状态的运行时边界，不能用来绕开“一个 LState 不被多个 goroutine 同时使用”的规则。

常见问题

给 LState 加互斥锁后还能不能用？

可以把它变成串行访问，但这不是多个 goroutine 并发执行 Lua。若只是保护一个低频管理操作可以接受；若目标是并行处理任务，应改为每个 worker 独占状态。

Lua 脚本里的全局变量会不会在 worker 间同步？

不会。每个 LState 有自己的运行时环境；需要共享的数据应在 Go 层明确传输，或通过 channel 设计消息协议。

对象池取出的 LState 能跨请求复用吗？

可以，但一次只能被一个 worker 持有，并且要定义清理和归还规则。无法确认脚本状态是否可重置时，新建 LState 更安全。

落地前可以只检查四件事：是否存在跨 goroutine 共享的 LState、是否把 Lua 运行时对象塞进 channel、是否把 NewThread 误当成 Go 并发隔离、是否在 worker 退出路径调用了 Close。这四项都明确后，GopherLua 的并发边界基本就不会靠运气维护。