将ClojureScript搬进QuickJS：轻量运行时的嵌入式实践

把 ClojureScript 放到一个不到 1MB 的 JS 引擎里跑意味着什么大概两年前我尝试过在自己的树莓派和几个低配服务器上跑 ClojureScript 应用。当时最大的感受不是语言本身不顺手而是运行时太重一个最简单程序也要拉动 Node.js再算上 npm 依赖光空跑一次就有几十兆内存。这在开发机上完全不是问题但放到嵌入式场景、边缘设备或者一个宿主应用想内嵌脚本引擎的时候成本就立刻变得刺眼。这也是我在看到 “Show HN: Choq: Cherry (ClojureScript) on QuickJS” 这个项目时会停下来细看的原因。它把一个专门面向轻量化的 ClojureScript 方言 Cherry放到了 QuickJS 这个以小型化著称的 JavaScript 引擎里。组合起来就是你依然写 ClojureScript 风格的代码但运行时不再是 Node.js而是一个只有几兆甚至更小的嵌入式 JS 引擎。这个方向看起来像个“小众中的小众”但它真正试图解决的问题并不小众当你想在资源受限、需要快速启动、或者需要被宿主应用安全嵌入的环境里跑函数式代码时我们一直没有太好用的路径。Choq 想补上这一块。这篇文章就顺着这个项目展开聊清楚它到底做了什么、真正适合谁、落地会踩到什么坑以及这类组合为什么值得长期关注。1. 先搞清楚这个组合真正解决的是哪类重复劳动很多人看到 ClojureScript、QuickJS 这两个词第一反应是“这跟我有什么关系”。在没有尝试过用 JS 引擎嵌入脚本、没有接触过边缘计算和嵌入式 JS 之前确实会觉得它很遥远。但实际上它解决的问题就藏在一个很常见的抱怨里我只是想写一段脚本为什么需要启动一个那么庞大的运行时1.1 ClojureScript 的舒适与重量ClojureScript 是 Clojure 语言在 JavaScript 平台的编译目标。它保留了 Clojure 的大部分语法和核心思想不可变数据结构、函数式风格、强大的序列操作、以及 REPL 驱动的开发体验。对于熟悉 Lisp 家族语言的人来说这是一种非常“舒服”的编写体验——你可以用很少的代码完成很复杂的逻辑而且因为数据结构默认不可变代码的可预测性比普通的命令式脚本要高很多。但舒服归舒服运行时的体积和启动成本一直是个问题。ClojureScript 传统上跑在 Node.js 上。Node.js 本身是一个功能完整的运行时加上 npm 生态任何应用跑起来都是几十兆起步。这在服务器、桌面工具、Web 应用层面完全不是问题。可一旦你想把一段用 ClojureScript 写的业务逻辑放到微型设备、边缘网关或者嵌进某个应用内部的脚本环境里Node.js 就显得太“重”了。如果你只是做开发测试重一点无所谓。真正的问题在于很多脚本场景根本不需要完整的 Node.js不需要文件系统、网络栈、进程管理那一大套能力。它们只需要一个能解释 JS、能执行逻辑、能被我控制的执行引擎。1.2 Cherry不是 ClojureScript 的替代品而是轻量化的那一面Cherry 是一个 ClojureScript 方言。它的设计目标是尽可能小、尽可能快、尽可能无依赖。对它来说写出来的代码看起来非常接近 ClojureScript但省去了很多为了兼容大型生态而承担的包袱。我理解 Cherry 的设计取舍是这样的把编译器本身和生成的运行时都控制在一个非常轻量的范围内。它不是 “换个品牌”而是真的把目标定成“给小设备、小板卡、快启动场景用的 ClojureScript”。在常见实践里如果你之前在写 ClojureScript切到 Cherry 的迁移成本不算高因为语法几乎一样。但如果你的项目大量使用了某个大库、某个与完整 CLJS 运行时强绑定的特性那就需要额外验证兼容性。1.3 QuickJS一个能够“随身携带”的 JavaScript 引擎QuickJS 是 Fabrice Bellard 开发的一个 JavaScript 引擎。它最大的特点是小巧和可嵌入。整个引擎可以做到小于 1MB同时支持 ES2020 的标准特性。它不是“另一个运行时”而是一个可以像库一样被你的宿主应用链接进去的引擎。这意味着你可以写这样的程序#include quickjs/quickjs.h int main() { JSRuntime *rt JS_NewRuntime(); JSContext *ctx JS_NewContext(rt); const char *code var result 6 * 7; result;; JSValue val JS_Eval(ctx, code, strlen(code), input, JS_EVAL_TYPE_GLOBAL); // 读取 val得到 42 return 0; }在 Node.js 里启动一个事件循环、加载一堆模块、管理一堆内部机制资源开销是明确的。而 QuickJS 是你想用就创建一个 Runtime跑完就销毁。它天然就适合作为宿主应用的上层脚本引擎。Choq 做的事情正好把这两者接起来。2. Choq 做了什么把“编译结果”放到“迷你运行时”里执行2.1 编译器与运行时的解耦理解 Choq 之前要先建立一个基础认识ClojureScript 和 Cherry 这一类语言编译完之后的产物并不是要跑在某个专门的“Clojure 虚拟机”里而是生成 JavaScript 代码再由目标 JavaScript 引擎来执行。所以一条链路可以是CherryClojureScript 方言源码 ↓ 编译 JavaScript 代码 ↓ 加载 QuickJS 引擎Choq 做的事情就是把这条链路打通用 Cherry 把 ClojureScript 代码编译成 JS然后把编译结果加载进 QuickJS 运行。这样一来整个执行环境从“Node.js 一堆依赖”变成了“QuickJS 这个极简引擎 对应 JS 文件”。这个变化的价值不在于“更快”——毕竟编译和加载总还是需要时间的。它的核心价值在于把重量级运行时从环境里拿掉了。你可以把 QuickJS 嵌入到任意一个宿主程序里哪怕那个宿主程序是一个 C 写的服务、一个嵌入式应用、或者一个边缘网关。2.2 为什么不是 Node.js也不是浏览器我先解释为什么这个组合值得单独做出来而不只是“在 Node.js 里编译然后扔到浏览器跑”。Node.js适合开发丰富的服务端应用但它不适合做“宿主应用的内部脚本引擎”。你很难把一个 Node.js 塞进一个 C 应用里并保证安全隔离、可控生命周期、低资源占用。浏览器适合跑前端但它的宿主环境不是你自己的程序你不能在嵌入式设备里轻易拉开一个浏览器窗口。QuickJS的位置恰恰在这两者中间它给你完整的 JavaScript 执行能力同时保留你作为宿主程序的完全控制权。这就像你需要一个能对话的人不想让他住在你的房子里也不想把他送去酒店。你真正需要的是一个随时可以来、干完活就走、而且你完全知道他每天吃什么喝什么的临时员工。QuickJS 就是这个临时员工Cherry 是让他能听懂你用的函数式指令集的翻译官。2.3 技术关键点模块加载、宿主接入、运行时边界如果你准备尝试 Choq有以下几个关键点需要理解编译结果是 JS 文件。Cherry 的编译产物不是一段用 eval 执行的小片段而是一个完整的、可以被引擎加载的 JS 文件。所以流程上通常是这样先用 Cherry 编译得到一份out.js再把它交给 QuickJS。宿主环境需要处理输入输出。QuickJS 本身不关心你的脚本要去调文件系统、要打印日志、要读取环境变量。它只负责执行。你需要自己把宿主能力绑定到 JS 环境里。Choq 在这个方向上会定义好哪些原生函数可以被 ClojureScript 代码调用但一般来说它不会把 Node.js 的全部 API 带进来。运行时的边界决定了代码能做什么。你用 Cherry 写代码时不能默认所有 ClojureScript 生态的库都能直接跑。因为运行时不是 Node.js那些依赖 js 对象、依赖process、依赖 Node 全局对象的标准库在 QuickJS 环境里可能不存在。我一般会建议把 Choq 想成一个“受控的执行容器”。它适合承载你写得足够独立的逻辑数据转换、状态机、业务规则、事件处理。不适合承载依赖大量系统能力的脚本。3. 从零跑通 Choq最小流程、关键参数、验证路径这部分按“最小可用流程”来写。核心原则是不要一上来就优化先确认一条链路完整通了再逐步扩展。3.1 环境准备先准备三样东西Node.js用于跑 Cherry 编译器。Cherry 作为编译器本身是在 Node 环境下运行的你没有必要把 Cherry 编译器搬到 QuickJS 里去跑。QuickJS 引擎可以根据平台选择预编译版本也可以从源码构建。如果是嵌入式设备cross compile 是常见路径。一份 Cherry 写的脚本。在常见配置里你的目录结构可以是这样的choq-demo/ src/ main.cljs # Cherry 源码 out/ main.js # 编译产物 host/ main.c # QuickJS 宿主程序3.2 写一份最小 Cherry 脚本不附加任何多余假设先写个能验证链路的功能。比如一个斐波那契数列计算或者一个字符串处理。它的价值在于它能证明源码编译、JS 生成、QuickJS 执行、结果返回这四个环节都正常。(ns choq-demo.main (:require [clojure.string :as str])) (defn greeting [name] (str Hello, name !)) (def result (greeting Choq)) (println result)如果你是熟悉 ClojureScript 的开发者这个代码几乎是零迁移成本。3.3 编译和运行Cherry 的编译命令会输出一个 JS 文件。常见写法类似cherry compile src/main.cljs --output out/main.js然后在 QuickJS 宿主程序里加载这个文件JSValue result JS_Eval(ctx, js_code, js_len, out/main.js, JS_EVAL_TYPE_MODULE);如果你没有自定义宿主程序也可以用 QuickJS 自带的命令行工具先做验证qjs out/main.js这一步如果输出了你预期的字符串说明这条链路已经通了。3.4 如果卡住了按这个链路排查我第一次整合这类组合时最容易出问题的不是编译和运行本身而是几个很隐蔽的小环节。如果遇到问题按以下顺序排查看编译是否成功如果 Cherry 报错通常是源码语法、命名空间或宏使用问题。看生成的 JS 文件是否存在、非空如果编译通过但 JS 文件没生成检查输出目录是否可写、路径是否写错。看 QuickJS 是否支持代码里用到的 JS 特性Cherry 编译出来的代码可能用到某些较新语法。不同 QuickJS 版本对 ES 特性的支持不完全相同。看宿主程序是否声明了需要的外部对象如果脚本里调用了console.log、setTimeout、fetch但这些没有在 QuickJS 环境里预先注册脚本会在运行时抛错。看日志和返回值在宿主程序里通过JS_IsException判断执行结果再用JS_GetException取出错误信息。别把“引擎没有 crash”当成“执行成功”。注意先跑通一个最简脚本比一上来就写完整模块更重要。一次只验证一件事能帮你快速定位问题到底出在编译器、引擎还是宿主绑定。3.5 从最小示例到批量场景的衔接当你确认最小示例跑通后可以逐步增加复杂度增加第二个函数验证模块化没问题。增加字符串和数组操作验证核心库函数正常。增加宿主绑定函数比如从 C 侧传一个数字数组给 JS 处理再拿回结果。这个过程本质上是在构建一个可复用的模板。只要你有了一套“编译 → 生成 JS → 加载进 QuickJS → 返回结果”的脚手架后续每次写新的业务逻辑你就只需要替换 Cherry 源码。4. 选型之前先想清楚Choq 适合谁不适合谁即使链路跑通也不意味着它应该被用到所有场景。它有一条非常明确的适用边界。4.1 更适合这些场景嵌入式脚本引擎你的程序由 C/C 写主逻辑但希望某些业务规则可以热更新不重新编译主程序。把 Cherry 编译成 JS再交给 QuickJS 执行正好满足。边缘设备和资源受限环境存储空间、RAM、CPU 都有限跑 Node.js 成本过高。QuickJS 的镜像很小Cherry 生成的 JS 也不算臃肿。宿主应用内的扩展机制类似游戏内脚本、编辑器插件、自动化工具的高级配置。你想给用户暴露一种比 JSON 更灵活的表达方式又不想为了让用户写脚本而上整套 Node.js。追求启动速度和隔离性的服务组件QuickJS 可以独立创建和销毁 Runtime每个 Runtime 之间天然隔离。用 Cherry 写业务规则理论上可以做到快速加载、运行、回收。4.2 不太适合的场景依赖大量 ClojureScript 生态库的项目Cherry 的轻量化是有代价的很多基于完整 CLJS 运行时的库、宏、宿主 API 可能无法直接用。需要完整 Node.js 能力的高复杂度业务如果代码要操作数据库、访问网络、处理文件系统、管理子进程与其费劲在 QuickJS 里重新绑定能力不如直接用 Node.js。团队里大家都只熟悉 JavaScript 的项目引入 ClojureScript 方言需要学习成本除非你本身就是 Lisp 爱好者否则不要为了“技术新鲜感”引入。4.3 一个通俗的判断标准你可以用一个“脚本复杂度阶梯”来判断阶段适合的语言/方案理由配置和简单规则JSON / YAML简单但表达力有限中等复杂动态逻辑Lexical / QuickJS 内嵌绑定动态、轻量、可热更新复杂业务模块Cherry / 完整 CLJS Node.js需要更丰富的生态大规模应用ClojureScript 成熟后端 / 前端框架需要体系化能力Choq 所在的位置是中间那一层。它给的是一种比配置文件表达力强得多、又比完整 CLJS 应用轻量得多的方案。5. 这类组合背后的趋势运行时轻量化会越来越重要5.1 从“万物基于 Node.js”走向“按需选择运行时”过去十年里JavaScript 的成功让很多工具默认选择了“都跑在 Node.js 上”。好处是生态统一坏处是运行时体积、启动时间和资源占用很难受控制。虽然 Node.js 本身也在不断优化但它毕竟是一个功能完整的通用运行时对于“只希望宿主程序能执行一段脚本”这样的需求来说规格是超配的。QuickJS 这类小型 JS 引擎的出现打破了“JavaScript 只能跑在大运行时里”的固有印象。配合 Cherry 这类轻量方言你可以做到语言层面是 Lisp 风格执行层面是一个极小依赖的引擎。这两件事组合在一起产生的结果不是“性能提升”而是“场景扩展”——原本不适合跑脚本的设备或宿主现在可以了。5.2 让 ClojureScript 有机会走向更多设备ClojureScript 一直被看作偏向浏览器或 Node.js 平台的选项。但如果有越来越多的轻量引擎、轻量编译目标支持类似 ClojureScript 的语法和语义那么“用 ClojureScript 写嵌入式边缘规则”就不再是奇怪的事情。从工程经验看这更多是一种长期可能性。Cherry 本身还在快速迭代期Choq 这类整合项目也更像是一种思路验证。它真正的价值在于给社区展示了一条路径函数式语言不是必须和“重量级运行时”绑定的。5.3 长期使用的关键拼图隔离、日志、热更新和宿主绑定如果决定把这个组合放进生产环境不能只停留在“能跑”。至少还要补上这几块隔离策略QuickJS 的 Runtime 之间是隔离的但同一 Runtime 内多个脚本之间你需要设计好资源上限和超时控制。日志和错误上报QuickJS 执行异常时要通过宿主程序捕获并把有效信息传递到你的业务日志里否则排障会非常痛苦。热更新机制业务规则变化时你需要让新编译出的 JS 文件能够被安全加载不影响正在运行的任务。宿主 API 的权限控制你往 JS 环境里注册哪些函数决定了脚本能做哪些事。这是安全边界要在设计期就想清楚不要等上线后再补。注意不要把 QuickJS 当成“性能升级版 Node.js”。它的价值在于轻量可控不在性能优势。如果你需要极高吞吐基于 JIT 的引擎可能是更适合的选项。6. 我的建议先跑一个最小验证再决定要不要深入Choq 这类项目在拿到手的那一刻最不该做的事就是“先读完全部文档再动手”。文档永远比运行慢。更好的路径是花十分钟把最小示例跑通再决定是否值得投入。我也建议把“编译链路”和“运行时链路”分开理解。Choq 的核心是一条编译链路Cherry 源码 → JS加上一条运行时链路QuickJS 加载 JS。你甚至可以不依赖 Choq 的固定封装自己组装这两部分。自己动手组装一遍远比单纯看项目介绍更能理解它的设计取舍。如果只是想尝鲜准备 Node.js 和 Cherry 编译器。写一个最简单的 ClojureScript 风格函数。编译后扔进 QuickJS 命令行里看输出。一切正常再考虑写宿主绑定。如果想放进生产项目先确认你的核心业务逻辑不依赖完整 CLJS 运行时。测试 QuickJS 在你目标设备上的编译和运行表现。设计好宿主绑定的 API 边界。从“一条业务规则”做起而不是一上来迁移整个系统。说到底Choq 吸引我的地方不是“又一个新玩具”。它代表了一种取舍把语言体验从运行时重量里解放出来。我们过去习惯了“反正编译到 JS就用 Node.js 跑”但这其实只是历史惯性不是技术必然。随着 QuickJS 这类小型引擎越来越成熟像 Cherry、Choq 这样的轻量组合会越来越多。它们不会取代 Node.js也不会取代浏览器它们会去填一个以前长期得不到足够重视的中间层一个让逻辑可以被动态加载、快速执行、安全隔离、又不需要庞大运行时的地方。对你来说如果手上恰好有类似场景这个项目值得花一个下午尝试。如果没有也不急着入坑。但至少下一次你再看到“某个编译到 JS 的方言”可以下意识多问一句它真的必须在 Node.js 上跑吗答案可能比你以为的更多样。