Cocos Creator 热更新流程，五步走完

2026-09-08 Cocos Creator,热更新,小游戏开发

第一次做热更新的人，大多会卡在同一个地方：本地明明换了资源，线上还是旧的。所以聊 Cocos Creator 热更新流程是什么，我一般不讲代码，先讲每一步怎么验证。

下面按顺序讲，每一步我给出「做什么」和「怎么确认它生效了」。

一、前提：先分清改的是什么

热更新能换的是资源，不是引擎和原生层。

所以第一件事是判断这次改动属于哪一类。改图、改数值、改脚本逻辑，通常走热更新；动了原生插件或者引擎版本，那就得重新提审。

这个判断做错，后面的步骤全是白费。

| 改动类型 | 能不能热更新 |

|---|---|

| 图片、音频、参数配置 | 可以 |

| 脚本逻辑 | 可以 |

| 原生插件、引擎版本 | 不行，要走提审 |

上面这张表是按「改的东西在包里还是在包外」分的。在包里的东西换不掉，记住这一句就够判断了。

第一步：给这次更新定版本

第一步是标记版本。你要用版本号区分「用户手上那份」和「你要发的那份」。

我的习惯是版本号只增不减，并且和内容对应。比如修一个界面问题就只加一次版本。

怎么确认生效：本地把版本号改掉，程序启动时应该能读到新的版本标识，而不是缓存里的旧值。

第二步：打出资源包并放到能访问的位置

第二步是把资源按规则导出来，上传到服务器或者对象存储。

这里最常见的失败不是打包失败，是路径写错。本地测试用的是本地路径，线上用的是域名路径，两者必须在配置里分开。

怎么确认生效：用浏览器或者命令行直接访问那个资源地址，能下载到文件，才算这一步做完。

第三步：写好版本清单

第三步是清单文件。热更新靠它来判断「本地哪些文件和线上不一样」。

清单里要包含版本号和每个资源的校验信息。清单本身也必须每次都更新，否则客户端会以为没有变化。

怎么确认生效：打开清单地址，看看里面的版本号是不是你刚发的那一版。这一步没过，后面再怎么查 Cocos Creator 热更新流程是什么都找不到问题。

第四步：客户端启动时先查清单再决定

第四步是客户端逻辑：启动时先拉清单，对比本地版本，有差异就下载。

下载这一步要处理失败和中断。用户网络不好是常态，不能假设一次就能下完。

怎么确认生效：在真机或者模拟器上冷启动一次，看日志里有没有走完对比和下载。

第五步：灰度和大版本兜底

最后一步容易被省掉：不要把新版本一次性推给所有人。

我的做法是先小范围验证，确认没问题再放开。同时保留一个兜底方案——万一热更新后起不来，用户至少还能退回旧版本。

怎么确认生效：找一台没更新过的设备，走一遍从旧到新的完整过程，而不是只看已经更新过的那台。这五步走完，Cocos Creator 热更新流程是什么这个问题就答完了，剩下的是每一步的细节耐性。

常见问题

Q：Cocos Creator 热更新流程是什么，能更新脚本吗？

A：能，脚本和资源都可以走热更新。但涉及原生层和引擎版本的改动不行，那类变更必须重新提交审核。

Q：热更新改动生效了，用户还是旧的怎么办？

A：先查清单文件里的版本号有没有更新，再查客户端启动时有没有真的去拉清单。这两处是最常见的失效点。

Q：热更新能不能保证用户立刻拿到新版本？

A：不能。更新会在用户下次启动时发生，具体时机不由你控制，所以关键修复别只依赖热更新这一条路。