Rust 插件系统怎么选：Lua 已经成熟，但 QuickJS 值得一试
最近读到一篇关于 Rust 插件系统设计的文章。作者 fmiras 对几种常见方案进行了比较：原生动态库、嵌入式脚本语言、WebAssembly、表达式引擎。最后他的推荐方向很有意思：如果要给 Rust 程序增加插件能力，脚本语言通常是更值得优先考虑的方案，而在 JavaScript 方案里，他更推荐 QuickJS，而不是 V8。
这个结论有点出乎意料。因为说到嵌入式脚本语言，过去三十年的答案几乎一直是 Lua。Nmap、Wireshark、Neovim，以及大量游戏引擎，都证明过 Lua 作为插件语言的可靠性。
那么问题来了：既然 Lua 已经这么成熟，为什么还会有人考虑 QuickJS？
这背后真正变化的，不是哪门语言更先进，而是插件系统面对的人变了。
Lua 为什么能成为过去三十年的答案
Lua 的成功，并不是因为它拥有最复杂的能力。恰恰相反，它成功的原因是克制。
Lua 从设计之初就是为了嵌入其他程序：体积小、容易集成、语法简单、宿主程序可以控制暴露给脚本的能力。对于软件作者来说，这意味着可以很低成本地给程序增加扩展能力。
Nmap 的 NSE（Nmap Scripting Engine）使用 Lua 编写网络扫描脚本，已经运行多年。Wireshark 支持 Lua 编写协议解析器，让用户可以扩展自己的分析能力。Neovim 将 Lua 作为主要插件语言，让编辑器生态从 Vimscript 迁移到更现代的脚本环境。甚至 Rust 编写的终端文件管理器 yazi，也选择 Lua 作为插件接口。
这些案例说明了一件事：Lua 不是一个”老语言”，它是一个已经被大量软件验证过的嵌入式扩展方案。
那为什么还需要 QuickJS？
因为插件作者正在变化。过去设计插件系统时，开发者面对的问题是”我应该给用户提供哪一门适合嵌入的语言”，Lua 几乎是最好的答案。
但今天很多项目面对的是另一批开发者，他们可能每天使用 JavaScript、TypeScript、Node.js、Web 工具链。对于他们来说，Lua 不是难学，但它是一门额外需要学习的语言。
于是 QuickJS 提供了一种新的可能：让插件作者继续使用 JavaScript，而宿主程序又不需要引入完整的浏览器级运行环境。
这才是 QuickJS 真正有意思的地方。它不是为了证明 Lua 不够好，而是在解决另一个问题：如何让更多已经会 JavaScript 的开发者参与软件扩展。
QuickJS 和 V8 的区别，不只是性能
既然选择 JavaScript，为什么不用 V8？因为 V8 解决的是另一个问题。V8 是为了让 JavaScript 在浏览器和 Node.js 中高速运行，拥有即时编译、高度优化的执行引擎、完整运行时。这些能力让 V8 非常强大，但也带来了更高的嵌入成本。
而插件系统很多时候并不需要极限性能。一个插件可能只是修改配置、增加一个命令、扩展一个工作流、添加一个自动化动作。这种场景下，运行时大小、启动速度、集成难度，可能比峰值性能更重要。
QuickJS 选择了另一条路线：它没有追求成为最快的 JavaScript 引擎，而是成为一个更容易嵌入的软件组件。
QuickJS 值得关注的三个原因
JavaScript 是很多开发者的共同语言
插件生态最大的成本，不只是技术成本，还有人的成本。一门语言越接近插件作者已有的技能，生态越容易建立。过去 Lua 降低了”嵌入脚本”的门槛，今天 QuickJS 降低的是”让 JavaScript 开发者参与软件扩展”的门槛。
它比完整 JavaScript 运行时更适合嵌入
很多软件并不需要一个完整 Node.js，它们需要的只是”执行一段脚本，并让脚本调用几个受控接口”。QuickJS 的定位刚好符合这种需求。
没有 JIT 也是一种取舍
很多人看到 JavaScript 引擎，会自然想到性能。但插件系统的重点通常不是跑分。没有 JIT，意味着运行时更简单，初始化成本更低，也减少了一部分复杂执行路径。对于很多扩展场景，这是一种合理交换：牺牲部分极限性能，换取更容易嵌入。
插件语言没有赢家，只有不同取舍
| 场景 | 选择 |
|---|---|
| 需要长期稳定的嵌入式插件生态 | Lua |
| 插件作者主要使用 JavaScript / TypeScript | QuickJS |
| 需要更强隔离能力 | WebAssembly |
| 只执行规则和过滤逻辑 | CEL 等表达式语言 |
| 极致性能，接受复杂度 | 原生动态库 |
没有一种方案适合所有情况。Lua 的优势，是三十年的生产验证。QuickJS 的机会，是连接新的开发者群体。
写在最后
过去三十年，Lua 证明了一件事：插件语言最重要的，不是语法有多漂亮，而是能不能长期陪伴一个系统成长。
QuickJS 的出现，则说明了另一件事：插件生态的竞争对象，不只是技术，也是开发者。
以前，软件需要问”哪门语言最适合作为插件语言”，现在它还需要问”我的插件作者已经会什么”。
Lua 已经是成熟答案。而 QuickJS，可能是下一批工具值得尝试的方向。它不是替代 Lua，它只是在现代 JS 语境下，让 Rust 项目可以极低成本地接住 JavaScript 庞大的开发者红利。