为什么沙盒边界是 UGC 平台的第一块基石

先说个真实场景。你的游戏上线，加了插件系统，第一周岁月静好，社区在 Discord 里夸你「终于肯开放了」。第二周，有人写了个永不结束的循环，服务器 CPU 被一个 20 人的房间打满，所有人的操作开始飘。第三周，插件市场里出现了一个叫「存档云同步助手」的东西，实际上把玩家本地的配置和一个登录令牌一起打包发走了。第四周，你不装了，玩家也不装了，评论区全是「你们到底管不管插件」。

这就是 UGC 平台的三周半衰期。做用户生成内容这件事，你以为你在做游戏，其实你在开银行——只不过存进来的不是钱，是别人写的代码，而你得对所有储户负责。银行的第一块基石不是利率，不是网点，是金库的门。

而 WebAssembly 这几年被安利得最狠的一句话，恰恰是「它有沙盒」。这话没错，但它被误解得离谱。准确的说法是：Wasm 给你的是一个物理上没法伪造的笼子——模块的每一条内存访问都要经过边界检查，控制流被约束在结构化的块里，连「跳到某条指令的中间开始执行」这种事在规范层面就不存在。这个笼子是真的。

但笼子不等于社区。笼子管的是「这头野兽跑不出去」，管不了「这头野兽在里面把墙挠穿了」「它在里面嚎了三天让所有人睡不着」「它隔着笼子跟隔壁那头野兽用气味交流」。资源耗尽、侧信道泄漏、合法 API 被滥用——这三件事，Wasm 的可验证性一个字都没保证。

更要命的是，很多团队第一次做 UGC，会把「选一个安全的运行时」当成「做完了安全」。我见过也翻过这种车：静态校验跑通了，上线三天，一个玩家写了段无限递归的插件，单个实例把整个 Worker 拖死，而我们的错误处理逻辑刚好写在同一个 Worker 里——于是错误处理跟着一起死了。那晚我在群里发了一句「沙盒不是一道门，是一栋楼」，被同事截图嘲笑了半年。

这篇就聊这栋楼怎么盖：Wasm 的可验证性到底给了你什么数学保证；wabt 这类静态分析工具能问到什么、问不到什么；运行时电表怎么装；以及那个所有人都不太想聊、但一定会在你扩展多租户时冒出来的东西——Spectre。

第一层：可验证性——Wasm 给你的到底是什么级别的保证

先把这个笼子的构造拆开。Wasm 模块在进入任何引擎之前，必须先过一遍校验器，这一步是规范强制要求的。校验器检查什么？主要是四件事。

类型栈的平衡。Wasm 是栈式字节码，每条指令对栈上数据的类型有明确要求。校验器会模拟整个执行路径，确保任何时候栈上的类型都对得上——你不能把一个浮点数当整数用，也不能凭空多弹出一个值。

控制流的结构化。Wasm 里没有任意跳转指令，只有块、循环、条件这几种结构化的嵌套。跳转目标只能是某个块的边界。这一条是它跟 x86 机器码最本质的区别：在 x86 上，任意一个字节都可能是某条合法指令的开头，攻击者只要找到一段能拼凑出有用指令的字节序列，就能「跳到中间」执行——这就是经典的内存攻击土壤。Wasm 把这条路从规范层面堵死了，不是「难做」，是「没有这个操作」。

内存访问的边界。模块只能看见一块扁平的线性内存（就是一个从地址 0 开始的字节数组），每次读写的偏移和长度都要经过检查，越界即 trap——注意，trap 不是「读到垃圾数据」，而是整个实例立刻停摆。这是一个很硬朗的设计：宁可死，不可脏。

间接调用的类型签名。通过函数表做的间接调用，也要过类型匹配检查，不能拿一个签名去调另一个签名的函数——这直接掐掉了传统的「伪造函数指针劫持控制流」套路。

这四条拼在一起，你得到的是一个可以形式化推理的结论：任何通过了校验的 Wasm 模块，在架构层面上无法访问它没有被授予的内存，也无法执行它没有声明的控制流转移。

