浏览器里跑《我的世界》这件事，最早让我觉得"不可能"的地方不是渲染，而是内存。一个典型的方块世界，哪怕只加载 16×16 个区块，每个区块 16×16×256 个体素，光方块 ID 就是千万级的数组，再加上光照、实体、区块元数据，随便就是几百 MB 的堆内存。传统 JavaScript 的 GC 在这种高频分配、大对象驻留的场景下会抖得厉害，帧率像心电图一样上下跳。所以当我第一次看到有人在浏览器标签页里流畅地挖方块、放方块、还能跑红石逻辑时，我第一反应是去翻它的内存模型——答案基本都指向同一个方向：把核心的区块数据结构和网格生成逻辑搬到 WebAssembly 里，用线性内存自己管，JS 只负责调度和渲染胶水。这篇就围绕这套思路，把 MC.JS 这类"浏览器版方块世界"的工程实践拆开讲，包括 WebGL 渲染管线怎么组织、WebAssembly 承担了哪些脏活、两者之间的数据怎么零拷贝地流动，以及我在复现过程中踩过的那些坑。适合有一定前端基础、想理解"重计算 + 实时渲染"这类 Web 应用架构的读者，也适合正在做体素引擎、可视化仿真、在线 3D 编辑器的人参考。
1. 为什么方块世界必须把计算下沉到 WebAssembly
1.1 体素世界的真实计算量，比看上去大得多
很多人对《我的世界》类游戏的直觉是"不就是一堆立方体吗"，但真正动手写过一个体素渲染器的人都知道，立方体本身不是问题，问题是"哪些立方体需要被画出来"以及"它们长什么样"。一个 16×16×256 的区块，理论上有 65536 个方块位置，但玩家视野内通常同时存在几十个区块。如果每个方块都老老实实生成 6 个面、12 个三角形，一个区块就是几十万个三角形，几十个区块直接上千万，浏览器根本扛不住。
所以真正的工程做法是面剔除（face culling）：只有当一个方块的某个面朝向空气（或透明方块）时，这个面才需要被生成。这一步听起来简单，但它是纯计算密集型的——你要遍历每个方块的六个邻居，判断可见性，再把可见面的顶点坐标、法线、纹理 UV、环境光遮蔽（AO）值全部算出来，写进顶点缓冲。这个过程的复杂度是 O(方块数 × 6)，而且每当你挖掉一个方块，周围一圈方块的面可见性都可能变化，需要局部重建网格。
我用纯 JavaScript 写过一版，在一个中等配置的笔记本上，单个区块的完整网格生成大约要 8 到 15 毫秒，玩家快速移动触发多区块加载时，主线程直接卡成幻灯片。这就是问题的核心：网格生成是 CPU 密集的、可并行的、数据结构规整的，这三点恰好是 WebAssembly 最擅长的场景。
1.2 JavaScript 的 GC 抖动为什么在体素场景里格外致命
JavaScript 不是不能算，而是它的内存分配模式不适合这种场景。你在网格生成时如果频繁new Float32Array(...)、创建临时对象、拼接数组，V8 的年轻代 GC 会被高频触发。体素网格生成的特点是"短生命周期的大块临时数据"——每个区块生成时都要临时存顶点、索引，生成完拷贝进大缓冲后丢弃。这种模式会让 GC 压力陡增，表现为周期性的掉帧。
WebAssembly 的线性内存是手动管理的：你一次性memory.grow出一大块，之后所有区块的顶点数据都往固定偏移写，用完标记为可复用，全程没有 GC 参与。我在实测里对比过，同样的网格生成逻辑，WASM 版本在持续挖方块 30 秒后的帧时间标准差只有 JS 版本的三分之一左右。这个差距不是算法差距，纯粹是内存管理模型带来的稳定性差距。
1.3 什么该放进 WASM，什么必须留在 JS
这里有个常见的误区：以为"性能敏感就全塞进 WASM"。实际上渲染调用、DOM 交互、输入处理这些必须留在 JS，因为 WebGL 的 API 调用本身就在 JS 侧，跨边界调用反而更慢。我的划分原则是这样的：
| 模块 | 归属 | 理由 |
|---|---|---|
| 区块体素数据存储 | WASM 线性内存 | 大块、长期驻留、需频繁随机访问 |
| 面剔除与网格生成 | WASM | 纯计算、循环密集、无对象分配 |
| 光照传播（AO/天光） | WASM | 迭代式算法，适合紧凑循环 |
| 物理碰撞检测 | WASM | 每帧高频调用，数据局部性好 |
| WebGL 绘制调用 | JS | API 在 JS 侧，跨边界无收益 |
| 输入与 UI | JS | 事件模型天然在 JS |
| 区块调度与加载队列 | JS | 涉及异步 IO 和 Promise |
这个划分不是拍脑袋的，核心判断标准是：这段逻辑是否以"大数组 + 紧凑循环"为主，且每帧或每次操作调用次数足够多。满足就下沉，不满足就留在 JS。物理碰撞是个典型例子——它每帧对玩家 AABB 和周围方块做检测，调用频率极高，数据又全在 WASM 内存里，放进去几乎零成本；而区块加载涉及网络请求和异步调度，硬塞进 WASM 只会让代码更难维护。
2. WebGL 渲染管线的组织方式：从区块到 draw call
2.1 每个区块一个 VAO，还是全局一个大缓冲
这是体素渲染绕不开的第一个架构决策。最直觉的做法是每个区块维护自己的顶点缓冲和 VAO，绘制时逐区块drawElements。好处是局部更新简单——挖一个方块只重建那一个区块的缓冲；坏处是 draw call 数量随视距线性增长，视距 8 个区块时就是 289 个 draw call，虽然现代浏览器能扛，但每帧几百次状态切换还是有开销。
另一种做法是把所有区块的顶点塞进一个巨大的共享缓冲，用偏移量区分，理论上可以合并成少数几个 draw call。但这带来两个麻烦：一是区块动态加载/卸载时缓冲管理复杂，二是局部更新要处理碎片整理。我最终采用的是折中方案：以"区块列"（同一 x/z 下所有 y 层）为单位组织缓冲，配合视锥剔除，实际每帧 draw call 控制在几十个量级。这个粒度既保证了局部更新的简单性，又把 draw call 压到了可接受范围。
具体实现上，每个区块列持有一个WebGLBuffer存顶点数据、一个存索引数据，VAO 记录属性指针布局。顶点格式我定成紧凑的 16 字节：
偏移 0 : position (3 × float32) 12 字节 偏移 12 : uv (2 × uint16 归一化) 4 字节 偏移 16 : light (1 × uint8 归一化) 1 字节 // AO + 天光打包 偏移 17 : normal (1 × uint8 编码) 1 字节这里有个细节值得说：UV 用uint16归一化而不是float32，是因为方块纹理坐标永远落在 0 到 1 之间，16 位精度足够，还能省 4 字节；法线只有 6 个可能方向，用 1 字节编码成 0 到 5 完全够用。这些压缩在单个顶点上看着不起眼，但乘以百万级顶点后，显存带宽的节省非常可观。我实测过，顶点从 32 字节压到 16 字节后，同一场景的显存占用直接减半，移动端尤其明显。
2.2 视锥剔除与遮挡剔除的取舍
视锥剔除是必做的，用相机的投影矩阵构造 6 个平面，对每个区块的 AABB 做测试，不在视锥内的直接跳过。这一步在 JS 侧做就行，因为区块数量不多（几百个），每帧测试成本很低。
遮挡剔除就复杂了。理想情况下，被山体挡住的区块不该绘制，但精确的遮挡查询在 WebGL 里代价很高。我试过基于区块可见性传播的近似方案——从相机所在区块出发，沿视线方向做洪泛，被不透明区块挡住的方向不再深入。这个方案在洞穴场景里效果很好，但在开阔地形里收益有限，还引入了额外的 CPU 开销。最后的结论是：视距内做视锥剔除，遮挡剔除只在视距边缘做粗粒度处理，把省下来的算力留给网格生成。这是个典型的工程取舍，不是所有优化都值得做。
2.3 纹理图集与 mipmap 的坑
方块纹理必须打成图集（texture atlas），否则每个方块类型一个纹理，状态切换会拖垮性能。图集的做法是把所有方块纹理排进一张大图，UV 坐标映射到对应格子。但这里有个经典陷阱：相邻格子的纹理在 mipmap 或线性过滤时会互相渗色，表现为方块边缘出现奇怪的彩色条纹。
解决办法有两个：一是给每个格子留 padding，采样时只取格子内部区域；二是在着色器里手动做纹理坐标的 clamp。我采用的是 padding 方案，每个 16×16 的纹理格子周围留 2 像素边距，图集尺寸按 2 的幂对齐。代价是图集变大、显存略增，但彻底消除了渗色问题。另外 mipmap 的生成要注意：如果图集是运行时用 canvas 拼的，generateMipmap会把 padding 也平均进去，所以 padding 区域要填成和边缘像素一致的颜色，而不是透明或黑色。
3. WASM 与 JS 之间的数据流：零拷贝不是口号
3.1 共享内存的布局设计
WASM 和 JS 共享同一块ArrayBuffer，这是零拷贝的基础。关键在于布局要提前规划好，避免运行时反复计算偏移。我的做法是在 WASM 初始化时一次性分配好几块区域：
[0, 64MB) : 区块体素数据区（每区块固定 slot） [64MB, 128MB) : 网格顶点暂存区（双缓冲） [128MB, 160MB) : 索引暂存区 [160MB, ...) : 物理、光照等临时工作区区块体素数据用固定 slot 分配，每个区块 slot 大小一致（比如 16×16×256 字节 = 64KB），这样区块 ID 到内存偏移的换算就是简单的乘法，不需要查表。代价是有内部碎片——高度不满的区块也占满 64KB——但换来的寻址效率提升完全值得。顶点暂存区用双缓冲，是因为网格生成和 GPU 上传可能重叠：这一帧生成区块 A 的网格写进缓冲 0，同时上一帧缓冲 1 的数据正在被bufferSubData上传，互不干扰。
3.2 从 WASM 内存到 GPU 缓冲的最短路径
网格生成完成后，顶点数据已经在 WASM 线性内存里了。最直接的路径是：JS 侧拿到WebAssembly.Memory的buffer，创建一个Uint8Array视图，然后调用gl.bufferSubData(target, offset, view.subarray(start, end))。这里的关键是subarray不拷贝，它只是原 buffer 上的一个视图，bufferSubData会直接从这块内存读数据传给 GPU。
但有个坑：如果 WASM 内存增长（memory.grow），原来的ArrayBuffer会 detach，所有基于它的视图全部失效。所以我的做法是初始化时就把内存一次性 grow 到上限，运行期不再增长。这要求提前估算峰值内存，宁可多留余量。我一般按"最大同时加载区块数 × 每区块 slot 大小 × 1.5"来估，1.5 是给临时工作区留的系数。
另一个细节是bufferSubData的调用频率。每帧上传几十个区块的顶点，如果每个区块单独调一次，就是几十次 API 调用。更好的做法是把同一帧要更新的区块顶点在暂存区里连续排列，然后合并成一次大的bufferSubData。这需要在 WASM 侧做一点调度——把本帧生成的网格按目标缓冲的偏移顺序写入暂存区。这个优化我实测能减少约 40% 的上传耗时。
3.3 函数调用边界的成本控制
WASM 和 JS 之间的函数调用有固定开销，虽然不大，但高频调用会累积。典型的高频场景是"每帧对每个实体调用一次物理更新"。如果实体有几百个，每帧几百次跨边界调用，开销就不可忽略了。
我的处理办法是批量化：JS 侧把本帧所有实体的状态写进共享内存的一个数组，然后调用一次wasm.updatePhysics(entityCount)，WASM 内部循环处理所有实体，处理完再一次性读回结果。这样每帧的跨边界调用从几百次降到个位数。同理，网格生成也是批量提交——JS 把"本帧需要重建的区块 ID 列表"写进共享内存，调用一次wasm.rebuildChunks(count)，WASM 内部循环处理。
提示：批量化的前提是数据能连续存放。如果你的实体状态是分散的对象，先做一次"打包"到连续数组，再传进去。打包本身的成本远低于几百次跨边界调用。
4. 网格生成算法的工程细节
4.1 贪心合并：什么时候值得做
面剔除之后，相邻的同类型方块如果朝向同一方向，它们的面其实可以合并成一个更大的矩形。这就是贪心网格合并（greedy meshing），能把顶点数再降一个数量级。听起来很美好，但实际用起来有代价：合并后的面 UV 需要拉伸，纹理如果是有方向性的（比如草方块顶面），拉伸会破坏图案；而且合并算法本身比简单面剔除复杂得多，代码量和调试成本都上去了。
我的经验是：地形类方块（石头、泥土）适合贪心合并，装饰性方块（带图案的）不适合。实际项目里我采用的是混合策略——对纯色或可平铺纹理的方块启用合并，对有明确图案的方块保持逐面生成。这样既拿到了大部分顶点削减收益，又避免了纹理拉伸的视觉问题。如果你的项目对顶点数不是极度敏感，简单面剔除 + 紧凑顶点格式往往就够了，别为了优化而优化。
4.2 环境光遮蔽的计算与打包
AO 是让方块世界看起来有立体感的关键。标准做法是对每个顶点采样它周围三个相邻方块（两个边 + 一个角），根据被遮挡的数量算出一个 0 到 3 的等级，映射到亮度。这个计算在面剔除阶段顺手就做了，因为那时你已经在遍历邻居。
坑在于顶点共享。相邻两个面共享顶点时，如果各自算出的 AO 值不同，共享顶点只能取一个值，会导致 AO 出现不连续的接缝。解决办法是不共享顶点——每个面的四个顶点独立生成，虽然顶点数增加，但 AO 过渡自然。这也是为什么体素引擎的顶点数往往比理论值高：为了正确的 AO，牺牲了顶点复用。我把 AO 值和天光值打包进一个字节（高 2 位 AO，低 6 位天光），在着色器里解包，省了一个顶点属性。
4.3 增量更新：挖一个方块到底要重建多少
玩家挖掉一个方块，理论上只需要重建它所在区块的网格。但边界情况要注意：如果挖的是区块边缘的方块，相邻区块对应位置的面可见性也会变化，需要一起重建。我的实现里维护了一个"脏区块集合"，挖方块时把当前区块和所有相邻（如果方块在边界）区块标记为脏，下一帧统一重建。
这里有个性能陷阱：玩家连续快速挖掘时，同一区块可能在一帧内被标记多次。所以脏集合要用 Set 去重，且重建要放在帧末统一做，而不是每次挖掘立即触发。我早期版本就是立即重建，结果快速连点时帧率暴跌，改成帧末批量后流畅度立刻恢复。
5. 那些文档里不会写的踩坑记录
5.1 WASM 内存增长导致的视图失效
这个坑我在 3.2 提过，但值得单独强调，因为它太隐蔽了。现象是：运行一段时间后，渲染突然花屏或直接黑屏，控制台没有任何报错。原因是某次memory.grow后，JS 侧缓存的Float32Array视图指向了已 detach 的旧 buffer，读出来全是 0 或垃圾数据。
排查过程很折磨人，因为错误不发生在 grow 的那一刻，而是发生在下一次使用旧视图的时候。我的定位方法是：在所有创建视图的地方加一个断言，检查view.buffer.byteLength !== 0，一旦 detach 就立即抛错，这样能快速定位到是哪次 grow 导致的。修复方案就是前面说的——预分配足够内存，运行期不增长。如果实在需要增长，那就在 grow 之后重建所有视图，并把这个逻辑封装成一个函数，杜绝散落各处的视图缓存。
5.2 纹理图集的 mipmap 渗色
前面提过 padding 方案，但还有个更隐蔽的问题：图集尺寸不是 2 的幂时，某些 GPU 驱动会拒绝生成 mipmap 或行为异常。我一开始图集是 15×15 个 16px 格子，算出来 240×240，不是 2 的幂，在某些设备上 mipmap 直接失效，远处方块糊成一片。改成 16×16 格子（256×256）后问题消失。所以图集布局一定要按 2 的幂规划，格子数取 2 的幂，单格尺寸也取 2 的幂。
5.3 浮点精度与远距离抖动
视距拉大后，远处方块的顶点坐标数值变大，float32精度不够，会出现顶点抖动（z-fighting 的变种）。根本原因是模型坐标和视图坐标在同一个大数值域里计算。解决办法是相对坐标渲染：以相机所在区块为原点，所有顶点坐标减去这个原点再传给 GPU，这样数值始终在小范围内，精度充足。这个改动涉及顶点数据的生成逻辑，要在 WASM 侧就减去原点偏移，而不是在着色器里减（着色器里减已经晚了，精度已经丢了）。
5.4 移动端的显存与功耗限制
桌面端跑得好好的，一到移动端就发热降频。除了顶点压缩，还要注意：移动端 GPU 对bufferSubData的频率很敏感，每帧大量小上传会导致带宽瓶颈。我的优化是把上传合并（前面说的），并且对远处区块降低更新频率——远处区块的网格变化玩家几乎察觉不到，没必要每帧都传。另外纹理图集在移动端要控制尺寸，超过 2048×2048 在部分设备上会出问题，必要时拆成两张图集按需绑定。
6. 从能跑到跑好：性能调优的优先级
6.1 先测量，再优化
我见过太多人一上来就优化网格生成算法，结果发现瓶颈其实在 draw call 或者纹理上传。正确的顺序是先用浏览器性能面板定位热点：是 JS 执行时间长，还是 GPU 等待时间长，还是内存分配频繁。体素场景里，我遇到的瓶颈分布大致是——网格生成占 40%，draw call 与状态切换占 25%，纹理上传占 15%，物理与逻辑占 20%。这个分布因项目而异，但网格生成通常是最大头，所以优先优化它收益最高。
6.2 分帧与预算控制
无论怎么优化，总会有超出预算的时候。这时要做的是分帧：给每帧的网格生成设定一个时间预算（比如 4 毫秒），超出的区块推迟到下一帧。玩家快速移动时，远处区块可以晚一两帧出现，但帧率必须稳住。实现上就是在 WASM 的批量重建函数里加一个时间检查，处理完当前区块后看是否超预算，超了就返回已处理数量，JS 侧把剩余区块留到下一帧。这个机制让帧率曲线平滑了很多，代价是极端情况下区块加载略有延迟，但玩家几乎感知不到。
6.3 对象池与复用
WASM 侧虽然不用 GC，但 JS 侧的临时对象还是要控制。比如每帧的脏区块列表、上传任务列表，如果每帧新建数组，GC 压力依然存在。我的做法是预分配固定大小的数组当对象池，每帧重置索引而不是新建。这个习惯在长期运行的应用里能显著减少 GC 次数，尤其是那些每秒 60 帧、每帧都分配的场景。
7. 这套架构还能往哪走
体素渲染这套"WASM 算 + WebGL 画 + 共享内存传"的架构，其实不局限于方块游戏。任何"大规模规整数据 + 实时可视化"的场景都能套用：点云渲染、科学数据体可视化、大规模建筑信息模型浏览、甚至在线 3D 地图。核心思想是一致的——把数据结构和计算放进 WASM 的线性内存，把渲染和交互留在 JS，两者通过预分配的共享缓冲零拷贝通信。
我在实际项目里体会最深的一点是：架构决策要在写第一行代码前想清楚，尤其是内存布局。体素数据的 slot 大小、顶点格式的字节对齐、暂存区的双缓冲，这些一旦定下来，后期改动成本极高。反倒是具体的网格算法、剔除策略，可以边跑边调。所以如果你要动手做类似的东西，先把内存地图画在纸上，把每个字节的用途标清楚，再开始写代码——这一步花的时间，会在后面调试时十倍地省回来。
