要隔离的是内核还是系统调用：microVM 和用户态内核换掉的其实不是同一层

「我们用的是容器，所以已经隔离了。」

这句话在很多场合没错。容器确实把进程表分开了，把文件系统的视图分开了，把 CPU 和内存的账目也分开了，一个容器里 ps 出来的东西和另一个容器里 ps 出来的东西是两回事，一个容器吃满内存也不会直接把另一个容器的进程 kill 掉。日常跑自己团队写的服务，这套机制足够好，好到几乎所有人都会默认它是「隔离」。

但它的成立有个前提：内核是同一份。

只要你的机器上跑的都是你自己团队编译出来的二进制，同一份内核是优点——页缓存共享、连接复用、内核态的数据结构只用维护一套，省内存也省 CPU。可一旦你要在同一台机器上执行别人提交的一段脚本、别人上传的一个插件、别人触发的一次构建任务，这句话就不成立了。你分开了进程和文件视图，但你没有分开内核；那份内核是所有人共用的，而且它对外暴露的那张系统调用表，是任何一段用户态代码都能直接敲的门。

于是真正要分辨的问题浮出来：你要隔离的到底是「内核」，还是「系统调用面」。

这两个问题听起来是一回事，工程上完全是两回事，对应的也是两套方案。一套是把边界往上推到硬件虚拟化层，让每个实例拿一份自己的内核，这条路走到今天最有代表性的实现是 Firecracker 这类 microVM；另一套是把边界停在系统调用入口，让系统调用进的不是内核而是一个用户态实现，这条路最有代表性的实现是 gVisor 这类用户态内核。中间还夹着 Kata Containers 这种「用虚拟机承载容器接口」的第三条路。

很多选型讨论之所以吵不出结果，是因为两边在比「谁更快」。说实话，这个比较方向从一开始就偏了，下文会把真正的变量摆出来。

隔离边界一共可能有四层，每层挡住的和挡不住的是两回事

先把「隔离」这个词拆开。它不是一堵墙，是一叠墙，你可以选择把最外面那道防线砌在哪一层。

第一层，进程与文件视图层。 这一层做的是「你看到的根目录不是我的根目录」，典型手段是 chroot、pivot_root 加上 mount namespace。它挡住的是路径层面的互相看见：你 ls / 出来的东西和我 ls / 出来的东西不一样，你装的包不会覆盖我装的包。它挡不住任何安全意义上的东西——只要攻击者在同一份内核上拿到了执行任意代码的能力，他面对的是完整的一张系统调用表，换不换根目录没有任何区别。所以这一层的定位很清楚：它是打包与依赖隔离的便利设施，不是安全边界。把它当安全边界用，是这些年最常见也最危险的一个误解。

第二层，内核层。 也就是 namespace、cgroup、seccomp、capabilities 这一整套。它挡住的东西是实打实的：进程可见性归 pid namespace 管，网络栈归属归 net namespace 管，资源账目归 cgroup 管，能调用哪些系统调用归 seccomp 管，能做哪些特权动作归 capabilities 管。容器之所以敢被叫作容器，靠的就是这一层。

它挡不住的也很明确，而且这一条才是本文的重点：内核本身没有被分开。同一份内核意味着三件麻烦事。第一，内核漏洞的影响半径覆盖这台机器上的全部容器，一个提权漏洞打到的是宿主内核，Namespace 拦不住。第二，/proc 与 /sys 的暴露面是共享的，你在容器里读到的很多条目其实反映的是宿主机的状态，这些伪文件系统既给了攻击者信息，也给了他干扰邻居的抓手。第三，内核内部那些全局账目——目录项缓存、索引节点缓存、网络连接跟踪表、文件描述符上限、共享内存与信号量这类 IPC 对象——不是按容器记账的，一个容器把它们吃掉，另一个容器的行为会跟着变，而且这种变化很难归因。

换句话说，第二层挡住了「越界访问」，没挡住「内核共享」。

