将一个生产级 JavaScript 运行时从 Zig 迁移到 Rust 绝非简单的语言替换，而是一次涉及 ABI 兼容性、运行时行为等价性和性能零损耗的系统工程。Bun 项目选择 JavaScriptCore 作为引擎核心，Zig 负责底层内存管理、系统调用绑定和运行时调度，这一架构决定了迁移过程必须围绕「保持 JS 引擎与宿主语言边界稳定」这一核心约束展开。本文将从 FFI 边界划分、核心模块移植顺序、兼容层设计和风险控制四个维度，剖析这一迁移的工程化路径。
FFI 边界设计：建立稳定的跨语言契约
迁移的第一步是定义一套跨越 Zig 与 Rust 的稳定接口层，这套接口必须足够精简以降低维护成本，同时足够完整以覆盖运行时的全部关键入口点。业界通用的做法是采用 C 兼容性层作为桥梁 ——Rust 代码导出 C-ABI 函数，Zig 代码通过 extern 调用这些函数，两者之间仅传递 POD（Plain Old Data）类型和函数指针。
具体到 Bun 的场景，FFI 边界需要覆盖以下运行时核心入口：初始化与关闭流程（bun_runtime_init /bun_runtime_shutdown）、任务调度节拍（bun_runtime_tick）、任务提交与取消（bun_task_submit /bun_task_cancel）、内存分配钩子（bun_alloc /bun_dealloc）以及错误与异常传播机制。每个入口函数应返回或接收一个不透明指针（opaque pointer），指向 Rust 侧的具体实现结构体，避免将内部 Rust 类型直接暴露到跨语言边界。使用 repr (C) 确保结构体内存布局在编译单元之间保持一致，防止因字段重排导致的 ABI 漂移。
边界设计还需考虑事件回调机制。由于 Rust 闭包无法直接跨越 FFI 传递，通常的做法是注册 extern "C" 回调函数指针，将上下文指针（ctx）作为用户数据一并传递。Rust 侧在触发事件时通过这个指针回溯到对应的状态结构。此外，错误处理应统一为小整型错误码加可选字符串的格式，避免将 Rust 的 Result 枚举直接映射到 Zig 侧，造成跨语言类型定义的额外复杂度。
运行时核心模块移植顺序：按风险与依赖排序
确定了 FFI 边界后，移植工作应遵循「自底向上、由静至动」的原则，即先移植不依赖运行时动态特性的底层模块，再逐步迁移涉及并发调度和 I/O 交互的关键路径。参考业界实践和 Bun 自身的模块依赖关系，建议按以下顺序推进。
第一阶段是内存管理原语。Zig 在 Bun 中承担了精细的内存控制职责，包括对象分配器、内存池（arena）和垃圾回收堆的底层接口。迁移这一层时，可以在 Rust 侧实现一个与原有 Zig 分配器 ABI 兼容的封装层，对外提供 bun_alloc 和 bun_dealloc 两个入口，内部可选使用 Rust 的内存分配器抽象（Allocator trait）或自定义的 bump allocator 以保持性能优势。此阶段的验证重点是分配 / 释放语义等价性和多线程下的内存可见性。
第二阶段是任务调度器与协程运行时。Bun 的并发模型建立在轻量级协程之上，调度器负责管理任务的挂起、恢复和公平调度。迁移调度器的核心挑战在于准确移植 yield 语义和唤醒机制。可以先在 Rust 侧实现一个最小化的调度器原型，验证任务创建、挂起和恢复的基本流程，再逐步引入优先级、抢占式时间片等高级特性。调度器的移植通常需要与事件循环紧密配合，这自然引出下一阶段的移植内容。
第三阶段是事件循环与 I/O 抽象。Bun 的网络和文件系统操作通过事件循环驱动，Zig 侧使用 epoll/kqueue 等系统调用实现。事件循环的迁移应保持外部行为不变：相同的回调语义、相同的超时精度、相同的多路复用模式。Rust 生态中有 tokio 和 mio 等成熟的事件循环库可选，但在迁移阶段更推荐实现一个轻量的内部实现，以减少外部依赖带来的兼容风险。
第四阶段是 JavaScriptCore 绑定层。JSC 是 Bun 的 JavaScript 引擎，Zig 通过 bindings.zig 等文件与 JSC 交互。这一层的迁移最为敏感，因为涉及对象生命周期管理、值（Value）引用计数和调用栈展开。建议将此层放在最后，在其他模块均已稳定运行后再进行迁移，或者在迁移期间保持 Zig 侧的 JSC 绑定不变，仅通过 FFI 调用 Rust 实现的其他模块。
兼容层设计：渐进式迁移与并行运行
增量迁移的核心诉求是在任何时间点都能编译出功能完整的可执行文件。实现这一目标的常用模式是「特性门控 + 条件编译」：为每个待迁移的模块创建对应的 Rust 实现，并通过构建时的 feature flag 决定使用 Zig 版本还是 Rust 版本。在迁移早期，Rust 版本可能仅提供桩实现（stub），测试验证通过后逐步填充逻辑，最终在完全替代后移除 Zig 代码。
另一个关键设计是「双写期」（dual-write period）的并行验证。团队可以在 CI 中同时构建 Zig-only 和 Rust-backed 两个版本，运行相同的测试套件并对比行为差异。这种机制能够在回归问题出现的最短时间内定位到具体的移植模块。为了降低维护成本，双写期应设置明确的退出条件，例如当 Rust 版本在指定基准测试集上的性能差距小于 5% 且测试覆盖率超过 99% 时，即可启动 Zig 版本的废弃流程。
兼容层还需要处理运行时配置的统一入口。Zig 和 Rust 两侧应共享同一套配置结构体的定义，确保启动参数、环境变量和行为开关在两侧保持一致。推荐在迁移初期将配置定义抽取到独立的声明式文件（如 JSON Schema 或 TOML），由构建脚本在两端分别生成对应的类型定义，避免手动同步导致的版本不一致。
风险控制：基准测试、灰度回滚与监控告警
大规模迁移的风险主要体现在三方面：性能回退、行为回归和引入新的内存安全问题。针对性能回退，应为每个移植模块建立独立的微基准（micro-benchmark），覆盖启动时间、吞吐量、延迟等关键指标，并在每次合并到主分支时强制执行回归检测。基准测试的阈值设置需要保守一些，建议将可接受差距设定为 10% 以内，超出则阻止合并。
行为回归的防护依赖全面且稳定的测试套件。Bun 已有针对运行时行为的集成测试，迁移过程应将这些测试按模块分组，每完成一个模块的移植就执行对应的测试分组，确保原有语义得到保持。对于难以通过测试覆盖的边界场景（如极端并发条件下的资源竞争），可以借助模糊测试（fuzzing）工具主动触发。
最后，迁移期间的监控告警体系也不可或缺。可以在运行时埋入轻量级的检测点，监控调度延迟、内存分配延迟和错误发生率等指标。一旦 Rust 版本的某项指标偏离历史基线超过阈值，即可触发告警并自动回落（fallback）到 Zig 版本。灰度发布机制可按用户群组或请求量逐步放量，在小规模流量上验证稳定后再全量切换。
资料来源
本文涉及的迁移策略参考了 Rust FFI 最佳实践以及 Bun 项目公开的运行时架构讨论。
- Effective Rust - Item 34: Control what crosses FFI boundaries
- Bun 官方文档 - FFI API