看最后一列。注意 Wasm 那一行的逃逸方式里，「访问未授权内存」不见了——这正是它值钱的地方。剩下的四条，全都不在 Wasm 规范的管辖范围内，全是你的工程责任。

这里插一个对照案例，能把这个区别讲得特别清楚：Roblox。Roblox 的沙盒不是 Wasm，是他们自己改的 Lua 方言 Luau。它的安全性来自哪里？来自虚拟机实现不出错。这在工程上是能活的——Roblox 有专门的团队做模糊测试、做安全审计、做漏洞赏金，也确实一路在修补沙盒逃逸。但你看它的性质：这是一个持续对抗的模型，安全性是一个随投入波动的水位，不是一个可以被证明的命题。

写过 Roblox 的人对那行红字都不陌生——脚本执行时间耗尽，被强制掐掉。这行提示背后就是一层电表，它跟可验证性一点关系都没有，它是纯粹的运行时监管。Roblox 的设计意图很清楚：让一个十二岁的孩子十分钟内做出一个能跑的东西，比让他先去理解什么叫能力模型重要得多。收益是数以百万计的创作者和极低的上手门槛；代价是沙盒的强度永远绑在实现团队的仔细程度上。

Wasm 走的是另一条路：把安全性下沉到规范，你不需要信任实现者，你只需要信任校验器。但这条路有个前提——你得自己把能力授给谁想清楚。Wasm 的默认状态是「什么都不会」，一个刚加载的模块，除了自己那点内存和算术，连当前时间都读不到。文件、网络、随机数、日志、渲染，全部要通过导入（import）由宿主显式提供。这就是能力安全模型：不是「禁止你做什么」，而是「你压根没有那个器官」。

说白了：Wasm 给你的是一个空房间加一把你自己配的钥匙串。房间的墙是钢筋混凝土，但你手上这一大串钥匙，才是真正的攻击面。

第二层：静态分析能问到什么，问不到什么

静态分析这一层，工具生态其实很清楚，大致分三档。

最下面是结构校验：wabt 工具集里的校验器，或者运行时自带的校验入口。它回答的问题是「这个二进制文件是不是一个合法的 Wasm 模块」。这一档必做，而且成本几乎为零——很多运行时在加载时本来就强制校验，你只是把结果显式地记录下来。

中间是反汇编与探查：wabt 里的反汇编工具能把模块拆成文本形式，让你看见它的段结构、导入表、导出表、内存段、起始函数、自定义段。这一档是真正干活的地方，你的自动审计流水线大部分逻辑应该长在这里。

最上面是变换与分析框架：Binaryen 这类工具允许你写自定义的分析遍，对整个模块做规则扫描。再往上就是反编译回类 C 伪代码做人工审计，工具是有，但成本高到只适合处理「高危高能力」的那一小撮模块。

关键认知先摆出来：静态分析能做的是清单式审查，不是行为证明。「你能不能静态判断一段循环会不会结束」——不能，这不是工具不够好，这是停机问题。同理，你也无法静态判断「这一串完全合法的接口调用序列，是不是在刷金币」。想明白这一点，你就不会在静态分析上投入不切实际的预算。

那它到底能问出什么？我按实战优先级列一下。

我特别想强调导入表这一项，因为它是 Wasm 相对其他方案最大的结构性优势。在动态语言里做沙盒，你要防的东西一长串：原型链污染、构造函数链绕过、全局对象属性被改写、反射拿到底层引用。在 Wasm 里，能力清单是一张静态可枚举的表，而且默认是空的。这个「默认拒绝」的姿态，省掉的不只是代码量，是一整类你想不到的漏洞。

但清单式审查有个隐藏成本，这个成本不在技术上，在产品上。举个大厂的真事：Facepunch 做的 s&box，走的就是 API 白名单路线——不分析你写的代码，只给你一小撮允许调用的接口。社区一开始怨声载道：「我连读个文件都不行」「我想写个自定义渲染都写不了」。官方的口径基本是：你需要什么，去代码仓库提，我们评估了加进去。