第三层，系统调用入口层。 思路是：既然问题出在那张门上，那就把门换掉。你的系统调用不再陷入真内核，而是进一个运行在用户态的实现，由它来决定这个请求要不要、以及怎么样转发给真内核。它挡住的是整条陷入内核的路径——攻击者即使用户态拿到了任意代码执行，他打的是那个用户态实现，不是真内核，真内核的攻击面因此被大幅收缩。

它挡不住的是这个实现覆盖不到的部分。一个用户态实现不可能把 Linux 内核几十年积累的行为全部复刻，缺的 syscall、/proc 下缺失或字段不同的条目、行为不一致的 ioctl、以及那些「返回成功但语义微妙不同」的角落，都是这一层必然要付的代价。这一层的强项是部署轻，弱项是行为覆盖不全，而这个弱项在兼容性敏感的业务上会被放大。

第四层，硬件虚拟化层。 guest 有自己的内核、自己的页表、自己的中断与设备模型，CPU 提供的虚拟化指令让边界落回到硬件给出的那道线上。它挡住的是内核这一整层：guest 里发生的内核漏洞打的是 guest 内核，不是宿主内核。它挡不住的是虚拟机管理器本身、是设备模型的实现、是宿主机上那些依然共享的物理资源。

把这四层并排看，规律非常直白：边界每往上砌一层，挡住的东西变多，但你自己要维护的东西也变多。 第一层几乎不用维护；第二层是操作系统自带的；第三层你要接受一个第三方实现的行为差异；第四层你要自己准备并维护 guest 内核与镜像。选型从来不是「哪层更强」，而是「我愿意为多挡一层付多少长期维护成本」。

microVM 换掉的那一层：Firecracker 把边界推到了硬件线上

Firecracker 是 AWS 开源的一个 microVM 管理器，出身场景是 Serverless——也就是那种「同一台机器上要跑大量彼此不信任的短任务」的地方，这个出身决定了它的全部设计取向。

它基于 KVM，guest 拥有独立的内核与虚拟硬件边界。这一点是它与容器最本质的区别：容器里所有实例共享宿主内核，microVM 里每个实例自带一份内核。前面说的那三个麻烦——内核漏洞的影响半径、/proc 与 /sys 的共享暴露面、内核全局账目的争抢——在这条路上被整体移走了。

真正值得学的是它对设备模型的裁剪态度。传统虚拟机的攻击面有很大一部分来自设备模拟：BIOS、PCI 总线、USB 控制器，这些为了兼容性保留下来的东西，既是代码量也是漏洞源。Firecracker 的做法是刻意把设备模型削到极薄，只保留 virtio-net、virtio-block 这类极少量设备，把 BIOS、PCI 总线、USB 这类面直接去掉。说白了就是不追求「像一台完整的 PC」，而追求「刚好能跑起一个 Linux 任务」。 少一样设备，就少一片要维护、要打补丁、要审计的代码。

另一侧是 jailer。硬件边界解决的是 guest 到 host 的越界，但 Firecracker 这个用户态进程本身也跑在宿主机上，它自己需要被收口。jailer 这个进程干的就是这件事：在启动 microVM 之前，先用 cgroup、namespace 与 seccomp 把这个管理器进程自身再关一层。这是一个很清醒的设计——硬件边界不等于进程边界，两道都要有。

量级上，AWS 公开材料给出的口径是：单个 microVM 的内存开销在数 MiB 量级，启动在百毫秒量级，单台宿主机每秒可以创建上百个 microVM。注意这里说的是公开材料给出的量级，不是某种具体环境下跑出来的确定值；不同宿主机配置、不同 guest 内核与 rootfs 尺寸下，落到你手里的数字会有明显出入。但量级本身足以说明问题：这个量级让「每个租户一台虚拟机」从奢侈变成了可算的账，这才是 microVM 这个品类的意义。

