它到底做了什么

Kakehashi 的工作分三步：加载 Darwin 平台的 Mach-O 可执行文件，映射一份独立实现的 libSystem，再把程序发出的 BSD 系统调用翻译成 Linux 能听懂的形式。

关键在于它不是指令模拟器。客户程序的机器码直接跑在 CPU 上——同为 ARM64 架构，本就不需要翻译指令。真正的开销集中在系统调用的边界上：线程本地存储切换、备用栈、NEON 寄存器的保存与恢复，以及运行时内部的分发。程序调用系统接口越频繁，代价越大。

项目目前已经跑通的包括：7-Zip 的命令行版本 7zz（含 `-mmt=4` 多线程压缩这类正确性关卡）、curl 的 HTTP 与 HTTPS 请求，以及若干 clang 编译探针，验证环境为 Docker/Colima 容器与 UTM 虚拟机中的 Linux aarch64。

它还借用了 Wine 的一个概念：bottle。这是一个模拟 macOS 目录结构的根目录，默认放在 `~/.local/share/kakehashi/bottle/`，里面按照 `/usr/local/bin`、`/usr/lib` 等真实路径摆放客户程序，而 `/Volumes/linux/` 则桥接到宿主机的文件系统，方便两边交换文件。

慢 5 倍，为什么还有人用

项目文档里的性能数据给得相当坦诚。在 UTM 上的 Ubuntu aarch64 环境中，压缩一个约 8000 个文件、总计约 240MiB 的目录树：原生 Linux 版 7zz 用时约 22.5 秒，Darwin 版 7zz 在 Kakehashi 下用时约 118 秒，差距约 5.2 倍。文档同时说明，在文件数少、压缩计算密集的样本上，差距往往缩小到 1.1 至 1.2 倍——多文件场景下的巨大差距主要来自路径遍历和逐次系统调用的边界开销，而不是压缩算法本身出了问题。

慢 5 倍还值得用，理由落在持续集成的账单上。项目直接引用了 GitHub Actions 托管运行器的超额计费费率：Linux 双核 arm64 每分钟 0.005 美元，Linux 双核 x64 每分钟 0.006 美元，而 macOS 3 至 4 核机型每分钟 0.062 美元，更大规格的 macOS 机型在 0.077 至 0.102 美元之间。

也就是说，macOS 的分钟单价大约是 Linux arm64 的 10 到 12 倍。即便同样的活在 Linux arm64 上慢 5 倍，账面成本仍可能更低：5 分钟乘 0.005 美元约合 0.025 美元，对比 macOS 1 分钟的 0.062 美元。公共仓库的免费额度和自建 Linux 运行器会进一步放大这个差距，而托管的 macOS 资源本身还更容易排队等待。

项目也划清了边界：涉及图形界面、代码签名与公证、Xcode 界面测试，或者任何不属于”纯命令行 Darwin 程序”的工作负载，macOS 运行器依然不可替代。

还很早期

Kakehashi 用 Rust 编写，通过 `cargo install kakehashi` 安装，实机运行需要 Linux aarch64 环境；而静态检查命令 `kh inspect` 和只加载不执行的 `kh run –dry-load` 在包括 macOS 在内的任意平台都能用。项目要求较新的 Rust 工具链，并同时兼容 4KiB 与 16KiB 两种内存页大小，后者对应 Asahi Linux 那类在苹果芯片上直接运行的系统。

作者对完成度毫不含糊，专门列出一节”尚不构成产品承诺”：完整的 curl 功能集（POST 请求体、代理、端到端 HTTP/3、全部协议）、真正的苹果 Security 框架、git 与命令行开发工具、图形界面和代码签名，目前都还不支持。下一个计划中的能力是通过 `kh install xcode-tools` 支持 git。持续集成里跑的是单元测试、冒烟测试和多线程压缩的正确性关卡，而不是和原生性能比拼耗时。

截至文章抓取时，该项目在 GitHub 上获得 82 颗星，仓库累计 68 次提交，仍处于典型的早期实验阶段。但它给出的思路值得关注：把苹果生态里的命令行构建环节挪到便宜得多的 Linux ARM 机器上，用可接受的速度损失换取真金白银的成本下降——对于持续集成资源紧张的团队，这笔账未必不划算。

来源：GitHub 项目 wie-project/kakehashi 官方说明文档，经 Hacker News Show HN 板块转载讨论