如果一款工具只有 Mac 版本，你通常得找一台 Mac 才能运行。哪怕 Linux 机器和 Mac 都用了 ARM64 处理器，程序也不能直接互通：硬件语言相近，操作系统的“办事窗口”却不同。Kakehashi 想做的，就是在 ARM Linux 上替部分 macOS 命令行程序跑腿，转换它们向系统提出的请求。
它仍是实验项目。下文的兼容性与性能结果均来自项目仓库自述，尚无第三方复现或独立测试。
它不是虚拟出一台 Mac
Kakehashi 是用户态兼容层——运行在普通程序空间里，承接另一套操作系统接口的中间层。它不启动完整 macOS，也不覆盖 Mac 应用生态或 GUI 图形应用。
它首先装载 Mach-O，也就是 macOS 原生程序使用的可执行文件格式，相当于 Linux 常见的 ELF。随后映射项目自带的 libSystem，再把 BSD syscalls 转成 Linux 能处理的请求。syscall 即系统调用，是程序要求操作系统读文件、联网或创建线程时使用的底层接口。
项目选择了“CLI-first、no JIT”：先服务命令行工具，并且不使用 JIT（运行时动态生成机器码）。原因是这些程序与宿主机同属 ARM64／aarch64 架构，Kakehashi 让客程序在处理器上原生执行，主要翻译操作系统接口，而非模拟每条指令。
现在能跑到哪一步？
项目称，它已在 Docker／Colima 和 UTM 内的 Linux aarch64 环境试跑 clang 探针、7-Zip 的 7zz、curl 及线程程序。列出的 7zz 测试包括创建、检测、列出和解压归档；四线程压缩测试的预期结果为 Everything is Ok 和退出码 0。curl 示例则覆盖 HTTP、HTTPS、文件或标准输出，并要求自签名证书测试失败。
使用者可通过 cargo install kakehashi 安装，再运行 kh bottle ensure 准备运行环境，随后用 kh install 7zip 或 kh install curl 获取客程序。/Volumes/linux/… 负责把客程序中的路径接到 Linux 宿主机根目录，方便读写宿主文件。
实时执行只支持 Linux aarch64，包括裸机、虚拟机和 Colima／Docker；其他主机只能执行 dry-load 或 inspect，也就是检查程序能否装载，而不能真正运行。
为什么值得关注？
这条路线的价值不在于“Linux 变成 Mac”，而在于让部分 Darwin 命令行工具有机会进入 ARM Linux 的开发和 CI 流程。项目给出一组 UTM 中 Ubuntu aarch64 的测试：约 8000 个文件、240 MiB 的 7zz 归档任务，Linux 原生版本约需 22.5 秒，Kakehashi 下的 Darwin 版本约需 118 秒，慢约 5.2 倍；少文件、重压缩任务的差距据称可缩至约 1.1～1.2 倍。项目将前者的主要开销归因于频繁遍历路径和跨越系统调用边界。
局限与未知
- 当前展示的是部分 ARM64 命令行程序，不代表完整 macOS、GUI 应用或 Apple frameworks 已兼容。
- curl 的完整功能、
git、codesign 等仍未覆盖；运行时也可能出现缺少 OpenSSL 配置或跳过 Apple framework 的警告。 - 实际兼容率、稳定性和不同工作负载下的性能仍缺少独立数据，现有“Verified”结论应视为项目方的阶段性展示。