当前位置：首页 > news >正文

Rust 插件系统怎么选：Lua 已经成熟，但 QuickJS 值得一试

news 2026/7/29 9:43:37

最近读到一篇关于 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 的机会，是连接新的开发者群体。