这就是白名单的真实代价——白名单不是技术方案，是产品节奏。你每放开一个接口，就等于给所有潜在恶意插件开了一扇窗；你每收紧一个接口，就有一个 modder 在群里骂你。它是一份需要长期运营的资产，不是一个能一次写完的配置文件。很多团队做 UGC 失败，不是技术不行，是没预料到自己接下来三年要花大量时间在「这个能力给不给」上做取舍。

所以我的建议很直接：把能力分成三档，从最小的那一档开始活。第一档只给「读输入、写输出」两个能力，几乎所有玩法类插件都能活；第二档开放资源访问（只读的资产清单、只读的配置）；第三档才是网络、持久化存储这类高危能力，只给经过人工审核的模块。别一上来就做一整套「什么都能干」的插件 API——那不是慷慨，那是给自己埋雷。

第三层：运行时电表——计量、配额、熔断

静态分析放行了，不代表它能跑完。第二道防线是给每个模块装电表，而且这个电表至少要管四个维度，缺一个都会出事。

指令计量。给每条指令（或者每个基本块）定个价，跑一步扣一点，扣完就 trap。Wasmtime 的 fuel 机制是最典型的实现。这个方案的优点是精准，缺点是贵——插桩会带来大概一到三成的性能损失，具体数字看你的代码形态和插桩粒度。粒度也是一个权衡：逐条指令扣费精度高但开销大，按基本块扣费开销小但一次可能多放行几十条指令。对于游戏插件，我一般建议按基本块，因为你需要的是「不冻帧」，不是「精确到第七条指令」。

时间片与外部中断。不逐条计数，而是每过若干毫秒从外部强行打断一次，检查这个实例是不是超时了。开销几乎为零，粒度非常粗——最坏情况是它已经跑完了一整帧你才发现。适合「允许跑几毫秒」这种场景，游戏主循环里跑插件基本都该配这个。它和指令计量不是二选一，是两道保险：一个管总量，一个管最坏情况下的拖延。

内存配额。Wasm 的线性内存以页为单位扩展，一页 64KB。你必须给每个插件一个硬上限，而且不能信它在内存段里自己申报的数字——那个数字只是它「希望」有多少，运行时才是最后一道闸。给个参考：纯逻辑插件给 16 页到 64 页（1MB 到 4MB）就够绝大多数玩法；需要处理地图数据或者音频的，再单独提额。

输出配额。这是最容易被忘掉、也最常被攻击的一条。插件没有越权，它只是每秒往宿主发十万条消息——你的主线程当场去世。真实攻击者不需要读你的内存，他只需要让你卡。所以每个插件都要有消息预算：每帧最多多少条、每条最多多少字节、每秒最多触发多少次错误。超了就丢弃、计数、按策略降级。

说到降级，有个工程细节必须讲。trap 之后不能只是「记一笔日志」就完事，你要保证一个插件死掉，游戏还活着。这意味着每个插件最好是独立实例、独立内存，trap 只杀那一个。如果插件和你的主循环跑在同一个执行上下文里，那你等于把电表和电器接在同一根保险丝上——电器一短路，电表跟着烧。我前面说的那次翻车就是这么来的。

两个真事，一件在游戏圈，一件在基础设施圈，都能说明「电表做得好，用户是能感觉到诚意的」。

第一个是 Roblox 的脚本超时。所有写过 Roblox 的人都见过那行提示，说脚本执行时间耗尽了、被强制终止。它的价值不在于「限制」本身，而在于它是可见的。开发者知道自己的代码被限速了，就会去优化，而不是在论坛上猜「为什么我的游戏一卡一卡的」。计量器不该是隐形的，这是产品设计的一部分。

第二个是 Cloudflare Workers。它给每个请求一个 CPU 时间上限，免费档是十毫秒量级，付费档才放宽到秒级。你品一下这件事——计量器直接就是计价器。技术限制和商业模式在这里是同一个东西。对你的 UGC 平台来说，这有个很实用的推论：如果你将来要做「普通插件 / 认证插件 / 官方插件」的分层，最自然的分层依据不是审核流程，是资源配额。给认证插件更高的指令预算和内存上限，玩家立刻能感知到差别，而你不需要写一行额外的功能代码。

