热更新
Category
glossary 词条。节点定位：热更新是修复窗口、迭代速度与事故半径的权衡——每缩短一环修复链路，同时扩大一个线上变更入口。
Definition
热更新指不经过完整发版流程，让线上逻辑或资源的变化生效。围绕它的讨论从来不只是技术可行性，而是修复窗口、迭代速度和事故半径之间的权衡：热更把修复链路每缩短一环，同时也在扩大一个线上变更的入口。
Problem
热更讨论只问技术可行性就跑偏：真正的权衡是三件事——窗口多快、节奏多频、半径多大。没有分级、回滚与平台约束的热更体系，是把发布流程绕过去而不是优化它。
热更新通常分几个层级
- 资源热更：贴图、音频、表格内容，风险较低，量最大。
- 配置热更：参数和规则取值，见效最快，影响面可能很广。
- 脚本热更：逻辑层代码，灵活度最高，风险也最高。
- 服务端逻辑热更：节点内替换逻辑或热重启，取决于运行时设计。
不同层级的事故半径完全不同。讨论“要不要热更”时，先确认说的是哪一层，否则讨论会退化成立场之争。
它真正决定的事
项目进入长期运营后，最贵的往往不是功能做不出来，而是问题已知却改不动、发不出、止不住损。热更新体系决定了修复窗口有多短、迭代节奏能多快、一次错误变更的影响范围有多大。这也是它总被反复讨论的原因：它是运营期最重要的架构能力之一。
热更和发版的成本结构不同
发版慢，但走完整流程，单个变更成本高、批量摊薄；热更快，但每个变更都要走灰度、验证和回滚，单个成本降不下来。这决定了两者的适用场景：内容型、参数型的高频变化适合热更，结构型的低频变化适合发版。把结构变更也挤进热更，等于用最贵的通道做最危险的事。
热更体系通常由什么组成
- 打包与差量：把变更做成可下发的补丁。
- 签名与校验：确认补丁来源和完整性。
- 分发与灰度：按比例、按机型、按渠道放量。
- 兼容矩阵：脚本版本、宿主版本、配置版本之间的匹配规则。
- 监控与回滚：崩溃率和报错率的观察位，以及一键回退。
这五件缺任何一件，热更通道都算不完整。实际项目里最常见的缺口是兼容矩阵和回滚：前四件都在建，出事时才发现没有退路。
它要放进发布链路里看
热更不是独立开关，而是发布体系的一环。旧客户端拉到新配置、热更脚本跑在未准备好的宿主代码上，这类组合失配是版本事故的高发区，也是版本发布一章反复强调兼容窗口的原因。评估热更方案时，把它当成一条独立的发布管线来看，缺的环节往往立刻显形。
平台和渠道的约束
不同平台对热更的态度差别很大：小游戏平台限制明确，渠道审核对脚本热更的容忍度不同，包体和资源更新还可能受审核窗口约束。热更能力设计如果脱离目标平台的规则，往往在上线前被迫重构，而重构热更体系几乎等于重构发布体系。
回滚和热更本身一样重要
热更通道没有回滚，等于线上变更没有撤销键。常见做法是灰度先行、保留上一版热更包、明确宿主与脚本的版本匹配规则、给热更变更配独立的事故回退预案。评估一个团队的热更能力，看的往往不是“能不能热更”，而是上次热更出问题时多快恢复的。
哪些问题经常靠热更兜底
数值失衡、逻辑 bug、活动开关、紧急止损，是热更最常承接的四类。前两类考验验证流程，后两类考验灰度和回滚。值得警惕的是第五类——新功能也走热更上线，这通常意味着发布管线出了问题，团队在用热更绕开发版流程，事故半径随之失控。
兜底的顺序也有讲究：先止损再修复，先小流量再全量。这两条顺序被打乱，热更的速度优势就会变成风险来源。
热更和灰度的关系
灰度不只是放量，还是热更的验证手段：按机型、按渠道、按在线时长分层放量，观察崩溃和报错，再决定全量。没有分层观察位的热更灰度，本质上还是全量发布，只是分了几天发完。常见做法是给每类热更定观察指标和停留时间，不达标就不进下一批。
常见误区
- 把热更当万能修复通道，任何问题都指望热更，发布纪律随之瓦解。
- 只建热更通道不做兼容矩阵，热更包与宿主版本失配引发批量事故。
- 热更代码不走测试，把生产环境当验证场。
- 忽略平台规则，上线前才发现核心热更能力不可用。
- 有热更没回滚，出问题时只能再热更一次去修上一次的热更。
Used By
热更能力分级；发布链路的热更接入评审；平台约束核对。
Related
关系链：分级 → 决定什么 → 成本结构 → 体系组成 → 发布链路 → 平台约束 → 回滚。上游：glossary/05（哪些变化可热更）。下游：production/02（资源与配置版本）、production/03（回滚）。
Reference
本页为工程经验归纳。