Phaser 与 PixiJS：Web 2D 框架的能力、开发状态与选型

AI 参与说明（Agent：Codex）：本文由 Codex 根据 Phaser、PixiJS 的官方文档、固定版本源码与发布记录辅助调研、撰写和校验，资料整理于 2026-10-08。场景匹配与选型流程是本文的工程建议。执行入口为 Codex Desktop，提供方为 OpenAI；完整模型标识与 reasoning effort 未取得可核验运行记录。

需要一套现成的 2D 游戏运行机制，优先评估 Phaser；需要可嵌入 Web 应用、由自己组织规则的 2D 画布，优先评估 PixiJS。 两者都能做游戏，区别主要在于替开发者承担多少职责。不能仅凭“PixiJS 更底层”推导它一定更快，也不能因为 Phaser 功能完整，就认为它会自动运行全部子系统。

本文以 Phaser 4.2.1、PixiJS 8.22.0 为示例基线，同时解释 Phaser 3 的历史与迁移边界。版本依据是核验日的官方发布记录；后续读者应重新检查 Phaser Releases 与 PixiJS Releases。

先认识本文的术语

两个项目分别解决什么问题

Phaser：把常见游戏机制提前组合好

Phaser is a 2D HTML5 game framework with its own renderer and game systems. 官方提供 JavaScript API 与 TypeScript 类型，围绕 Scene 组织资源加载、对象创建和每帧更新，并提供输入、相机、动画、Tilemap、音频、物理等机制。Phaser：What is Phaser? · Scenes

例如一个俯视角冒险游戏，需要先载入地图和角色动画，再让相机跟随角色、处理方向输入、阻止角色穿墙，并在进入房屋时切换环境。Phaser 为这些工作提供了一套相互配合的入口。开发者仍要写玩法，但少做一层基础设施拼装。

Scene 不只是一个显示对象容器。它可以有自己的加载、更新、暂停、恢复、关闭等生命周期；多个 Scene 也可以同时运行，例如世界画面与覆盖其上的游戏界面。Phaser：Scenes

PixiJS：提供画面与交互基础，留下应用组织权

PixiJS is primarily a rendering library, with a scene graph, asset loading, a ticker, and pointer interaction. 它并非只能“画一张图”：Application 帮助初始化 Renderer 与 Ticker，Container 组织对象，Assets 加载资源，事件系统负责命中检测与指针交互。PixiJS：Architecture · Application · Events / Interaction

但是，一个 Container 不等于 Phaser 的 Scene。进入战斗后如何暂停世界、切换关卡时如何清理资源、哪一层拥有游戏状态，仍要由应用或另选的库决定。PixiJS 给的是组合这些能力的基础，而非一套预设的完整游戏结构。PixiJS：Scene Graph

这很适合既有 React 应用：表单、账户、列表、对话与设置继续由 DOM 界面负责，地图或编辑区域交给 PixiJS。代价是应用团队要承担相机控制、规则、音频、碰撞等实际需要的能力。

Phaser 基于 PixiJS 吗

Phaser 2 曾集成 PixiJS；Phaser 3 已改用自己的 Renderer。 Phaser 官方在 2018 年的开发日志中解释了这一变化，因此“Phaser 是套在 PixiJS 上面的游戏框架”只适用于特定历史版本。Phaser Dev Log 158：Farewell Pixi

Phaser 4 又重写了自己的 WebGL Renderer，从 Phaser 3 的 Pipeline 结构转向 RenderNode 结构。它也不是把当前 PixiJS 放在内部继续包装。Phaser：v3 to v4 Migration Guide

所以，今天的选型应比较两套独立实现及其工作方式。不能把 PixiJS 的某项优化自动算作 Phaser 已有能力，也不能把旧 Phaser 教程中的集成关系套用到新版本。

能力列表：内置、扩展与自己实现

下表中的“内置”表示项目提供对应机制；不表示所有功能默认开启，也不表示两边 API 或效果完全相同。“扩展”表示需要另外选包，并核对版本兼容性。

Phaser 的游戏能力可分别核对 Scenes、Input、Physics、Audio 与 官方仓库；PixiJS 的对象与扩展入口见 Architecture、ParticleContainer 和 Ecosystem。

版本核验有一个容易误判的例子：PixiJS 的 8.x Renderers 指南仍将 CanvasRenderer 写作 Coming-soon，但 8.22.0 的源码和版本化 API 已包含它。 本文按固定版本核对：autoDetectRenderer 支持 canvas，默认候选顺序为 WebGL、WebGPU、Canvas。只看指南会得到过时结论。8.x Renderers 指南 · 8.22.0 autoDetectRenderer 源码 · 8.22.0 CanvasRenderer 源码