代价也摆在明面上。你要准备 guest 内核，要准备 rootfs，要决定内核与 rootfs 的匹配关系，要维护这条链上的更新与回滚。镜像分发方式会直接影响你的实例密度和启动延迟，单台宿主机到底能开多少实例，由内存、vCPU 调度与镜像分发方式共同决定，不是一个能随手拍出来的数字。这些工作量不会出现在技术方案的亮点页里，但会实实在在出现在你未来两年的运维排期里。

用户态内核换掉的那一层：gVisor 把边界停在系统调用入口

gVisor 是 Google 开源的用户态内核，走的是完全不同的思路：不动硬件，不动内核，把系统调用那张门换掉。

它的两个核心组件分工很清楚。Sentry 在用户态实现系统调用，也就是说应用程序发起的系统调用进的是 Sentry 而不是真内核；Gofer 进程负责代理文件系统访问，把文件相关的请求转到外面去处理。这样切分的好处是：应用程序的绝大部分请求在用户态就被消化了，真正穿透到宿主内核的调用被收敛到一个很小的集合里。

它的取向也很坦诚：不追求百分之百的 Linux 系统调用与行为兼容。 这不是偷懒，是设计选择——Linux 内核的行为面太广，全量复刻既不可能也不划算，与其做一个处处凑合的复制品，不如把边界做扎实，把兼容性缺口明确列出来。代价是某些 syscall、/proc 下的字段、ioctl 与特定内核行为会缺失或者行为不同。历史上它提供过 ptrace 与 systrap 等不同运行平台，其差别本质上是「用什么机制把系统调用拦下来」，取向不同，开销与覆盖也不同。

这条路最大的现实优势是不需要 KVM。它就是一个用户态进程，不依赖硬件虚拟化扩展，因此在那些拿不到嵌套虚拟化的云主机上依然能跑。前面提过，microVM 这条路在多数云主机上是走不通的，因为多数云主机不提供嵌套虚拟化支持（这一点需向服务商确认）；用户态内核不受这条限制，这是它在实际部署中经常被低估的竞争力。

它最大的现实劣势也只有一个词：行为差异。你的业务代码不会管你在用哪种沙箱，它只管调用。一次 ioctl 返回的参数不同、一个 /proc 条目读不到、一个文件锁的语义微妙偏移，表现出来就是「在我本地好好的，上了沙箱就偶发异常」。这类问题排查成本很高，因为它不会稳定复现，也不会在日志里说清楚是哪一层出了岔子。

第三条路：Kata Containers 把虚拟机塞回容器接口后面

Kata Containers 做的事用一句话就能说清：用轻量虚拟机承载 OCI 容器接口。上层继续用容器工具链，该怎么写镜像怎么写，该怎么起容器还怎么起；底层拿到的却是硬件虚拟化边界，每个容器跑在自己的 guest 内核里。

它的定位不是「更强的容器」或「更轻的虚拟机」，而是迁移成本最低的那条升级路径。如果你已经有一套基于容器接口的构建、分发与调度流程，但其中的负载开始变得不那么可信，那么把底层从共享内核换成轻量虚拟机，改动集中在运行时一侧，业务侧几乎不用动。这一点是 microVM 原教旨方案给不了的——Firecracker 那套接口不是 OCI，你要自己写一层适配。

代价是它同时继承了两边的负担：KVM 依赖、guest 内核与镜像管理这些虚拟机的活一样没少，而容器接口带来的兼容性期待又是满格的，用户会默认「容器能跑的它都能跑」。所以选 Kata 时，最该先问的不是性能，而是「我们现有的镜像里有没有依赖宿主内核行为的东西」。

决策第一变量是实例的生命周期与密度，不是性能

现在说那个真正决定划算与否的变量。

把两台机器摆在一起跑同一个负载，看谁快，这个比较意义不大。真正会改变结论的是两个量：一个实例活多久，以及同一时刻要开多少个。

