为什么 4GB 是立项会上就该拍板的事

先讲个我自己的翻车现场。

两年前我帮朋友移植一个模拟经营的小 demo 到浏览器，Emscripten 一把过，桌面 Chrome 跑得欢。地图从 256×256 调到 512×512，桌面还是没事，我心想稳了。结果把链接丢到群里，三个人里两个打开是白屏，一个 iPhone 用户直接 Safari 崩溃。我第一反应是着色器编译炸了，查了半天 WebGL，最后在控制台角落里看到一行 out of memory。那一刻我才反应过来：我不是在跟渲染管线打架，我是在跟地址空间打架。

这事儿听起来很技术，其实特别策划。因为你立项时拍板的“世界规模”“同屏单位数”“贴图精度”“配乐时长”，最后都会变成同一个池子里的字节数。这个池子就是 WebAssembly 的线性内存，而它有一个很多人不愿意直视的天花板：4GB。注意，这个 4GB 不是硬盘，也不是你电脑的内存条，它是你的游戏在浏览器里能看见的“全部世界的总地址”。贴图、网格、音频、物理缓存、寻路网格、实体状态、编译器塞进来的栈和元数据，全挤在这一个池子里。

你买手机 256GB 起步，4GB 听起来像上古文物。可你把它拆开算算：一张没压缩的 4096×4096 RGBA 贴图就是 64MB，六十多张就把 4GB 吃干净了，而你连一个像素都还没画到屏幕上。所以我说它更像一间四平米的仓库，你还得在里面摆一张乒乓球桌。

这个专题里，上一篇 SIMD 聊的是“算得快”，这一篇聊的是“装得下”。两件事经常被混为一谈，但它们是两条独立的命脉。算力不够，你掉帧；装不下，你连掉帧的机会都没有，直接白屏。下一篇运行时横评会讲 Wasmtime、Wasmer、WasmEdge 各自对 Memory64 的支持差异，这里先把“为什么要 64 位”和“什么时候轮到你操心”讲透。

第 1 层：4GB 不是内存条容量，是整个世界的地址空间

先把话说白。WebAssembly 模块眼里的内存，是一整块连续的、从 0 开始按字节编号的大数组，业内叫线性内存。你可以把它想成一张无限长的 Excel 表，每一行存一个字节，模块里所有变量、数组、对象都住在这张表上。它没有 malloc 出来的碎片化区块，也没有操作系统层面的页表概念，就是一根从头到尾的直线。

这根直线以“页”为单位增长，一页 64KiB。32 位地址最多能数到 65536 页，65536 乘以 64KiB，正好 4GiB。这就是 4GB 墙的由来。它不是谁拍脑袋定的营销数字，是地址宽度除以页大小算出来的硬账。

更扎心的是，4GB 是理论值。你在真实浏览器里拿到的，往往比这更少。

这张表最该被记住的是最后两行。默认 16MB 起步，意味着你稍微加载两张贴图，内存就开始“长”。而增长这件事，在老一点的实现里不是原地变长，是重新申请一块更大的、把旧数据整个复制过去、再释放旧的。你在大地图上跑着跑着卡半秒，未必是 GC，可能是堆在搬家。搬家瞬间，旧块和新块同时存在，峰值内存直接翻倍——这就是为什么很多项目“明明才用了 1.5GB，却在 1.5GB 崩了”。

所以别问“4GB 够不够”，要问“我的峰值会不会在某一帧里翻倍”。这一个问题的答案，比任何优化技巧都值钱。

第 2 层：四种撞墙姿势——玩家看到的不是报错，是白屏

内存墙不是撞上去才知道的，是你在设计玩法时就已经决定了天花板。我把常见的撞墙方式归成四类，每一类都对应玩家能感知到的具体体验。

第一类，大世界与模拟经营。这类游戏的爽点是“规模感”：地图越大、城市越密、单位越多，玩家越觉得自己在经营一个活的世界。可规模感是拿内存换的。一张 2048×2048 的地图，如果每格存 32 字节的状态（地形、归属、建筑、事件标记），光地图数组就是 128MB。你再加多层地形、道路网络、每个居民的日程和寻路缓存，翻三四倍很正常。玩家不会夸你“格子存得真省”，他只会问“为什么 1024 的地图开不了”。