Phaser 的 Physics 也要区分开来：Arcade Physics 适合较简单的矩形、圆形碰撞；Matter Physics 提供更复杂的刚体、形状与约束。它们需要配置和创建对应对象，并非使用 Phaser 就自动执行全部物理。Phaser：Physics

开发状态：维护活跃度与升级代价都要看

能力满足需求之后，还要判断依赖是否值得长期维护。下面是 2026-10-08 的公开快照，不是未来支持承诺。

发布时间与变更依据：Phaser Releases · PixiJS 8.21.0 · PixiJS 8.22.0。维护与支持入口见两者官方 Phaser 仓库和官方 PixiJS 仓库。

怎样解读这个状态

从这些发布样本看，PixiJS 最近的小版本发布更密集；Phaser 已完成一次较大的主线升级。这可以帮助安排升级与兼容性验证，但不能直接推导 PixiJS 更稳定，或 Phaser 已停止维护。发布频率与缺陷率、响应速度、长期支持是不同指标。

Phaser 4 的迁移指南明确列出破坏性变化。普通 Sprite、Text、Tilemap 的使用方式较熟悉，不代表自定义 Renderer 插件可以原样迁移；Canvas Renderer 在 4.x 中也已 deprecated。若项目依赖 Phaser 3 的插件，应先确认该插件支持哪一代 Renderer，再决定主线版本。Phaser：Migration Guide

PixiJS 8 的 Application 采用异步初始化，Graphics 与事件系统也有迁移事项。即使大版本不变，小版本仍可能改变可观察行为，例如 8.21.0 调整了矩阵分解结果，8.22.0 修复了 Tab 激活可访问性层的行为；只看“仍然是 8.x”不足以评估升级。PixiJS：v8 Migration Guide · 8.21.0 发布说明 · 8.22.0 发布说明

把维护风险落实到检查动作

本文建议，在选型小样中锁定框架与必要扩展的版本，并检查下面四件事：

1. 查依赖链。 确认 React、Tilemap、音频、相机等扩展的声明支持范围及公开测试；核心持续发布不保证扩展同时更新。
2. 读相关变更。 只关注项目用到的渲染、输入、纹理、资源释放等接口，再执行对应回归。
3. 检查问题处理。 选择与实际需求接近的公开 issue，观察是否有可复现案例、维护者回应和合并后的发布版本；Star 数量不能替代这个检查。
4. 做一次升级演练。 用同一场景验证加载、输入、显示、销毁和重建，记录需要修改的代码与扩展。长期成本比“第一次画出来用了几行”更有意义。

如果选择旧主线，必须单独核对其支持政策。本文没有证据将 Phaser 3 描述为具有指定期限的 LTS，也不把 PixiJS 8 的持续发布当作所有旧小版本都获维护的承诺。

性能：不用 PixiJS 会损失什么

没有脱离场景的固定损失比例。 Phaser 与 PixiJS 都有面向 GPU 的绘制优化。公平比较要先区分首屏加载、CPU 工作和 GPU 工作；否则可能把图片太大、业务更新太多或网络等待误认为 Renderer 的问题。

PixiJS 可能更合适的性能条件

当程序主要负责显示大量对象，并且团队愿意控制对象组织、更新频率、Batching 与资源生命周期时，PixiJS 的职责边界有利于只组合需要的系统。例如地图编辑器可以让背景层基本不变，拖动时只更新少数对象，而不是建立整套游戏机制。这是工程适配优势，不能据此保证更高帧率。

PixiJS 官方建议优先使用 Sprite 和合适的 Texture Atlas，注意对象顺序、混合模式与 Filter 对 Batching 的影响；Text 频繁改变会产生额外成本，可以按需求评估 BitmapText。Culling 也不是免费优化：CPU 已成为瓶颈时，增加剔除判断可能适得其反。PixiJS：Performance Tips

非交互的装饰对象应减少命中检测，例如按需设置 eventMode = 'none'；明确 hitArea、关闭不需要的子对象交互，也能减少事件遍历。PixiJS：Events / Interaction

Phaser 不等于自动支付全部功能的每帧成本

Phaser 的资源包包含多少代码，与运行时启用了多少系统，是两个问题。完整发行包可能带来下载和解析成本，但没有创建 Physics 世界或物理对象，就不能把对应模拟成本计入每帧更新。真正需要 Physics、Camera、Tilemap 与 Tweens 的游戏，使用已有系统也能减少重复实现。Phaser：Physics

同样不能拿一个旧 Phaser 3 测试与当前 PixiJS 对比，再把结果套用到 Phaser 4。Renderer 已发生变化，自定义 Filter、地图层或批量对象的实现也会改变负载。Phaser：Migration Guide