先说生命周期。microVM 这类方案每次创建实例，都要付一笔固定成本：guest 内核要引导，rootfs 要就绪，网络与那几个 virtio 设备要初始化，jailer 要完成收口。按公开材料给出的量级，这笔成本在百毫秒量级。百毫秒摊到一个跑两小时的实例上，等于零；摊到一个跑三百毫秒的函数上，等于把开销翻了一倍还不止。毫秒级短命实例和小时级长命实例，算的是两本完全不同的账。

反过来看用户态内核。它没有 guest 内核引导这一环，实例创建更接近起一个进程，固定成本低得多，短命实例上这笔账明显更好看。但它的成本在另一侧：每个实例的行为差异风险、Sentry 自身在处理密集系统调用时的开销、以及 Gofer 代理文件访问带来的路径变长。负载越是系统调用密集、越是文件操作密集，这笔成本越往上走，而且它跟实例活多久关系不大，是按调用次数计费的。

所以一个粗糙但有用的判据是：生命周期越短，越应该避开需要引导内核的方案；运行期系统调用越密集，越应该避开在用户态拦截每一次调用的方案。 这两条线交叉的地方，就是你要拿真实负载去验证的区间。

再看密度。密度决定的是单台宿主机能开多少实例，它由三样东西共同决定：每个实例的常驻内存、vCPU 的调度方式、以及镜像怎么分发。microVM 每个实例自带一份内核，常驻开销里有一份是内核自己的；用户态内核每个实例也有一份 Sentry 状态，但不需要独立内核镜像。谁更省，取决于你的负载是内存敏感还是 CPU 敏感，也取决于你的镜像能不能在本地缓存住、能不能在多个实例间复用。单台能开多少实例这件事，最终是被镜像分发方式卡住的，而不是被内存卡住的——这一点很多团队是在扩容时才发现的。

所以真正该算的账是三项相加：每实例常驻开销乘以并发峰值，加上每次启动的固定成本乘以创建频次，再加上行为差异导致的返工成本。前两项大家都会算，第三项几乎没人算，而它往往最大。一个缺失的 syscall 让某个构建任务在百分之几的概率下失败，排查加绕开加回归，花掉的人天远超那点机器钱。

兼容性怎么验收：先列清单，再谈选型

既然代价的大头在行为差异，验收就必须走在选择之前。顺序反了，就是先买后试。

通用做法是拿你的真实负载跑一遍系统调用与行为清单，把缺的东西记录下来，再决定方案。注意这是通用工程方法，不是某个具体环境下的测试结论，你的结果只有你自己跑出来才算数。清单至少要覆盖下面这些面。

系统调用面。 先抓一遍你的负载实际用到哪些 syscall，尤其是那些不那么常见的：与进程控制相关的、与内存映射相关的、与定时器相关的、与事件通知相关的。抓出来之后和用户态内核的覆盖情况对照，缺的直接进清单。不要只看主流程，异常路径、清理路径、信号处理路径用到的 syscall 同样要算。

/proc 与 /sys 依赖面。 很多程序会去读伪文件系统：读内存信息、读 CPU 数量、读网络统计、读自身进程的某些条目。这些读取在共享内核下和在用户态实现下拿到的内容未必一致，字段缺失、数值为零、文件整个不存在，这三种情况都要分别记下来，因为它们导致的失败形态完全不同——有的是崩溃，有的是静默地做出错误决策，后者更麻烦。

ioctl 与设备相关行为。 ioctl 的语义高度依赖具体设备与驱动，是用户态实现最容易与原内核分岔的地方。凡是涉及终端、块设备、网络接口配置、以及各类/dev 下节点的调用，都要单独过一遍。

文件锁与共享内存行为。 flock、fcntl 锁、POSIX 与 System V 的共享内存与信号量，这类行为在跨进程、跨实例场景下的语义非常微妙。构建工具、数据库类进程、以及一些语言运行时的多进程模型都重度依赖它们。