第二类，高清资产。一张 4096×4096 的 RGBA 贴图，在显存里是压缩的，但在 Wasm 线性内存里做解码、拼图集时往往是未压缩的，64MB 一张。十张就是 640MB。你以为你在做美术，其实你在做资产搬运工。

第三类，音频。这个最容易被策划忽略。未压缩的 44.1kHz 立体声 16 位 PCM，一分钟大概 10MB。你想做个有氛围的模拟经营，一小时配乐加环境音，就是 600MB 起。就算你全用流式加载，混音缓冲区、音效实例、解码中间态也在吃内存。

第四类，运行时的隐形税。物理引擎的宽相碰撞缓存、对象池、脚本虚拟机、GC 没来得及回收的垃圾、JS 和 Wasm 之间传数据时的副本。每一笔都不大，加起来能吃掉你三四成的预算。你以为是引擎在帮你，其实是引擎在收租。

说两个真实案例，都是 Web 游戏圈里能查到的。

案例一：OpenTTD 的浏览器版。这个开源运输模拟游戏通过 Emscripten 移植到了 WebAssembly，真的能在浏览器里跑，而且体验相当完整。问题出在地图规模上。OpenTTD 的经典大地图是 2048×2048，甚至能开到 4096×4096，每一格都有地形高度、类型、归属、信号、车辆状态等一堆数据。桌面原生版随便开，浏览器版在大地图加多 AI 对手时就开始喘。设计团队的取舍很典型：他们没有砍玩法，而是把“默认地图尺寸”和“AI 数量”当作可调旋钮交给玩家，同时接受浏览器端的上限比原生低。收益是零安装、点开就玩；代价是那种“开到最大地图慢慢经营”的老玩家体验被打了折。这不是技术团队的失败，是地址空间的账单。

案例二：Unity WebGL 独立游戏。Unity 官方文档一直建议 WebGL 内存别超过 2GB 左右，因为浏览器和引擎自身还有开销。我见过太多独立团队在 itch.io 发布 WebGL 版，桌面测试一切正常，移动端玩家打开就白屏。论坛里最常见的反馈是“为什么手机上加载到 90% 就没了”，答案往往就是堆增长到某个点，被 iOS 的 WebContent 进程限制直接干掉。Unity 的堆增长策略和浏览器上限之间的关系，是这个坑的核心：引擎想多要点，系统说不行，中间没有优雅降级的余地。

再补一个跨类的老案例，很多人有共鸣。PC 时代的 32 位内存墙。《上古卷轴5》《辐射4》这些游戏当年都有社区做的 4GB 补丁，原理是让 32 位程序能用上超过 2GB 的地址空间。玩家装补丁不是因为游戏变快了，是因为不装就装不下更多 mod。这跟今天的 Wasm 一模一样：不是性能问题，是容量问题。历史不会重复，但会押韵。

第 3 层：Memory64 动了哪根筋，以及它要收的税

Memory64 提案干的事，说穿了就一句话：把线性内存的地址从 32 位加宽到 64 位。指针从 4 字节变 8 字节，能寻址的空间从 4GiB 变成理论上 16EB。你不用记 EB 这个单位，只要知道它大到你这辈子做游戏都用不完。

但工程上没有免费午餐。地址变宽，第一个直接后果是“指针变胖”。同样一个数据结构，里面每存一个指针就多占 4 字节。链表、树、图、对象引用多的地方，整体内存占用会涨，经验值大概在 20% 到 40% 之间，取决于你的数据布局。第二个后果是缓存局部性变差：指针胖了，同样大小的缓存行装的指针少了，遍历时的缓存命中率会掉。第三个后果是代码体积也会涨，因为地址常量、重定位信息都变宽了。

所以有句话我得说在前面：Memory64 是容量扩展，不是性能优化。它让你装得下，但它很可能让你的程序慢一点点。你拿它当银弹，它反手给你一记税单。

