Web 小游戏引擎与工具链选型清单（含对比表）

做第一款网页小游戏时，最容易浪费时间的决定不是「写代码」，而是「选错引擎」。选对了，一个下午能跑出一个能玩的循环；选错了，会在两周后还在和框架的抽象层搏斗。这份清单把主流的六个方案横向摆在一起，并给出「先做什么、后做什么」的顺序——所有条目都是长期可访问的公开资源，不做付费墙推荐。

六个方案横向对比

一句话选型

如果你还不确定学哪个 —— 先用 Canvas 原生 写一个最小可玩循环。理解「requestAnimationFrame + 时间步长 + 状态更新」这三件事之后，换任何引擎都不会被概念绊倒。很多教程一上来就讲引擎 API，反而让人以为游戏开发的核心是框架。

如果目标是 2D 且需要物理碰撞 —— 用 Phaser。它把精灵、动画、场景管理、碰撞检测打包好了，官方文档和示例可以直接跑通，最适合「做一个街机或动作小游戏」这种明确目标。站内 24 款游戏里的街机与动作分类，基本都是这个技术路线。

如果你自己写玩法逻辑、只想要一个渲染层 —— 用 PixiJS。它是极速 WebGL 渲染库，不替你决定游戏怎么写，只负责把画面画出来。当你的玩法已经想清楚了，只差一个 performant 的渲染方案时，它是最合适的选择。

如果要做 3D —— 用 Three.js。站内 3D 展厅 就是基于同类技术栈做的（WebGL + 模块化 importmap），可直接参考其实现方式。

如果团队写 TypeScript —— 用 Excalibur.js。它是 TypeScript 原生的 2D 引擎，类型定义完整，适合偏好强类型的前端团队。

如果只是想快速验证一个玩法 —— 用 Kaboom.js。文档短、上手快，验证完就扔，不值得为一个 demo 引入重型框架。

工具链顺序：从零做出第一款

按这个顺序做，每一步的产出都是下一步的输入，不会白做：

第一步 —— 用 Canvas 写一个最小可玩循环。 目标只有一个：一个会动的小方块，能用方向键控制、能吃到食物、能计分。这一步不追求好看，只追求「亲手写过一遍主循环」。

第二步 —— 用 Kenney 的 CC0 素材替换掉占位方块。 这一步会让你第一次直观感受到「素材决定观感」，也为后续的美术选型建立判断。

第三步 —— 在 itch.io 或本地静态服务器上调手感。 手感（加速度、土狼时间、输入缓冲、跳跃高度）是独立于引擎的技能，早点单独练比混在引擎学习里高效得多。

第四步 —— 发布到 Cloudflare Pages / Netlify / Vercel。 纯静态小游戏不需要服务器，一份 HTML 加几个资源目录就够了。三个平台都有免费额度和 HTTPS。

第五步 —— 补齐页面结构。 按站内的 游戏页结构说明 写清规则、技巧、亮点与 FAQ 四段——这不只是 SEO 需求，它同时是 AI 助手能否引用你这个页面的前提。

可商用素材清单

素材是 Web 小游戏最容易踩版权坑的地方，优先用明确授权的站点：

• Kenney 素材库 —— 大量 CC0 游戏素材（精灵图、音效、UI），商用免署名
• OpenGameArt —— 开源游戏艺术社区，每个条目都标注授权方式，下载前看清 License
• Freesound —— 音效与录音共享库，按 CC 协议分层筛选，商用前确认具体条款
• Google Fonts —— 开源字体，站内标题字体即出自此类来源
• Google Material Icons —— 统一风格的图标集，适合按钮与菜单
• Mixkit —— 免费视频、音频与模板素材，许可宽松

学习与文档

• MDN Canvas 教程 —— Canvas 绘制与动画的权威入门
• MDN HTML Canvas 元素 —— 元素级 API 说明与浏览器支持情况
• web.dev —— 面向前端的性能、可访问性与最佳实践指南
• Chrome Developers —— 浏览器特性、性能分析与调试工具的官方文档
• Can I use —— 查询各浏览器对某特性的支持率，决定兼容策略
• itch.io —— 独立游戏平台，作品发布、试玩与找玩家都在这里
• GitHub —— 开源引擎、模板与示例代码的主仓库