语言运行时与第三方依赖。 这一条最容易被漏掉。很多语言的原生扩展会直接碰到内核行为：Node 的原生插件、Python 的 C 扩展、JVM 的某些诊断接口、Go 运行时的调度与内存相关行为。你的业务代码可能一行特殊调用都没有，但你依赖的库里有。

工具链特性。 调试器、性能分析工具、以及那些依赖 ptrace 或 perf 事件的组件，在沙箱里的表现往往和裸机不一样。如果你的流水线里包含性能剖析、代码覆盖率采集、或者某种插桩，这些要单独验证。

清单列完要做一次分级：能改代码绕开的和只能换方案的，分开记。前者只是工作量，后者是硬约束。分级之后，选型其实已经自动完成了——硬约束为零的方案里挑一个生命周期最划算的就行。

还有一条经验：清单要写成能跑的东西，不要写成文档。写成一份能自动执行的验证脚本，每次沙箱版本升级都跑一遍。这类差异往往是在升级后才冒出来的，靠人记不住。

宿主机侧的真实约束：KVM、嵌套虚拟化、内核与镜像

方案选得再漂亮，落不到机器上就是纸上谈兵。宿主机侧有几条硬约束，必须在选型之前确认。

第一条，microVM 依赖 KVM。 这不是软件依赖，是硬件能力依赖。宿主机必须能加载 KVM 相关模块并提供 /dev/kvm 设备节点，运行实例的用户或进程要有访问它的权限。没有这一条，Firecracker 和 Kata 这条路直接封死。

第二条，多数云主机不提供嵌套虚拟化支持，需向服务商确认。 这条最容易被跳过，也最容易在采购之后才发现。你在云主机里再开一层虚拟机，需要宿主机把虚拟化扩展透传进来，这件事很多云服务商默认不做，有的做了也要单独申请或选择特定机型。所以如果你打算在云主机上跑 microVM，下单之前必须把这条问清楚，不要假设它有。物理机上这条约束通常不存在，但也不要默认，CPU 型号、BIOS 里的虚拟化开关、宿主机内核是否编入了相关模块，任何一环断了都跑不起来。

第三条，宿主内核版本。 虚拟化相关的模块在新旧内核上的行为与性能特性有差异，某些 cgroup 版本、某些 namespace 行为、seccomp 的可用过滤能力也和内核版本相关。jailer 那一层收口能不能做扎实，取决于宿主内核提供什么样的能力。这一条建议和内核的长期支持策略一起看，不要选一个很快就要退出维护的内核。

第四条，镜像分发。 前面说过密度会被镜像分发卡住，这里补一句具体形态：rootfs 是从网络拉取还是本地缓存，多个实例间能不能复用同一份底层存储，镜像更新时怎么保证正在跑的实例不受影响。这三件事决定了你的扩容速度和故障时的恢复速度。

一万网络深耕 IDC 19 年（成立于 2007 年），要在物理机上跑这类沙箱，签约前最好先问清宿主机是否支持嵌套虚拟化、单台能开多少实例。

如果确认下来宿主机拿不到 KVM，也不用非得换机器——这正是用户态内核的存在价值。它不依赖硬件虚拟化扩展，在受限环境里是唯一能拿到「比容器更强边界」的选项。反过来，如果你的负载里有一堆绕不开的内核行为依赖，那么即使宿主机不支持嵌套虚拟化，也值得考虑换到支持它的机型上，而不是硬把负载塞进用户态内核里改代码。

镜像与内核版本管理：新增的运维面从哪里长出来

这一段写给那些正准备上 microVM 或 Kata 的团队。硬件边界带来的不只是安全收益，还有一整套以前不存在的运维工作。

内核版本选择。 你需要为 guest 选一个内核版本，并决定它和 rootfs 里用户态组件的匹配关系。这个选择不是一劳永逸的：内核有自己的维护周期，你选的版本什么时候停止维护、你打算什么时候升、升级时 guest 里的用户态组件会不会跟着变，这些要排进日历里。以前这些事归宿主机管，现在归你管。