我特别想强调“提交方式”这一行，因为它才是 Memory64 对游戏设计真正的礼物。32 位内存有个物理约束：它必须是一块连续地址。你想从 1GB 长到 2GB，得先找到一块连续的两GB 空地，把数据搬过去。这对“边玩边加载”的开放世界是致命的，你没法在玩家跑图时优雅地扩堆。64 位地址空间大到几乎不可能耗尽，运行时可以一上来就预留一大片虚拟地址，物理内存按页慢慢给。这件事的意义，比“上限变大”重要得多，下一层细讲。

至于工具链现状，我给你一个不带滤镜的判断：服务器端和桌面运行时已经能用了，Wasmtime 这些对 Memory64 的支持相对成熟；Emscripten 有实验性的 64 位内存开关，但默认不开，很多第三方库在 64 位指针下没验证过；浏览器端还在逐步放开，Chrome 系走得靠前，移动端别指望。你要是做的是 Web 端独立游戏，2025 年这个时间点，把它当“未来选项”而不是“本周任务”。

第 4 层：和操作系统虚拟内存握手——预留一大块，按需给页

这一层是整篇文章里最不“策划”、但最影响玩法边界的一层。我用大白话讲。

操作系统的虚拟内存有个本事：它可以先给你“画个饼”。你申请 8GB 地址空间，系统说行，给你留着，但一分钱物理内存都不给；等你真的往某一页写数据，它才分配那一页。这个机制叫按需提交。现代运行时给 Wasm 分配线性内存时，玩的就是这套。

传统 32 位 Wasm 内存为什么难用？因为它要的是“连续”。系统就算有足够的物理内存，也不一定有一块连续的虚拟地址给你，尤其浏览器进程里还跑着一堆别的模块。增长时的搬迁、峰值翻倍、加载卡顿，全是从这儿来的。

Memory64 把地址空间拉到几乎无限，运行时的操作空间就大了：开局预留一大片虚拟区间，物理页在游戏运行中一页一页地提交。对玩家来说，这意味着什么？

• 无缝加载的地图。玩家骑马跑过一个山头，新的区块数据直接落到预留区里已经提交好的位置，不用整块搬迁，不卡那么一下。
• 更大的资产池。贴图、音频可以按需解码进内存，用完释放回池子，池子本身不用缩。
• 更可预测的峰值。你不再需要为了“增长时翻倍”而预留一大块安全余量，预算能做得很紧。

但浏览器厂商不是吃素的。地址空间虽然大，浏览器进程里还有别的模块、还有安全隔离、还有地址随机化，加上历史包袱，主流浏览器对“一上来就预留几个 GB”这件事非常谨慎。Wasmtime 这类独立运行时可以让你配置预留多少、提交策略是什么，浏览器里你就得看引擎心情。这就是为什么同一个游戏，桌面运行时跑得好好的，扔进浏览器就缩水。

这里还有个常被忽略的设计点：内存不连续之后，游戏逻辑得跟着变。以前很多引擎假设“所有资源在同一个大数组里，用偏移量互相引用”，64 位下偏移量变大，序列化格式、存档、网络协议都得跟着改。这不是换个编译开关就完事，是一次数据结构层面的体检。我见过团队兴冲冲开了 64 位，结果存档格式全废，回滚花了两周。别问我怎么知道的。

把内存预算做成一张表：立项时就该填的数字

下面这张表是我自己项目里用的内存预算模板，按游戏类型给了建议区间。数字不是圣旨，但能帮你在立项会上把“我们地图做多大”翻译成“我们内存留多少”。

再给一张“要不要上 Memory64”的决策参数表，每一项都可以在立项时打分。

这两张表放在一起看，结论其实很清楚：大多数独立游戏根本不需要 Memory64，需要的是把资产管理和流式加载做好。但如果你做的恰好是“规模就是卖点”的那一类，那这 4GB 就不是优化问题，是你能不能做出这个游戏的问题。

初级用户速览 vs 进阶深入

初级用户速览：三分钟判断你要不要关心这件事

先回答三个问题，答案会告诉你该不该继续读下去。