第四层：Spectre——沙盒挡不住的那一半

到这一层，话题就开始不体面了，因为它涉及到很多人不愿意承认的一件事：Wasm 的数学保证，在微架构层面不成立。

先把原理说人话。现代 CPU 为了快，会在还没确定要不要执行的时候，就偷偷先把指令跑一遍——这叫推测执行。如果猜错了，结果会被撤销，寄存器回滚，一切看起来像没发生过。但有一件事撤不回来：缓存状态。数据被读进缓存这件事，是物理的，撤不掉。攻击者用计时去「感觉」哪块数据在缓存里、哪块不在，就能反推出他本来没有权限读的内容。这就是 Spectre 这一类攻击。

关键在于——Wasm 的沙盒挡的是架构层：你的读指令越界了，它 trap。它挡不住微架构层：攻击者根本不需要越界，他只需要一个能对任意地址做精确计时的探针，然后让 CPU 在推测执行里替他跑一段越权的逻辑。沙盒以为自己在守门，其实攻击者是从窗户缝里看的。

在 Wasm 游戏插件的场景里，有三个东西会把风险放大。

第一是高精度计时。浏览器这些年一直在砍计时的精度，把高精度时钟磨到百微秒甚至毫秒级，防的就是这个。但共享内存配合原子等待指令，可以自己造出一个纳秒级的计时器——这就是为什么共享内存这件事在浏览器里要被跨源隔离策略死死按住，必须在响应头里带上那两个隔离标记才允许用。这条线在第 09 篇讲多线程时已经展开过，这里只说结论：高精度计时是侧信道攻击的燃料，你不能一边给插件燃料一边指望它不点火。

第二是多租户共置。你把两百个玩家的插件跑在同一个进程里省内存，那理论上 A 能摸到 B 留下的痕迹。单机游戏里这不是问题（攻击者和受害者是同一个人、同一台机器），但一旦你的插件跑在服务端，或者客户端插件要处理别人的数据，性质就变了。

第三是插件之间的共享内存。这是大忌。共享线性内存等于把两个笼子中间的墙拆了，你之前所有的隔离工作在这一刻全部归零。省下的那点内存，会以事故的形式连本带利还给你。

那怎么应对？我给一张隔离等级的实账，从最松到最紧。

看 Cloudflare 怎么做的，你会对这件事的严肃程度有个直观感受。他们是最早把 Wasm 用到边缘网络的公司之一，但他们公开写过的态度很清楚：Wasm 是一个很好的隔离原语，但不构成安全边界。所以他们除了用引擎层面的隔离，还叠了进程级的缓解措施，并且削减了计时的精度。一家把 Wasm 用到极致的公司，尚且不敢只靠沙盒——你一个三五人的独立团队，就别幻想「加载即安全」了。

但话也说回来，别被吓到。对绝大多数独立游戏来说，Spectre 不是你的威胁模型。判断标准很简单：插件和它要偷的数据，是不是在同一个信任域里。

单机 UGC，玩家在自己机器上跑别人的插件：攻击者和受害者是同一个人，Spectre 基本没有意义。你真正该怕的是「恶意插件偷玩家本地文件、偷剪贴板、偷登录状态」——解决这个的办法是「不给文件能力」，跟侧信道一点关系都没有。

联网 UGC，插件在服务端跑，或者客户端插件能碰到别人的数据：这才是真风险。而最省事的解法不是去做微架构防护（那是有专门团队的云厂商干的事），是不要在同一个进程里放两个不同租户。说白了，Spectre 的正确应对不是「打得过它」，是「别给它值得偷的邻居」。

把沙盒做成一张可调的配置表

聊完四层，我们把它落成工程师能直接拿去开会的东西：一张参数表和一套分级策略。

先看权限本身。我建议所有能力分成三档授予，不要有「默认全开」这个选项。

然后是运行时参数。下面这张表我给的是「保守档」和「宽松档」两端，中间怎么取值看你的游戏类型——塔防和即时战斗的每帧预算能差十倍。