补丁与漏洞响应。 内核漏洞公告出来之后，你的响应链条比原来长一环：要重新构建内核、重新构建或验证 rootfs、重新分发、再滚动替换正在运行的实例。这条链上任何一环慢了，你的安全收益就打折——毕竟你做硬件隔离的初衷就是为了把内核漏洞的影响半径关小，结果补丁三个月都没打上去，那道边界就白砌了。把隔离做上去却把补丁流程落下，是很常见的翻车方式。

镜像构建与体积。 rootfs 的体积直接影响分发速度和实例启动延迟，也影响单台机器能缓存多少份。构建流程要不要纳入 CI、基础镜像多久重做一次、业务层与基础层的分层怎么切，这些决策会一路传导到扩容速度上。经验上，把镜像构建当成发布流水线的一等公民来维护，比事后优化要省事得多。

兼容矩阵与回滚。 guest 内核和 rootfs 不是任意组合都能跑的，你需要维护一个明确的兼容矩阵，并且让每个运行中的实例都能报出自己用的是哪一组。回滚预案也要提前定：是回滚内核、回滚 rootfs、还是回滚整个组合，不同选择的恢复时间和风险不一样。

灰度与观察。 新内核、新镜像上线要有灰度路径，而且要有能观察到的指标：启动失败率、启动耗时分布、运行中的异常退出率。这几个指标一旦出现台阶，大概率是内核或镜像的变更引入的，没有它们就只能靠用户投诉来发现问题。

把这些加起来会发现一件事：microVM 的门槛从来不在能不能跑起来，而在能不能长期维护下去。 跑通一个 demo 是一周的事，把上面这套流程建起来并稳定运行，是一个持续投入。团队里没有人愿意长期认领这件事的话，方案再先进也别上。

故障域与噪声邻居：隔离强不等于体验好

还有一个容易想当然的地方：以为边界砌到硬件层，噪声邻居问题就没了。

没有。硬件边界挡住的是越界，挡不住争抢。CPU 时间片、内存带宽、磁盘 IOPS、网络包转发能力，这些物理资源在同一台宿主机上依然是共享的。一个邻居把磁盘吃满，你的实例照样卡；一个邻居疯狂发包，你的网络延迟照样抖。隔离解决的是「他能不能碰到我」，不是「他会不会挤到我」。

而且引入 guest 内核之后，争抢的形态还会变。每个实例自带一份内核，意味着内核自己的缓存、页表、各类内核态数据结构都要各留一份，内存放大的方向变了。原来是一份内核缓存服务所有容器，现在是 N 份内核缓存各服务一个实例，实例数一多，这部分开销会变成密度的主要限制项。所以你会看到一个反直觉的现象：边界变强了，单台能开的实例数反而可能下降，这不是方案不好，是账本来就该这么算。

故障域也要重新看。microVM 把单个实例的内核故障关在了实例里，这是进步；但它引入了一个新的共享故障点——虚拟机管理器本身，以及宿主机上的 KVM 层。这一层的漏洞影响的是整台机器上的全部实例，比单个容器逃逸的影响面还大。所以前面提到的 jailer 那层收口不是可选项，是必选项。

用户态内核这边也有自己的故障域问题：Sentry 进程处在所有实例的请求路径上，它是共享的攻击面，也是共享的性能瓶颈点。它的健壮性直接决定了整机的稳定性，而它恰恰是你引入的、需要自己盯着的组件。

宿主机本身依然是单点，这一条不会因为选了哪套沙箱而改变。机器掉电、RAID 卡故障、上游网络中断，所有实例一起消失。沙箱解决的是实例之间的隔离，不是机器级别的可用性，这两件事别混在一起谈。真要可用性，靠的是把实例散到多台宿主机上，以及一套能快速重建的镜像分发体系。

不同业务形态下的取舍推演（以下为典型部署思路，并非特指某一真实客户）

把前面的判据落到具体业务上，推演一遍会更清楚。下面这些是按典型部署形态做的推演，不代表某一真实客户的实际环境。