• 你的游戏在桌面 Chrome 上峰值内存超过 1.5GB 了吗？没有，关掉这篇文章，去做内容。
• 你的目标玩家有相当比例在手机上玩吗？有，那 Memory64 短期内帮不了你，优先降资产、做流式。
• 你的核心卖点是“世界很大、东西很多”吗？不是，那 4GB 墙大概率不会成为你的瓶颈。

三个都指向“是”，再往下看。否则，你更需要关心的是贴图压缩、音频流式、对象池，以及下一篇要讲的运行时选型。

进阶深入：真要上的话，迁移路径和验证清单

如果你确定要碰 Memory64，别一上来就改主分支。我推荐的顺序是这样的：

1. 先把峰值压到极限。用流式加载、纹理压缩、音频按需解码，把 2.5GB 压到 1.8GB。很多团队在这一步就发现不需要 64 位了。
2. 在服务器或桌面运行时上先验证。Wasmtime 这类运行时对 Memory64 的支持更成熟，拿它跑你的核心逻辑，测指针膨胀带来的内存涨幅和性能变化。
3. 检查数据布局。凡是用 32 位偏移量做序列化、存档、网络协议的地方，全部过一遍。这是最容易被低估的工作量。
4. 测三件事：同样场景下内存涨了多少、帧时间变了多少、加载时间变了多少。三个数字都记下来，别只记内存。
5. 浏览器端做灰度。先只对桌面 Chrome 开放，移动端回退 32 位版本。两套构建的维护成本要提前算进排期。

我再泼一盆冷水：如果你的团队没有能啃编译器和运行时的同学，Memory64 的坑你填不动。它不是点个开关，是一条从工具链到数据结构的完整链路。

争议与踩坑：Memory64 不是银弹，别把它当性能优化

还有个争议值得摆到台面上：“大多数游戏爆内存，根本不是地址空间不够，是资产管理烂。”这话难听，但我在太多项目里见过——贴图不压缩、音频全解码、对象从不复用、区块加载了不卸载。你给这种项目 64 位，它只是把崩溃时间从第 3 分钟推迟到第 8 分钟。先把该做的功课做完，再谈突破物理上限。

FAQ

Q1：我的 Unity WebGL 游戏能直接开 Memory64 吗？

短期别指望。Unity 的 WebGL 后端对 64 位内存的支持还在路上，而且就算引擎支持，浏览器端的覆盖也会卡你。你能做的是先把内存压下来，盯紧 Unity 版本更新里关于 WebGL 内存的说明。

Q2：4GB 到底能不能用满？浏览器实际给多少？

桌面浏览器能摸到 3GB 出头，移动端经常 1GB 到 1.5GB 就被系统干掉，机型差异极大。所以别按 4GB 做预算，按目标平台最差的那台设备做预算。

Q3：Memory64 会让我的游戏变慢吗？

可能会，幅度取决于你的数据布局。指针密集型代码受影响大，数值计算密集型受影响小。上线前一定要做同场景对比测试，别拍脑袋。

Q4：我做的是 2D 独立游戏，需要关心这个吗？

基本不需要。你的瓶颈更可能是图集没拼好、音频没流式、对象池没做。把这几件事做好，2D 游戏在 4GB 里活得很滋润。

Q5：能不能用多个 Wasm 内存模块绕过 4GB？

技术上可行，工程上很痛。跨内存的数据结构、序列化、引擎支持都是坑。除非你有很强的底层团队，否则不如老老实实做流式加载。

你的地图野心，卡在哪一层

写到这里，我想把问题反过来问你：如果你的游戏明天突然多了 4GB 可用内存，你的玩法会变成什么样？

如果答案是“地图能大四倍”“城市能多住十万人”“同屏能多两百个单位”，那 Memory64 对你就是真需求，值得你提前布局。如果答案是“好像也没什么变化，就是不用天天删资源了”，那你要的可能不是 64 位，是一套更好的资产管线。

4GB 墙真正残酷的地方，不在于它挡住了多少字节，而在于它逼你在立项时就回答一个问题：你的游戏，到底是靠“更大”打动人，还是靠“更巧”打动人。这两个答案没有高下，但它们通向完全不同的技术路线。想清楚这个，比追任何一个提案的进度都重要。