【调试热更】热更包版本管理与资源差分更新

热更不只是"把文件传下去"

脚本热更新成熟之后，下一个难题是工程化：几百个客户端手里的脚本版本五花八门，怎么让每个人安全地升到最新？没有版本管理机制的热更，等于在裸奔状态下给行驶中的车换轮子。本文给出一套可持续的热更发布流程。

版本清单：热更的中枢

服务器维护一份版本清单（manifest）：每一行是一个文件的"路径 + 内容 MD5 + 版本号 + 是否强制"。客户端启动时拉清单，逐个比对本地文件的 MD5，不一致的文件进入待更新列表。用 MD5 而不是文件修改时间，是因为时间戳在各类打包、传输环节太容易被破坏；MD5 相同即内容相同，判定可靠。

-- manifest 片段（示意）
-- path,md5,ver,force
-- script/item.lua,3fa8c21...,107,1
-- script/activity.lua,bb12d40...,23,0

差分更新：只发变化的部分

全量重发一个几百 MB 的资源包不现实，差分是标配。脚本类文件小，直接整文件替换即可；大资源（图集、音频）用差分算法（如 bsdiff 思路）只下发差异块，客户端与本地旧文件合成新文件。合成必须校验：合成结果的 MD5 与清单一致才允许替换，避免半途断网留下损坏文件。

发布纪律五条

灰度发布：新版本先对 1% 玩家开放，观察错误上报曲线平稳，再逐步放量到 100%。热更引入线上事故的概率永远不为零，灰度是唯一后悔药。

回滚预案：上一版全量包常驻服务器，一键回切清单指向。回滚演练要在上线前做一次，出事时才发现回滚脚本有 bug 就太讽刺了。

清单不可变：已发布的清单文件永不修改，发新版本生成新清单文件，版本号递增。改历史清单会让缓存与 CDN 全部失灵。

兼容窗口：新脚本上线后，旧客户端可能在跑旧逻辑、发旧协议。服务端至少在一个灰度周期内同时兼容新旧协议字段，处理完老版本请求再收紧。

发布记录：每次热更记录时间、变更文件列表、操作人与原因。回滚与追责全靠它。

这套流程搭建成本大约两三天，此后每次紧急修复都能安全落地——对比一次"热更引发全服故障"的损失，这是游戏运维里回报率最高的基建投资。