从2022年年中开始，Encore工程师想改一行构建系统的代码，都得先SSH进公司那台共享的Linux机器。原因很简单：Encore的构建系统跑在Firecracker microVM里，Firecracker需要Linux的/dev/kvm，而Mac从来没有这个设备节点。这家做后端应用构建与部署平台的公司，用四年时间才把这个死结解开——办法不是等Firecracker官方支持macOS，而是自己重写了一遍Linux镜像工具链，做出一个叫crackling的统一层，同时驱动Linux上的Firecracker和macOS上苹果自家的Virtualization.framework。

这条路走得通，但走不到底。苹果的虚拟化框架里，保存microVM快照这个能力被锁在一个私有权限后面，第三方开发者申请不到。Encore用工程手段解决了"能不能跑"的问题，却没法解决"苹果让不让"的问题。

四年远程开发，问题不是能不能用，是有多别扭

老的流程今天听起来像上世纪的运维故事：新工程师入职跑一次脚本，SSH进共享构建机建账号，从GitHub拉公钥，把人加进kvm和docker组，再把镜像文件和firecracker二进制硬链接到各自的用户目录下。谁改了哪个端口，写在一个每人一份、加了gitignore的CUE配置文件里，全公司挤在一台机器上，靠约定不互相冲突。

这套系统扛住了四年，代价是开发体验和生产体验彻底脱节。本地打个断点没用，因为代码根本不在本地跑；看日志要SSH进去tail文件；挂个性能分析器,先得把工具拷到远程机器上。Encore的产品卖点就是"写代码就该顺手"，自己最核心的构建环节反而是团队里唯一没法在自己电脑上跑的东西。

crackling怎么补上这个洞，又补不上哪里

crackling不是把Firecracker硬塞进Mac，而是在Linux和macOS上各接一个后端，中间用同一份Rust核心描述虚拟机、同一个guest agent通过vsock通信。Linux这边继续用Firecracker+KVM，macOS这边换成苹果的Virtualization框架（简称VZ）。为了让两端启动同一份OCI镜像，团队用纯Rust重写了镜像解析、CPIO打包、内核签名校验这一整套原本只在Linux上跑的工具链。

两个后端能力并不对等。Firecracker有主机网桥、有元数据服务MMDS，虚拟机进程可以在daemon重启后被重新接管；VZ有内置NAT、有virtiofs目录共享、有跑x86二进制的Rosetta翻译，但没有MMDS，虚拟机跟着daemon进程一起死。crackling的做法是给每个能力定义一个Feature枚举，某个后端做不到就在API边界直接报错，不装糊涂。

VZ还有个更麻烦的限制：它的虚拟机对象既不能跨线程发送，也不能跨线程共享，所有操作必须扎在创建虚拟机时的那一个串行队列上跑完。而Encore的daemon跑在tokio上，协程随时可能被调度到别的线程。crackling的解法是开一个全局串行队列专门托管VZ对象，异步那一侧只传纯数据的闭包过去，等结果回来，硬生生把两套并发模型缝在一起。

苹果锁住的那道门

crackling真正卡壳的地方不是工程难度，是权限。VZ框架给了开发者校验虚拟机状态、准备保存快照的接口，调用起来一切正常，但真正执行保存操作时需要一个名叫com.apple.private.virtualization的私有entitlement——顾名思义，私有，第三方开发者拿不到。校验能过，保存永远返回一个笼统的内部错误。

快照恢复不是没写完，是苹果没打算给你写完的机会。

这不是版本迭代能解决的bug，是平台方划的一条线。Firecracker在生产环境里可以把虚拟机挂起到磁盘、秒级恢复，这是microVM相比传统VM的核心优势之一。crackling在macOS上永远做不到这一点，无论团队再花多少个月重写工具链。

  • 风险.macOS开发环境和Linux生产环境之间，快照恢复这类工作流会长期存在结构性缺口，属于平台限制而非工程债务。

没有跑分的技术博客，和一个尚未开源的项目

Encore这篇博客写得很细，代码片段、架构决策都摆出来了,但从头到尾没有给出任何一个性能数字——冷启动延迟、内存开销、单机能并发多少个虚拟机,一概没有。文章暗示的"开发体验和生产环境一致"，目前更接近"功能对等"，不是"性能对等"。

架构层面还有一层没细说的差异：Mac上跑的是ARM64的Linux guest，Encore生产环境大概率还是x86-64的Firecracker主机。Rosetta能让部分x86二进制跑起来，但不等于复现x86的CPU行为，浮点计算、编译产物这类和架构强相关的场景，本地测出来的结果未必能照搬到生产。

Firecracker官方的立场也值得对照。2025年年初，社区里已经有人提交过一个用VZ在Apple Silicon上跑ARM64 Linux guest的可行性验证，报告的性能接近原生，但明确标注"非生产就绪"，且关掉了不少KVM专属特性。Firecracker维护者最终没有把macOS支持纳入路线图。Encore这次相当于在官方明确拒绝的方向上，自己动手把轮子造了出来——这条路目前看不到对应的公开代码仓库，外部开发者暂时没法验证，也没法直接复用。

  • 结论.crackling解决的是"能不能在Mac上跑"，苹果的entitlement政策决定了"跑得多像生产"这道题目前没有答案。