WebGPU 是选项，不是帧率保证

PixiJS 提供 WebGPU Renderer，但当前指南仍建议生产应用优先 WebGL，原因包含浏览器实现差异；8.22.0 的自动选择源码也把 WebGL 放在默认优先位置。WebGPU 无法自动消除 JavaScript 更新、对象排序、图片解码或大量透明像素的成本。PixiJS：Renderers · 8.22.0 autoDetectRenderer

本文未进行两框架的性能排名测试。若是否更换框架取决于性能，应使用后文的同条件小样取得证据。

哪些场景更适合 Phaser，哪些更适合 PixiJS

以下是基于能力边界的建议，表示优先试验方向，不表示另一方无法实现。

AI 小镇：决定因素是客户端承担多少工作

以居民生活与社交模拟为例，如果浏览器要提供角色直接操作、碰撞、相机跟随、地图切换、音效和较丰富的游戏反馈，Phaser 的组合优势比较明显。如果世界事实和规则主要在服务端，浏览器显示居民运动、建筑、气泡与选中状态，而大部分操作在 React 面板完成，PixiJS 更值得优先做小样。

两种情况下都应区分事实与表现：服务端给出的目标或位置，不必按照屏幕刷新率反复计算；客户端可以在两次状态更新之间平滑显示。LLM 决策、寻路、经济与社会规则，也不应因选用哪个 Renderer 就自动搬进逐帧回调。

flowchart TB
  A[客户端主要职责] --> B{是否经常需要相机、物理、地图与 Scene 生命周期一起工作}
  B -->|是| C[优先试验 Phaser]
  B -->|否| D{是否需要大量自定义 2D 显示与编辑交互}
  D -->|是| E[优先试验 PixiJS]
  D -->|否| F[先评估 React 与普通 DOM]
  C --> G[用相同素材、规则与目标设备验证]
  E --> G
  F --> G

图中的判断是本文建议。关于真实项目的引擎与玩法分工，可参见 my_ai_town 项目分析；改为 Web 交付后，应重新核对客户端职责，不能只按画面风格选择框架。

与 React 共存时，怎样划分状态

两边都有 React 接入入口：Phaser 提供官方 React 模板，PixiJS 提供 @pixi/react 等生态入口。接入前要检查模板或适配版本，特别是 Phaser 3 模板与 Phaser 4 的差异。Phaser React 模板 · PixiJS：Ecosystem

本文建议让 React 管理对话框、选中对象、工具模式等低频界面状态；Renderer 管理 Sprite 的每帧坐标、动画与相机表现。用户点击建筑后，向 React 发一个稳定的建筑标识即可，不需要每一帧重新创建整个组件树。

生命周期也要处理完整：路由离开后停止更新、解除监听、销毁实例；PixiJS 的初始化是异步的，还要处理初始化完成前组件已卸载的情况。SSR 阶段不要访问 Canvas 或浏览器对象，进入客户端后再建立画布实例。这里描述的是接入策略，不是一份可直接复制的 React 生命周期实现。PixiJS：Application

最小完整示例：实现相同的点击移动

下面两个 HTML 都使用 JavaScript 与固定版本 CDN，不需要图片素材。预期画面是一个 800 × 480 的区域，点击区域内任意位置，绿色方块以每秒 160 个逻辑像素向目标移动；本示例没有碰撞和寻路。

想先观察框架的实际效果，可以打开官方 Phaser Examples 或 PixiJS Examples。以下源文件用于复现与对照，不是性能基准。

Phaser 4.2.1：在 Scene 中处理输入和更新

保存为 phaser.html：

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>Phaser click-to-move</title>
<body>
  <p>Click inside the canvas to move the square.</p>
  <div id="game"></div>
  <script src="https://cdn.jsdelivr.net/npm/phaser@4.2.1/dist/phaser.min.js"></script>
  <script>
    class TownScene extends Phaser.Scene {
      create() {
        this.actor = this.add.rectangle(80, 240, 24, 24, 0x68d391);
        this.target = { x: 80, y: 240 };
        this.input.on('pointerdown', (pointer) => {
          this.target = { x: pointer.x, y: pointer.y };
        });
      }

      update(_time, delta) {
        const dx = this.target.x - this.actor.x;
        const dy = this.target.y - this.actor.y;
        const distance = Math.hypot(dx, dy);
        if (distance === 0) return;
        const step = Math.min(distance, 160 * Math.min(delta, 50) / 1000);
        this.actor.x += dx / distance * step;
        this.actor.y += dy / distance * step;
      }
    }

    new Phaser.Game({
      type: Phaser.WEBGL,
      width: 800,
      height: 480,
      parent: 'game',
      backgroundColor: '#172231',
      scene: TownScene,
    });
  </script>