再往下是流水线。这部分我用自然语言写，因为它本质上是流程设计而不是技术实现：上传先过体积和格式初筛；接着跑结构校验，不通过直接拒；然后解析出导入表和导出签名，比对白名单，生成一份能力指纹；高能力模块转人工抽审；通过后签名入包、分发；运行时挂电表；trap 和异常上报回后台；触发阈值就自动降级。

这里我要单独夸一下「能力指纹」这个设计，因为它把安全成本变成了产品资产。你给每个插件生成一份「它需要什么」的清单，展示在安装页上，就像手机应用的权限列表。玩家点安装的时候看见「此插件需要：读取战斗日志」，他会自己判断。你以为玩家不看——其实在出事之后，他们会翻回来找这个东西，然后发现你早就写了。这一张权限表，在危机公关时的价值超过十篇公告。

还有一个很少被提起但很实用的东西：自定义段的处理策略。Wasm 允许模块里塞任意自定义段，里面可以是调试信息，也可以是几千行违规文本。很多运行时直接忽略它，但你的审核流水线必须把它挖出来过一遍，否则它就是一条绕过内容审核的秘密通道——玩家在游戏里把这段字节读出来展示，你的审核系统一辈子发现不了。这一条我是被搞过才知道的。

初级用户速览 / 中级用户深入

初级路径：三步走，先别想着造一栋楼。

第一步，先问一句最该问的话：你能不能干脆不跑用户代码？把你的插件系统做成数据驱动——只允许玩家提供配置表、参数、简单的条件组合，不允许写任何过程式逻辑。我知道这话听起来不性感，但我保证，八成独立游戏的 UGC 需求，靠这个就能满足，而且一个安全漏洞都不会有。你不需要一个脚本虚拟机，你需要一张能被组合的数值表。

第二步，如果非要跑代码，那就用 Wasm，但只给三个能力：读输入、写输出意图、没有别的宿主调用。内存给 16 页，每帧给不到 1 毫秒的预算，超时就掐。这个配置能撑起绝大多数玩法插件，而且实现成本大概是一到两周。

第三步，加上 trap 隔离。每个插件一个独立实例，trap 就杀那一个，游戏继续跑，界面上给个「此插件已停止运行」的提示。这一步是分水岭——做之前，你的是一个随时会被一个插件带崩的游戏；做之后，你的是一个平台。

顺带一句：初级阶段别做人工审核流程。你还没有量，做了就是空转。等你的插件市场一天有几十个上传了，再来考虑。

中级路径：把「对抗」当成长期成本。

到了这一步，你面对的不再是「玩家不小心写错代码」，而是「有人真的想搞事」。几件必须补的功课。

第一，自己写恶意插件。这是性价比最高的一件事：造一个无限循环的、一个内存炸弹的、一个每帧狂发消息的、一个塞违规文本进自定义段的、一个试图通过桥接层类型转换搞事的。然后逐个丢进你的流水线，看防线在哪漏。我们当年就是这么发现「错误处理跑在同一个 Worker 里」这个问题的。别等社区来教你。

第二，把计量精度和性能开销做成可调的，别写死。同一个运行时，保守档和宽松档的开销可能差三倍，而你的游戏在不同设备上的余量完全不同。移动端的帧预算比桌面紧得多，插件预算必须有单独的档位。

第三，供应链那一层别省。模块签名、内容寻址、版本锁定——这三件事在第 19 篇讲包管理的时候展开过，但对 UGC 平台同样成立：你得能回答「玩家装的这个插件，是不是我审核过的那一份字节」。中间被 CDN 换了、被作者悄悄改了、被第三方镜像打了个包，你都得有办法发现。签名不是为了防黑客，是为了防「你以为是 A 其实是 B」。

第四，灰度与回滚。新版本插件先放给 5% 的玩家，观察 trap 率、平均帧耗、上报异常。这套东西在运营上叫灰度，在安全上叫止损。

第五，也是最多人跳过的一步：把服务端判定当作唯一权威。插件跑在玩家机器上，玩家能改运行时、能改你的校验结果、能直接伪造输入输出。客户端沙盒的作用是「防止误伤」和「给玩家信心」，它的防御对象是玩家的手误，不是玩家的恶意。真正的判别必须在服务端。

