热更新

热更新解决的是一个很现实的问题：手游发新包要过应用商店审核，短则几小时长则数天，线上出了严重 Bug 等不起。热更新让客户端绕过商店，直接从自家服务器拉补丁——玩家重启游戏甚至不重启就能拿到修复。除了救火，日常的活动配置、数值调整、资源替换也大量走热更，这是长线运营游戏保持内容节奏的基础设施。

但热更新不是万能的。能热更的范围取决于技术架构（脚本逻辑、配置、资源通常可以，底层原生代码一般不行），而且各平台对热更新有政策边界，尤其 iOS 对更新原生代码逻辑的行为有明确限制，用力过猛有下架风险。所以团队一般会区分：什么改动走热更，什么必须发大版本整包。

PM 视角

PM 不需要懂热更的技术实现，但必须懂它的管理含义：

第一，摸清自己项目”什么能热更、什么不能”，这直接决定你的排期弹性和事故响应预案。哪类 Bug 能当天修，哪类要等下个版本，心里要有张表。

第二，警惕”反正能热更”的心态。热更通道太顺畅，团队容易放松版本质量意识，把热更当成兜底。热更本身也是发布，也要测试、也要审批、也可能把小问题修成大事故——线上事故不少是”修 Bug 的热更”引发的。

第三，热更要有记录和节奏。每次热更改了什么、谁批的、验证结果如何，都要留痕。频繁的计划外热更是版本质量恶化的预警信号，PM 要把它当指标看。