苹果亲儿子 container 项目，实测 virtiofs 性能吊打 OrbStack，顺便把这背后的坑讲清楚。 macOS 不是 Linux，Docker 靠的 cgroups、namespace 全是 Linux 内核概念。 所以不管 Docker Desktop、OrbStack、Podman，在 macOS 上跑容器都得先起一个 Linux 虚拟机，容器其实是在虚拟机里跑的，不是直接跑在你的 macOS 上。 你的文件在 macOS 上（比如外接硬盘），容器在虚拟机里，两边隔着一层虚拟机边界，要让容器访问外接盘，得把 macOS 目录"共享"进虚拟机，这层桥接技术叫 virtiofs——不走网络协议，走的是虚拟机和宿主机之间的共享内存通道，理论上比 NFS/SMB 那种网络共享快。 但这层桥接是有限流的。我这次测试是 128 并发对 23 万个文件做 stat，这种极端并发下 virtiofs 守护进程要同时处理海量文件句柄请求，OrbStack 的实现直接 ENFILE（文件表溢出）——不是外接盘的问题，是桥接层扛不住。 苹果自己的 container 为什么就扛住了？ virtiofs 本身是苹果操作系统内核和 Virtualization.framework 里的东西，苹果自己既是协议设计者也是实现者。第三方工具是在苹果开放的框架上层搭自己的虚拟化栈，底层调优空间有限。 苹果用自家 Containerization 框架加自家 VM 方案，文件句柄队列深度这些参数调得更狠，同样的桥接技术，扛并发的能力天差地别。之前我以为"virtiofs 协议本身有并发上限，换哪个工具都一样"，这个判断是错的，限制在于各家实现的成熟度，不是协议本身的天花板。 顺带一提，真 Linux 机器（NAS、VPS）跑容器根本没这问题——容器和宿主机共享同一个内核，不用起虚拟机，不用 virtiofs 桥接，外接盘挂载点直接被内核当普通文件系统访问，没有中间层。这也是为什么 NAS 跑容器化图库从来不是问题，坑是 macOS 独有的。 文件访问这块 container 已经证明能打，但 build 工具链还很嫩（相对路径解析有 bug、registry 连接失败会疯狂重连），修复 PR 提了还没合并。 适合先玩起来，别急着上生产。