如果你正在为网页游戏挑选引擎，得到的默认推荐几乎都是Unity，默认理由则是“它是行业标准”。这句话没错，但和你真正要回答的问题基本无关。

我两种方式都发过网页游戏。下面这份对比，是我当初希望有人能直接给我的——包括那些Unity确实更合适的场景，因为这样的场景确实存在，假装没有会让整篇内容失去可信度。

打开网易新闻 查看精彩图片

决定性的问题：你是为浏览器开发，还是导出到浏览器？

这是整个争论的核心，所以放在最前面说。

Unity的WebGL支持本质上是一个导出目标。你在为原生平台设计的编辑器里构建游戏，然后生成一个浏览器版本。对Unity而言，网页是目的地，不是原生栖息地。这个决定向下游传导的一切——包体大小、加载时间、调试方式——都由此而来。

而Web原生技术栈（Three.js、PixiJS、纯TypeScript）把浏览器当作首要平台。你开发时运行的东西，就是用户最终运行的东西。

如果浏览器只是你发布的五个平台之一，Unity的导出模型是合理的取舍。但如果浏览器才是你玩家真正所在的地方——比如即点即玩的小游戏、可玩广告、Web优先的免费游戏——那你就是在为用不上的能力，为每一次构建支付导出税。

Web技术栈在哪些方面明显胜出

包体大小与首帧时间。Unity WebGL构建在加载你的游戏之前，先要加载一个引擎运行时。无论你的游戏是解谜小游戏还是开放世界，首次加载的载荷里都包含一个体积不小的WASM二进制文件。而Three.js或PixiJS的构建，加载的差不多就是你写的代码加上你引入的库，并且能像任何其他Web应用一样做代码分割。

这一点的影响不成比例地大，因为网页游戏玩家不会等。每多一秒加载时间，都会让你损失可观的转化漏斗份额。在移动网络环境下，先加载引擎运行时的载荷，是一个实实在在的转化问题。如果你的获客依赖即点即玩，单凭这一点就可能决定技术栈的选择。

迭代速度。Web的刷新是亚秒级的。没有编辑器域重载，没有“改一个数字”和“看到这个数字”之间的构建步骤。在重度调参的一天里——这在运营中的游戏里是常态——这些时间累积起来就是几个小时。

无需商店审核的线上运营。这是让没发过免费游戏的人最意外的一点。引擎游戏要发布一个平衡性调整，需要走二进制构建和商店审核流程。而Web游戏推送JavaScript和资源，几分钟就能完成。当你在周六需要修复一个崩溃的经济系统时，“几分钟”和“一周”是两种完全不同的生意。配合Capacitor打包，再通过Capawesome走空中更新，既能获得原生商店的露出，又能保留快速通道。

调试就是浏览器本身。Chrome DevTools、真实的堆快照、真实的网络面板、真实的性能剖析——整个Web行业每年都在打磨的同一套工具。没有任何引擎特有的东西需要额外学习。

AI代理能真正读懂你的项目。这一点比较新，而且我认为是被低估得最严重的一条。一个Web游戏项目，AI可以直接读取和理解。这对现代开发流程的影响，可能比很多人意识到的都要大。