应嵌入C绑定运行时（Lua）或纯Go轻量引擎（JS），取决于脚本类型、性能需求及是否接受Cgo；需规避生命周期不一致、栈错位、异步陷阱、内存泄漏及安全风险。
为什么不用 os/exec 调外部 Lua/JS 解释器
直接起 lua 或 node 进程跑脚本看似简单，但实际会卡在 IPC、启动开销、状态隔离和错误堆栈映射上。比如 os/exec 返回的错误是字符串，无法还原成 Go 的 error 类型；变量传参得序列化再反序列化，map[string]interface{} 一嵌套就容易丢类型；更别说热重载或并发执行时资源竞争问题。
真正可行的路径只有两条：嵌入 C 绑定的运行时（Lua），或用纯 Go 实现的轻量引擎（JS）。选哪个，取决于你要跑什么脚本、性能敏感度、以及是否接受 Cgo。
- 要跑已有 Lua 模块（如 OpenResty 生态）、追求极致性能 → 用
golua或layeh/gopher-lua - 只跑简单逻辑判断、不想引入 Cgo、部署要纯静态 → 用
robertkrimen/otto（已归档但稳定）或denysvitali/go-js（基于 QuickJS） - 完全拒绝 JS/Lua 语法，只要表达式求值 →
antonmedv/expr更轻、更安全
layeh/gopher-lua 常见 panic 场景与规避方式
这个库最常因“Go 和 Lua 生命周期不一致”崩溃，比如在 Lua 函数里保存了 Go 对象指针，之后 Go 对象被 GC，Lua 再访问就 panic。典型错误现象是 panic: runtime error: invalid memory address or nil pointer dereference，但堆栈指向 L.Call 或 L.SetField。
- 永远用
L.NewTable()创建表，别用make(map[string]interface{})转过去 —— 后者字段名会全变成小写，且嵌套 map 会丢失结构 - 注册 Go 函数给 Lua 调用时，函数签名必须是
func(*lua.LState) int，返回值是栈上返回值个数，漏写return 1就会导致栈错位 - 不要在 Lua 协程里调用
time.Sleep或阻塞 IO —— 它不支持真正的协程调度，会卡死整个 VM - 加载脚本用
L.DoString而非L.LoadString+L.Call，后者没做异常捕获，panic 会透出到 Go 层
用 denysvitali/go-js 执行 JS 脚本的最小可靠模式
它基于 QuickJS，支持 ES2020，不开 Cgo 也能编译（用 CGO_ENABLED=0），但默认启用了 Promise 和 async/await，这会让简单脚本意外变异步——你以为 L.RunString("1+1") 立刻返回结果，其实它可能返回一个 pending Promise。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时加
js.WithPromise(false)关掉 Promise 支持，除非你真需要异步逻辑 - 传参进 JS 只能通过全局变量注入，比如
L.Set("input", inputMap)，不能直接当函数参数传；JS 里读取就是input.user_id - 获取返回值统一用
L.Get("result")，别依赖RunString的返回值 —— 它只返回错误，不返回计算结果 - 每次执行完记得
L.Free()，否则内存泄漏比 Lua 还快（QuickJS 的 GC 不自动触发）
动态脚本的安全边界怎么划
没有沙箱的脚本引擎等于给自己留后门。Lua 默认无文件/网络访问，但一旦你注册了 io.open 或 os.execute，风险就和 eval Python 一样大。JS 引擎更危险，denysvitali/go-js 默认禁了 eval 和 Function 构造器，但如果你手动挂了 fetch 或 require，那就完了。
- 删掉所有自带的全局对象：Lua 里用
L.SetGlobal("os", L.Nil)，JS 里用L.Set("fetch", L.Null()) - 超时控制必须靠 Go 层实现 —— Lua/JS 自身没有 reliable timeout 机制；用
context.WithTimeout包住整个执行流程，然后在回调中调L.Close() - 内存限制只能粗粒度：Lua 用
L.SetMemoryLimit(1024 * 1024)（单位字节），JS 引擎目前没暴露该接口，只能靠进程级 cgroup 限制
最麻烦的不是语法限制，而是时间复杂度失控：一个 while(true){} 在 JS 里能吃满一个核，而 Go 层根本感知不到。这类问题没有银弹，只能靠预编译检查 + 执行超时 + 进程隔离三重兜底。