在线判题。 特征是代码完全不可信、单次执行时间短、并发峰值高、需要严格限制资源。生命周期落在秒级甚至更短，这本来是用户态内核占优的区间；但判题的另一面是语言种类繁多，编译型语言要跑编译器、要链接、要处理文件，系统调用面相当宽，而且选手代码里什么都可能写出来。这类场景下我倾向于先把系统调用清单摸清楚：如果清单里的缺口都能靠预装运行时和限制语言特性绕开，用户态内核更划算；如果出现了「某些语言的调试接口或特定 ioctl 不可用」这类硬缺口，那就转 microVM，用常驻实例池把启动成本摊掉——判题的并发是有波峰的，预热一批常驻实例来接请求，比每次现场创建要现实得多。

CI 构建沙箱。 生命周期在分钟级到十几分钟级，比判题长得多，启动固定成本几乎可以忽略，直接把 microVM 这笔账做平了。但它的兼容性清单是最重的：构建过程会用到各种工具链、包管理器、容器嵌套、调试与剖析工具、大量文件操作，还有可能依赖特定的伪文件系统内容。在这类场景下，兼容性验收的优先级高于一切，甚至应该在选型之前先花一两周把清单跑出来。按照经验，构建类负载最容易踩的是工具链特性那一类，而不是业务逻辑本身。

低代码平台与插件执行。 生命周期极短，往往跟着一次请求走，行为面相对可控——毕竟插件能调用什么，平台本来就会做一层封装。这类场景的关键动作不是选沙箱，而是把系统调用面收敛成一份白名单：先把插件 API 限制到一个明确集合里，再去看这个集合需要的 syscall 有哪些。收敛之后，用户态内核通常就够用了；如果平台允许插件引入原生依赖，那收敛就失效了，得按不可信代码处理，回到硬件边界那条路上。

SaaS 多租户函数。 多租户意味着租户之间互不信任，函数意味着生命周期短且创建频次高，这两条正好把两套方案各自的优势区都点亮了。这类场景是 microVM 的原生主场——Serverless 出身的技术本来就是为它设计的——但前提是你能把常驻开销和镜像分发这两件事做扎实。能不能在宿主机上缓存住常用镜像、能不能让一批实例复用同一份底层存储，决定了你的成本曲线是平的还是陡的。反过来，如果你的函数运行时已经把能力收得很窄（比如只跑一种语言、只放开一组标准库），那用户态内核的性价比会更高。

浏览器自动化实例。 生命周期通常在分钟级到小时级，重 IO、进程数多、依赖共享内存与各类设备节点，还经常要跑截图、PDF 导出这类偏重的操作。它的生命周期长到足以摊平 microVM 的启动成本，但它的系统调用面宽到足以让兼容性验收变成一场硬仗，尤其是共享内存与 /dev/shm 相关的行为。这类场景我更建议先用真实负载把清单跑透，再决定：如果清单干净，硬件边界带来的稳定性收益在这个生命周期上是划算的；如果清单里有一堆绕不开的项，那就别硬上，把进程数量和资源配额管好，用加强过的容器配置先顶着，投入产出比反而更高。

五个场景看下来，结论是一致的：生命周期决定你能不能承受启动固定成本，兼容性清单决定你能不能承受行为差异，两者都不看你选的技术名气有多大。

这五种路线各自的边界层级、适用生命周期与代价

什么时候这些方案都不划算

说了这么多方案，也得说清楚什么时候别上。有些场景硬套沙箱，是把简单问题复杂化。

负载本身可信的时候。 跑的是自己团队编译出来的服务，代码进生产前有过 review，依赖来源可控，这种情况下容器的隔离强度已经匹配风险等级了。上 microVM 只是多了一套内核与镜像要维护，收益接近于零。安全投入要对得上风险，不对等的投入最后都会变成没人愿意维护的负债。

