Phaser 资源加载与缓存策略：首屏快，不代表后面可以乱

从一个真实问题开始

有一次线上活动页的留存数据非常奇怪：玩家打开速度不慢，首屏 2 秒内出现，但第三关开始流失突然升高。测试回放以后才发现，第三关第一次出现新怪物时会卡一下，随后播放的技能音效还慢半拍。首屏指标很好看，真实体验却在中段崩掉。

这个问题发生在一款关卡制消除战斗 H5 游戏里。当时我的角色是负责加载链路的前端游戏工程师，最先做的不是马上改代码，而是把玩家路径、设备环境、资源状态和场景切换顺序重新走了一遍。Phaser 项目很容易给人一种“代码都在前端，问题应该很好定位”的错觉；实际到了线上，浏览器、渠道容器、资源缓存、输入焦点和玩家习惯会一起参与结果。

这篇文章讨论的核心是：资源加载不是 Loading 条，而是资源何时进入缓存、何时被消费、何时释放的策略。如果只看 API，很容易把 Phaser 学成一组函数；如果从项目交付看，就必须关心边界、生命周期、失败兜底和调试证据。下面会围绕 玩家从入口进入首关、解锁新怪、打开商店、切换活动皮肤的过程 展开，把经验落到可执行的工程判断上。

先看整体结构

flowchart LR
    A[首屏必需资源] --> B[进入首关]
    B --> C[后台预取第二关怪物]
    C --> D{玩家进入新关卡}
    D -->|缓存命中| E[直接创建对象]
    D -->|缓存缺失| F[短加载层补齐]
    E --> G[关卡结束]
    F --> G
    G --> H[保留通用资源并释放一次性资源]

这张图不是为了显得复杂，而是提醒我们：玩家看到的是一个连续体验，工程上却是多个系统串起来的结果。LoaderPlugin、Texture Cache、Audio Cache、JSON 配置、Atlas 图集、资源清单 都有自己的职责，任何一个环节偷懒，最后都会变成“怎么偶尔不对”的线上问题。

一段可以落地的代码切口

下面这段示例不是完整框架，只是为了说明 资源分阶段加载 应该如何从一开始就留下边界。真实项目里可以继续封装，但不要在还没说清职责前就追求抽象。

const packs = {
  core: ['ui', 'hero', 'common-audio'],
  level01: ['level-01-map', 'slime-atlas'],
  shop: ['shop-icons', 'skin-preview']
};

function loadPack(scene, packKey) {
  for (const key of packs[packKey]) {
    if (!scene.textures.exists(key)) {
      scene.load.atlas(key, key + '.png', key + '.json');
    }
  }
  scene.load.start();
}

代码里的重点不是语法，而是控制权。Phaser 的对象和插件都很好调用，难点是不要让每个回调都直接修改全局状态。只要控制权分散，后续就会出现“这个字段到底是谁改的”“为什么第二次进入场景不一样”“为什么关闭弹窗后玩法状态变了”之类的问题。

首屏快只是第一关

Web 游戏很容易被首屏指标牵着走。入口页加载得快当然重要，但游戏体验是一条连续链路。玩家不会因为第一屏快就原谅第三关卡顿，也不会因为 Loading 条顺滑就接受技能第一次释放时卡住。Phaser 的 Loader 很好用，但它不会替项目决定哪些资源应该提前加载。

资源策略要围绕玩家路径设计。首屏只需要入口 UI、基础字体、主角、第一关资源和必要音频。第二关怪物、商店大图、活动皮肤、稀有技能特效，可以在玩家已经进入可玩状态后再慢慢准备。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

资源清单要来自玩法

很多加载问题不是技术 API 用错，而是清单来源不可靠。策划改了关卡配置，新增怪物资源没有进入预加载；美术替换图集名字，旧缓存仍然被引用；活动换皮肤，商店预览图忘记加入 CDN。解决这些问题靠人工记忆不现实。

更好的做法是从关卡配置、角色配置、技能配置中生成资源清单。Phaser 只负责执行加载，清单应该由玩法数据推导。这样策划新增一个怪物时，资源依赖会自然跟着关卡走，而不是等 QA 第一次遇到新怪才发现白块。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

Texture Cache 不是垃圾桶

Phaser 的 texture cache 让重复使用资源非常方便，但缓存不是无限空间。H5 游戏经常运行在移动浏览器里，内存上限并不宽松。活动图、剧情插图、一次性大背景如果一直留在缓存里，几轮关卡以后就可能触发浏览器回收甚至页面崩溃。

缓存策略可以分三类：核心常驻、场景级缓存、一次性缓存。核心常驻包括主角、通用 UI、常用音效；场景级缓存跟着关卡或玩法模式走；一次性缓存用完就释放。释放前要确认没有显示对象还在引用对应 texture，否则你会得到更难排查的渲染异常。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

音频要单独考虑

音频资源和贴图不同。移动浏览器有自动播放限制，音频解码和播放策略也受设备影响。把音频当作普通图片一样加载，经常会遇到资源存在但无法播放、第一次播放延迟、后台恢复后静音等问题。

实践中可以把音频分为 UI 点击音、战斗高频音效、背景音乐和语音。UI 点击音要尽早解锁，战斗音效要在进战斗前预热，背景音乐要处理暂停恢复，语音则更适合按需加载。不要为了方便把全量音频塞进首包，这对移动网络非常不友好。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

加载失败要设计体验

