先做个稀罕事：这个帖子的数字，我去查了，全对
GitHub API 实时读数（2026-10-05 01:00，两次独立读）：50,494 星，1,809 fork，Apache-2.0，建仓 2025-05-30。所以「5 万星」不假——只是刚过线，是个随时会跌回四万档的门槛数。
版本也对得上：1.0.0 发布于 2026-06-09（container machine 就是这一版进来的），1.5.0 发布于 2026-09-29，一共 24 个 release。
架构那几句也全是 Apple 文档原话：
> it runs a lightweight VM for each container that you create
> Every container gets an IP address on its network
> You need a Mac with Apple silicon to run container
所以这篇不用打假。要补的是三件帖文没写的事。
第一件：一人一间的账单，是内存不还
Apple 在 docs/technical-overview.md 里有一节专门讲这个，标题就叫「Releasing container memory to macOS」：
> The macOS Virtualization framework implements only partial support for memory ballooning … memory pages freed to the Linux operating system by processes running in the container's VM are not relinquished to the host … you may need to occasionally restart them to reduce memory utilization.
翻过来就是：容器里释放的内存不会还给 macOS。你跑十个内存型容器，macOS 看到的占用只会涨不会落，回收办法是重启容器。
「一个容器一台 VM + 独立 IP」这个卖点的账单在这背面。帖文一句没提。
第二件：1.2.0 是 7 月 29 日，五个安全问题里只有三个有 CVE
帖文说「8 月的 1.2.0 一次修了五个安全问题」。实际：
| 版本 | 日期 |
|---|---|
| 1.2.0 | 2026-07-29 |
| 1.2.2 | 2026-08-08 |
| 1.3.0 | 2026-08-24 |
帖文点名的那条——build 时塞 symlink 读到构建上下文外的宿主文件——是 CVE-2026-64777，属实，也是最该升级的一条。
第三件：默认内核是 Kata 的 debug 构建
内核确实来自 Kata Containers，但 1.3.0 起默认是 3.32.0-debug。性能敏感的话得自己 container kernel set 换一个。
顺手补两个日常摩擦点
- 没有 Compose。55 KB 的 command reference 里 "compose" 零命中。子命令有 k8s（实验性，1.5.0 甚至一度把
container k8s start摘掉了），但 Compose 风格的裸主机名互解析至今是 open issue（#1809）。文档原话：*It does not currently work for looking up another container by its bare hostname … the kind of zero-configuration, Compose-style service discovery some users expect.* - macOS 15 的口径是分裂的。README 说 *We do not support older versions of macOS*，同一仓库的 technical-overview 却有一整节 "macOS 15 limitations" 教你怎么在 15 上跑——代价是容器间网络完全隔离、没有
container network。准确说法：官方只认 macOS 26，15 能跑但功能残缺且不管修。
一句话
Docker Desktop 那间大开间，和一容器一单间，是两种隔离模型：前者是「一屋子人共用一套水电」，后者是「漏水只淹自己家」。苹果选了后者，代价是每间房的水表只走不回。这个取舍换 AI Agent 沙箱是对的——Agent 炸了只炸自己那间。
