游戏客户端资源清单：版本号、依赖和回滚要一起设计

资源清单不是下载列表

很多团队第一次做资源更新时，会把 Manifest 理解成“有哪些文件需要下载”。这只说对了一半。一个真正可用的资源清单，还要回答文件属于哪个版本、依赖谁、校验值是什么、是否可选、能不能回滚、和代码版本是否兼容。

Manifest 里应该有什么

一份实用的资源清单通常包含资源路径、资源哈希、大小、资源类型、所属包、依赖列表、压缩方式、最小客户端版本、是否强制、分组标签和发布时间。字段不一定一次做完，但哈希、大小、依赖和兼容版本最好一开始就有。

flowchart TD
    A[客户端代码版本] --> B{读取本地 Manifest}
    B --> C[请求远端 Manifest]
    C --> D{兼容性检查}
    D -->|不兼容| E[提示整包更新]
    D -->|兼容| F[计算差异]
    F --> G[按依赖排序下载]
    G --> H[哈希校验]
    H -->|失败| I[重试或切备用 CDN]
    H -->|成功| J[切换活动 Manifest]
    J --> K[进入游戏]

依赖要由工具生成

手写依赖几乎一定会错。资源依赖应该由打包工具扫描生成，客户端只负责读取和校验。Prefab 引用贴图、材质引用 Shader、UI 面板引用图集、动画引用骨骼，这些都要进入依赖图。

版本号要分层

客户端至少有代码版本、资源版本、配置版本和协议版本。把它们混成一个版本号，会让灰度和回滚变得笨重。比如资源修一个贴图，不应该强迫玩家更新整包；协议字段变化，却不能只推资源解决。

灰度发布要能定位

资源灰度常见场景是先给 5% 玩家推新活动资源，观察崩溃和加载失败。如果 Manifest 没有灰度 ID，日志里只看到“资源缺失”，很难知道玩家拿的是哪一批资源。

回滚不是删除新资源

资源回滚需要设计。最安全的方式是保留上一份可用 Manifest 和资源缓存。当新 Manifest 被判定有问题时，客户端可以切回上一份，而不是临时删除文件。

小结

Manifest 是客户端资源系统的账本。账本清楚，下载、校验、灰度、回滚才有依据。它不是上线前临时拼出来的文本，而应该从资源生产、打包、发布到运行时加载全程参与。

上线前的复盘清单

资源清单最后容易输在细节。团队可以在提测前做一次十五分钟复盘：入口是否只有一个，失败路径是否能被重复触发，日志里是否能看到关键上下文，弱网、低内存、切后台、热更新后首次进入这些场景是否有人真正跑过。清单不需要很长，但要能挡住最常见的事故。

第一项是边界。哪些状态属于客户端暂存，哪些必须等服务端确认，哪些只是表现层效果，要写在需求文档或接口说明里。第二项是恢复。玩家断网、杀进程、锁屏、切换账号、更新资源后回来，客户端应该回到哪个画面，是否会重复扣道具或重复弹奖励。第三项是可观测。没有日志、没有埋点、没有版本号和配置号，线上问题只能靠猜。第四项是降级。低端机、老资源包、灰度配置错误时，系统能否退到朴素但可用的路径。

版本治理不是为了把代码写得保守，而是为了让客户端在真实环境里少一点脆弱。玩家不会按测试用例玩游戏，他会在地铁里切网络，在战斗结算前接电话，在更新到一半时锁屏，也会在礼包倒计时最后几秒连续点击。能承受这些动作的系统，通常不是靠某个聪明函数撑起来的，而是靠清楚的状态、稳定的数据、可回放的日志和足够朴素的失败处理撑起来的。

和策划、美术、服务端对齐

很多资源清单问题表面看是客户端实现，根上却是协作边界没有说清楚。策划需要知道哪些反馈可以立即出现，哪些反馈必须等待权威结果；美术需要知道资源尺寸、动画事件、特效峰值和加载时机的预算；服务端需要知道客户端会缓存什么、重试什么、放弃什么。只要这些假设没有写下来，后续迭代就会靠口头记忆运转。

比较有效的做法是把一页协作说明放在需求旁边，列出输入、输出、失败处理和验收方式。比如资源类需求要写明包体归属、依赖关系、是否允许边玩边下；战斗类需求要写明本地预演和服务端确认的差异；UI 类需求要写明列表规模、刷新频率和关闭后的状态保留。说明越具体，返工越少。

上线后也要保留一条反馈通道。客服截图、玩家录像、崩溃堆栈、埋点漏斗和灰度数据都能帮助团队判断问题在哪一层。客户端工程师不应该只等 bug 单，而要主动把现象翻译成可定位的问题：是资源缺失、状态跳转错误、请求重复、表现未降级，还是需求本身给了互相冲突的规则。

一个容易忽略的成本

资源清单还有一个成本是新人理解成本。项目越到中后期，真正危险的不是某个类多了两百行，而是没人能说清一次完整流程经过哪些模块。新同事接手时，如果只能靠全局搜索和断点追踪，很容易在修一个小问题时改坏另一条路径。

因此我更偏向把关键流程画出来，并在代码里保留少量稳定的命名：状态名、事件名、错误码、资源阶段名尽量和文档一致。这样排查问题时，日志、配置、代码和运营后台看到的是同一套语言。语言统一以后，团队讨论会短很多，也更少出现“我以为你说的是另一个状态”的误会。

这类维护成本不会在第一周显现，但会在每次版本合入、每次活动复用、每次紧急修复里持续计息。早一点把结构讲清楚，后面就少一点靠资深同学记忆救火的依赖。

上线前的复盘清单