CDN 抖动、弱网、跨域配置、缓存污染都会让加载失败。最糟糕的处理方式是让 Loader 错误静默发生，场景继续创建，然后玩家看到黑块或空白。加载失败应该有明确的阶段、重试策略和兜底资源。

对关键资源，可以阻塞并给出重试；对非关键装饰，可以使用占位图并记录错误；对活动资源，可以隐藏入口或显示稍后再试。失败处理不是技术洁癖，而是避免一个小资源把整局游戏拖死。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

后台预取要有节制

预取可以减少后续卡顿，但无节制预取会抢占带宽、增加内存、拖慢当前帧。尤其是在战斗中后台加载大量贴图，可能让浏览器主线程和 GPU 上传产生抖动。预取应该选择玩家很可能马上用到的资源，并限制并发。

一个实用策略是按玩家路径设优先级：下一关资源高于远期活动资源，正在展示的商店图标高于未滚动到的商品，当前角色技能高于未解锁技能。预取是预测，不是把下载压力提前甩给用户。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

版本和缓存要一起设计

H5 游戏发布频繁，资源缓存很容易遇到版本问题。代码已经引用新图集，浏览器却命中旧 JSON；CDN 上图片更新了，atlas 元数据还没更新；灰度版本和正式版本共用 key，导致玩家进入错误资源组合。

资源 key 最好带有稳定语义和版本约束。资源清单中记录 hash，加载前确认清单版本，必要时清理旧缓存。Phaser 内部 cache 解决的是运行期复用，不解决浏览器和 CDN 层面的版本一致性。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

落地清单

上线前至少检查：首屏资源是否最小化；第一局首次释放技能是否卡顿；关卡新增资源是否从配置自动推导；加载失败是否能重试；一次性大图是否释放；移动端后台恢复后音频是否正常；灰度版本是否不会污染正式缓存。

资源加载做得好，玩家不一定会夸；做得差，玩家会立刻离开。Phaser 提供了很顺手的工具，但真正决定体验的是项目如何定义资源边界、优先级和失败策略。

在实际协作中，我会把这部分写进开发检查表，而不是只放在口头约定里。因为 Phaser 项目的迭代速度通常很快，今天为了活动临时加的逻辑，三周后就可能变成复用模板。越是轻量项目，越要在关键位置把规则写清楚。

排查问题时的顺序

遇到相关问题时，不建议先凭经验改参数。更稳的顺序是先复现，再缩小范围，最后才动代码。复现时要记录设备、浏览器、渠道容器、网络、页面可见状态、游戏版本和资源版本。很多 H5 游戏问题只在特定容器里出现，如果只在桌面 Chrome 里验证，很容易得到错误结论。

缩小范围时，可以把链路拆成输入、状态、资源、表现和持久化几段。先确认玩家意图有没有被收到，再确认状态机有没有接受，再确认 Phaser 对象有没有正确执行，再确认表现层有没有被镜头、缩放、缓存或音频策略影响。这样的排查路径比“看哪里像问题就改哪里”慢一点，但能避免改出新问题。

最后是留证据。开发版日志、调试面板、可视化边界、状态快照和小型回放，都比口头描述可靠。尤其是涉及 资源分阶段加载 的问题，录屏只能告诉你现象，不能告诉你内部状态。把内部状态展示出来，团队才有共同语言。

团队协作里的责任划分

Phaser 项目经常由少数工程师快速推进，因此容易忽略协作边界。可是一旦项目进入运营，策划会改配置，美术会换资源，运营会调整活动，渠道会接 SDK，测试会覆盖多设备。工程代码如果没有把责任划清，每个角色都会被迫理解太多底层细节。

比较健康的方式是让配置描述意图，让服务层解释规则，让 Scene 编排生命周期，让表现对象执行动画和反馈，让平台适配器处理浏览器或渠道差异。这样策划新增内容时不需要知道 Scene 的内部结构，美术替换资源时不会改变玩法规则，运营关闭活动时不会留下半开半关的 UI 状态。

这不是大团队才需要的流程。越小的团队越需要减少隐性沟通成本。一个清楚的边界，可以让后续每一次临时需求都少一点风险。

上线前最后一轮检查

最后一轮检查不要只点一遍主流程。至少要覆盖首次进入、第二次进入、弱网、低端设备、后台恢复、快速重复点击、资源失败、配置缺字段和旧数据升级。很多 Phaser Bug 都出现在“第二次”或者“恢复后”：第二次开局、第二次打开弹窗、第二次播放音频、第二次加载同一图集。

如果这篇文章讨论的系统已经接近上线，我会要求团队给出三类证据。第一是功能证据，证明主流程确实可用；第二是边界证据，证明失败和异常路径不会把玩家卡死；第三是观测证据，证明线上再出问题时能定位。只有这三类证据都存在，才算不是靠运气发布。

结语

Phaser 的优势是轻、快、直接。它能让一个想法很快变成可以玩的东西，也正因为如此，项目很容易在“先跑起来”之后忽略工程边界。资源加载不是 Loading 条，而是资源何时进入缓存、何时被消费、何时释放的策略。把这个原则落实到代码里，项目就不会因为功能增加而迅速失控。

真正可靠的 Phaser 游戏，不是每个模块都写得很重，而是关键链路有清楚的生命周期、明确的责任、可降级的失败路径和能解释问题的调试证据。做到这些，即使项目仍然保持轻量，也能承受上线后的真实流量和频繁改动。