生命周期短到毫秒级、且行为面能收敛的时候。 如果沙箱里要跑的东西本来就被限制在一小撮操作里——比如只做模板渲染、只做表达式求值、只做固定格式的数据转换——那么真正的解法不是加强隔离，而是削减能力。语言级沙箱、白名单 API、甚至直接换一种受限的执行环境，比在内核层面砌墙便宜得多，也更容易审计。能用「不给能力」解决的问题，不要用「隔离开来」解决。

兼容性清单里出现大量不可绕开项的时候。 前面反复强调的验收，如果跑出来的结果是「一堆硬缺口且业务无法改」，那就别硬上了。为了适配沙箱去大规模改造业务代码，这笔账几乎不可能划算，而且改造本身会引入新的风险。这时候要么放宽到容器并接受风险等级，要么把这部分负载单独放到独立的机器上，用物理隔离换取兼容性。

宿主机拿不到 KVM 且短期换不了的时候。 这条针对 microVM 路线。没有 KVM 就是没有，不存在什么配置技巧能绕过去。要么换机型、换服务商，要么转用户态内核，要么退回到加强过的容器配置。不要在不支持的机器上折腾，浪费的是排期。

规模很小的时候。 一台机器上只跑几个实例，且租户边界固定，那物理分区或者干脆按业务线拆机器，比任何沙箱方案都省事。沙箱解决的是「同一台机器上要塞很多互不信任的东西」这个问题，你没有这个问题，就不需要这套方案。

还有一条偏现实的建议：如果团队里没有明确的负责人认领内核与镜像的长期维护，那就不要用需要 guest 内核的方案。技术可以学，流程没人管是真的会烂掉。烂掉之后的状态比不上任何方案都更糟——你以为自己有硬件边界，实际上那个边界后面跑着一个两年没打补丁的内核。

一万网络深耕 IDC 19 年（成立于 2007 年），要在物理机上跑这类沙箱，签约前最好先问清宿主机是否支持嵌套虚拟化、单台能开多少实例。

先回答「要隔离谁」和「实例活多久」，再决定用虚拟机还是用户态内核

回到开头那句「我们用的是容器，所以已经隔离了」。它错不在结论，错在没说清隔离的是哪一层。容器分开的是进程、文件视图和资源账目，内核是同一份；如果你的威胁模型里不包含「有人会在我这台机器上执行他想写什么就写什么的代码」，那这份共享内核是优点，不用动它。一旦包含，那份共享内核就是那道你以为有其实没有的墙。

要补这道墙，你有两条方向完全不同的路。往下不动硬件，把系统调用那张门换成用户态实现，代价是行为覆盖不全，换来的是部署轻、不依赖虚拟化扩展；往上推到硬件，让每个实例自带内核，代价是你要接管内核与镜像的全生命周期，换来的是内核这一整层被彻底隔开。Kata Containers 是这两条路之间的一座桥，它用虚拟机承载容器接口，买的是迁移平滑度。

而真正决定划算与否的，从来不是这两条路谁跑得快，是你的实例活多久、同一时刻开多少个。毫秒级短命实例和小时级长命实例算的是两本不同的账：前者要避开每次启动都要引导内核的方案，后者根本不在意那笔固定成本。在这个基础上，兼容性清单是唯一的否决项——清单里有绕不开的硬缺口，再漂亮的技术方案也得让路。

数据来源与核验说明：microVM 与用户态内核的公开材料口径

本文材料来自 Firecracker、gVisor 与 Kata Containers 的公开项目文档与公开技术材料。文中关于 microVM 的开销、启动时间与创建速率，一律采用公开材料给出的「量级」口径表述（数 MiB 量级内存开销、百毫秒量级启动、单台宿主机每秒上百个实例），不作为任何具体环境下的性能承诺，实际数值需以自有宿主机配置、guest 内核与镜像方案验证为准。文中未引用任何实测、压测、跑分数据，未引用任何具体客户案例；文中出现的业务场景推演均为典型部署思路，并非特指某一真实客户。