</body>
</html>

这里没有配置 Physics；移动来自自己的规则，Scene 提供输入与更新入口。delta 以毫秒计算；示例将单次移动使用的时间限制到 50 毫秒，减少切回页面时的大幅跳跃，这不是权威模拟时钟。Phaser：Scenes

PixiJS 8.22.0：组合 Application、事件和 Ticker

保存为 pixi.html：

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>PixiJS click-to-move</title>
<body>
  <p>Click inside the canvas to move the square.</p>
  <script type="module">
    import { Application, Graphics } from
      'https://cdn.jsdelivr.net/npm/pixi.js@8.22.0/dist/pixi.min.mjs';

    const app = new Application();
    await app.init({
      width: 800,
      height: 480,
      background: '#172231',
      preference: ['webgl'],
    });
    document.body.appendChild(app.canvas);

    const actor = new Graphics().rect(-12, -12, 24, 24).fill(0x68d391);
    actor.position.set(80, 240);
    actor.eventMode = 'none';
    app.stage.addChild(actor);

    let target = { x: 80, y: 240 };
    app.stage.eventMode = 'static';
    app.stage.hitArea = app.screen;
    app.stage.on('pointerdown', (event) => {
      target = { x: event.global.x, y: event.global.y };
    });

    app.ticker.add((ticker) => {
      const dx = target.x - actor.x;
      const dy = target.y - actor.y;
      const distance = Math.hypot(dx, dy);
      if (distance === 0) return;
      const step = Math.min(distance, 160 * Math.min(ticker.deltaMS, 50) / 1000);
      actor.x += dx / distance * step;
      actor.y += dy / distance * step;
    });
  </script>
</body>
</html>

await app.init()、Graphics 的 rect().fill()、eventMode 与 Ticker 回调均按 PixiJS 8 的接口编写。hitArea 让空白画布也可以接收点击；将候选限制为 ['webgl']，是为了明确示例的后端，不启用自动降级。Application · Graphics · Events · Ticker · 8.22.0 Renderer 选择

在保存两份文件的目录运行以下命令，需要 Python 3、能够访问 CDN 的网络，以及支持 WebGL 的浏览器：

python3 -m http.server 8000 --bind 127.0.0.1

分别打开 http://127.0.0.1:8000/phaser.html 和 http://127.0.0.1:8000/pixi.html。点击方块右侧与左侧，确认它移动并停在目标中心；点击斜方向，确认速度未因方向而明显改变。两份例子均限制最后一步，避免越过目标后反复抖动。

本文已核对示例所用官方 API，并对内联脚本执行语法检查；未在浏览器运行这两份示例，因此这里不报告运行帧率或浏览器兼容性结果。

用同条件小样做最终选择

若已经确定目标是有地图、角色与编辑操作的 Web 2D 产品，本文建议比较同一个小样，而不是两个不同的官方压力演示。

1. 固定条件。 同一浏览器、设备、Canvas 尺寸、渲染分辨率、纹理资源和 WebGL 路径；区分开发构建与生产构建。
2. 逐层增加负载。 先只画静态地图，再加运动、动画、选中、气泡、排序、Filter，最后接业务状态；每层都记录变化。
3. 改变对象数量。 可使用 100、1,000、10,000 作为探测样本，区分总对象、可见对象和正在变化的对象；这些数字不是任何框架的容量承诺。
4. 记录分布。 预热后采集帧间隔与 CPU 主线程工作时间，至少看 p50、p95 和明显停顿，同时观察 Draw Call、资源占用与首次加载。60 FPS 对应约 16.7 毫秒的帧间隔预算，但主线程测量不能单独代表 GPU 耗时。
5. 算开发和维护成本。 完成一次地图切换、对象选择、缩放、离开页面后的销毁与重建，再做一次依赖升级；记录自行补齐的代码、扩展数量与失败案例。

最后按具体约束决策：若两边都满足帧预算，优先选能减少长期维护的方案；若一边失败，先定位是业务更新、事件遍历还是绘制，再评估优化或迁移。选择 PixiJS 的充分理由，可以是更适合自定义画布的职责边界；选择 Phaser 的充分理由，可以是实际需要它已有的游戏系统。 性能优势应由目标场景的数据补充。

关联阅读

• 用 Agent 与 AI 开发 Steam 独立游戏：技术选型、素材流程与开发者申请：把 Web 框架放回引擎与发行方案的整体比较。
• my_ai_town 项目分析：Godot 与 AI 社会模拟是否匹配：通过公开源码理解模拟事实、居民决策与画面表现的分工。