五个我见过太多人踩的坑

还有一个不那么技术、但我觉得更值得说的争议：沙盒的严格程度，到底该由谁决定？

一派认为，安全优先，白名单越窄越好，宁可让创作者骂娘，也不能出一次事故。另一派认为，创作自由是 UGC 平台的命，你把 API 掐得只剩几个，好作品根本长不出来。这两派在网上永远吵不出结果，因为问题本身不是技术问题——它取决于你对「平台是什么」的定义。

我自己的倾向是：把严格程度做成一档可演进的产品策略，而不是一个一次性的技术决策。上线初期窄，先活下来；有了稳定的创作者群体，再按「认证作者」逐批放开；每次放开一个新能力，同步配套一套新的配额和一次内部演练。这样你的安全水位是跟着体量走的，而不是一步到位赌一把。

顺带说一句，Steam 创意工坊里出现过恶意动态库这件事，已经不是新闻了。原生动态库插件的安全性是零——一旦加载，它和你的游戏共享同一个地址空间、同一个用户权限。你如果还在用「把玩家编译的库直接加载进进程」这套方案，那你讨论沙盒不沙盒已经没意义了，因为你连门都没有。

FAQ

Q1：我把玩家的脚本从 JavaScript 换成 Wasm，是不是就更安全了？

不一定，甚至可能更糟。换语言不等于换边界。如果你的 Wasm 插件照样能通过桥接层拿到一整套宿主对象、照样能读文件、照样没有配额，那你只是把同样的攻击面换了一个实现语言，还额外增加了一层桥接层的类型转换风险。安全性的来源是「能力给多少」和「电表怎么装」，而不是「用什么字节码」。

Q2：结构校验通过了，是不是就代表这个模块没问题？

校验通过只代表「这是一个合法的 Wasm 模块」，它保证的是格式和不越界。它不会告诉你这个模块要导入文件写入能力，不会告诉你它的起始函数在加载瞬间就会跑，不会告诉你它循环的复杂度爆表。校验是必要条件，不是充分条件。真正的安全结论要靠「导入表比对 + 配额 + 隔离等级」三件套一起给。

Q3：独立团队做 UGC 平台，安全这块要投多少人月？

看你要做哪一档。只做数据驱动、不跑用户代码，投入接近零。跑 Wasm 但只给三个能力、加独立的实例隔离和超时熔断，大概一个人一到两个月的工时，之后是长期的低强度维护。要做到「三档授权 + 人工审核 + 灰度发布 + 签名分发」这一步，通常需要一个专职的人和一套自动化流水线，这是长期摊在运营成本里的。我的建议是：按你现在真实的创作者数量投，不要按你的野心投。

Q4：Spectre 我到底要不要管？

一句话判断：插件要偷的数据，和插件本身，是不是在同一个信任域里。单机 UGC，玩家在自己机器上跑别人的插件，攻击者和受害者是同一个用户，基本可以不管——你更该防的是「不给文件能力」。服务端多租户，或者插件能触碰到别人的数据，那就要管，但最有效的解法不是做微架构防护，是提高隔离等级：别把两个不同租户放进同一个进程。这是成本问题，不是技术难题。

Q5：插件需要访问游戏里的对象（比如一个单位的属性），该怎么给？

两条路，我强烈建议走第一条：序列化成消息传，别共享内存。每条消息有配额、有大小上限、有格式检查，你对这个通道的每一字节都有掌控。代价是序列化和反序列化的开销，以及延迟——但对于绝大多数玩法插件，这点开销完全在预算内。共享内存那条路快是快，但它把你所有的隔离、所有的量计、所有的审计一次性废掉了。速度换安全这件事，在插件系统里从来都不划算。

顺便说句题外的判断：如果你发现自己的插件 API 已经开始需要「共享内存才能不卡」了，那通常不是隔离方案的问题，是你的插件在干它不该干的活。把重计算搬回宿主侧，让插件只做决策不做运算，性能问题和安全问题会一起消失。