资源清单最后容易输在细节。团队可以在提测前做一次十五分钟复盘：入口是否只有一个，失败路径是否能被重复触发，日志里是否能看到关键上下文，弱网、低内存、切后台、热更新后首次进入这些场景是否有人真正跑过。清单不需要很长，但要能挡住最常见的事故。

第一项是边界。哪些状态属于客户端暂存，哪些必须等服务端确认，哪些只是表现层效果，要写在需求文档或接口说明里。第二项是恢复。玩家断网、杀进程、锁屏、切换账号、更新资源后回来，客户端应该回到哪个画面，是否会重复扣道具或重复弹奖励。第三项是可观测。没有日志、没有埋点、没有版本号和配置号，线上问题只能靠猜。第四项是降级。低端机、老资源包、灰度配置错误时，系统能否退到朴素但可用的路径。

版本治理不是为了把代码写得保守，而是为了让客户端在真实环境里少一点脆弱。玩家不会按测试用例玩游戏，他会在地铁里切网络，在战斗结算前接电话，在更新到一半时锁屏，也会在礼包倒计时最后几秒连续点击。能承受这些动作的系统，通常不是靠某个聪明函数撑起来的，而是靠清楚的状态、稳定的数据、可回放的日志和足够朴素的失败处理撑起来的。

和策划、美术、服务端对齐

很多资源清单问题表面看是客户端实现，根上却是协作边界没有说清楚。策划需要知道哪些反馈可以立即出现，哪些反馈必须等待权威结果；美术需要知道资源尺寸、动画事件、特效峰值和加载时机的预算；服务端需要知道客户端会缓存什么、重试什么、放弃什么。只要这些假设没有写下来，后续迭代就会靠口头记忆运转。

比较有效的做法是把一页协作说明放在需求旁边，列出输入、输出、失败处理和验收方式。比如资源类需求要写明包体归属、依赖关系、是否允许边玩边下；战斗类需求要写明本地预演和服务端确认的差异；UI 类需求要写明列表规模、刷新频率和关闭后的状态保留。说明越具体，返工越少。

上线后也要保留一条反馈通道。客服截图、玩家录像、崩溃堆栈、埋点漏斗和灰度数据都能帮助团队判断问题在哪一层。客户端工程师不应该只等 bug 单，而要主动把现象翻译成可定位的问题：是资源缺失、状态跳转错误、请求重复、表现未降级，还是需求本身给了互相冲突的规则。

一个容易忽略的成本

资源清单还有一个成本是新人理解成本。项目越到中后期，真正危险的不是某个类多了两百行，而是没人能说清一次完整流程经过哪些模块。新同事接手时，如果只能靠全局搜索和断点追踪，很容易在修一个小问题时改坏另一条路径。

因此我更偏向把关键流程画出来，并在代码里保留少量稳定的命名：状态名、事件名、错误码、资源阶段名尽量和文档一致。这样排查问题时，日志、配置、代码和运营后台看到的是同一套语言。语言统一以后，团队讨论会短很多，也更少出现“我以为你说的是另一个状态”的误会。

这类维护成本不会在第一周显现，但会在每次版本合入、每次活动复用、每次紧急修复里持续计息。早一点把结构讲清楚，后面就少一点靠资深同学记忆救火的依赖。

上线前的复盘清单

资源清单最后容易输在细节。团队可以在提测前做一次十五分钟复盘：入口是否只有一个，失败路径是否能被重复触发，日志里是否能看到关键上下文，弱网、低内存、切后台、热更新后首次进入这些场景是否有人真正跑过。清单不需要很长，但要能挡住最常见的事故。

第一项是边界。哪些状态属于客户端暂存，哪些必须等服务端确认，哪些只是表现层效果，要写在需求文档或接口说明里。第二项是恢复。玩家断网、杀进程、锁屏、切换账号、更新资源后回来，客户端应该回到哪个画面，是否会重复扣道具或重复弹奖励。第三项是可观测。没有日志、没有埋点、没有版本号和配置号，线上问题只能靠猜。第四项是降级。低端机、老资源包、灰度配置错误时，系统能否退到朴素但可用的路径。

版本治理不是为了把代码写得保守，而是为了让客户端在真实环境里少一点脆弱。玩家不会按测试用例玩游戏，他会在地铁里切网络，在战斗结算前接电话，在更新到一半时锁屏，也会在礼包倒计时最后几秒连续点击。能承受这些动作的系统，通常不是靠某个聪明函数撑起来的，而是靠清楚的状态、稳定的数据、可回放的日志和足够朴素的失败处理撑起来的。

和策划、美术、服务端对齐

很多资源清单问题表面看是客户端实现，根上却是协作边界没有说清楚。策划需要知道哪些反馈可以立即出现，哪些反馈必须等待权威结果；美术需要知道资源尺寸、动画事件、特效峰值和加载时机的预算；服务端需要知道客户端会缓存什么、重试什么、放弃什么。只要这些假设没有写下来，后续迭代就会靠口头记忆运转。

比较有效的做法是把一页协作说明放在需求旁边，列出输入、输出、失败处理和验收方式。比如资源类需求要写明包体归属、依赖关系、是否允许边玩边下；战斗类需求要写明本地预演和服务端确认的差异；UI 类需求要写明列表规模、刷新频率和关闭后的状态保留。说明越具体，返工越少。

上线后也要保留一条反馈通道。客服截图、玩家录像、崩溃堆栈、埋点漏斗和灰度数据都能帮助团队判断问题在哪一层。客户端工程师不应该只等 bug 单，而要主动把现象翻译成可定位的问题：是资源缺失、状态跳转错误、请求重复、表现未降级，还是需求本身给了互相冲突的规则。