版本刚发出去，半夜被电话叫醒，用户反馈某个页面一打开就闪退。这种场面做过 App 的人大概都见过。改代码、打包、提审、等应用商店过审，快的一两天，慢的一周，问题就一直挂在线上。
热修复要解决的就是这段等待。不重新发版，把修复内容推到已经装好的用户设备上，问题能更快被压住。阿里云的移动热修复服务（很多人直接叫它 Sophix）是这类能力的云端方案，挂在阿里云移动研发平台下面，补丁生成、下发、灰度、效果监控都在同一条链路里。
Android 和 iOS 的差别
两个平台的做法差别不小。Android 端通常是替换有问题的类或方法，运行时加载修复后的代码，不用重新安装应用。补丁一般是差分文件，体积小，下载快，对用户流量和等待时间的影响有限。
iOS 端受应用商店审核政策约束，动态更新能覆盖的范围比 Android 窄很多。立项前先把目标平台的能力边界摸清楚，别把热修复当成万能药。
什么问题适合热修复
逻辑错误、空指针、接口参数处理不当，这类问题最适合。比如某个列表在数据为空时崩溃，补上两行判断就能修好，用热修复很合适。
但新增页面、新增权限、大幅改动原生代码、升级 SDK 版本，这些还是得走正式发版。热修复是给紧急问题争取时间的，不能拿来代替版本迭代。
一个电商 App 的处理过程
假设某电商 App 在大促前一天上线新版本，优惠券结算模块在部分机型上因为一个未判空的字段闪退。两小时后崩溃监控显示大约 3% 的活跃用户受影响，而且集中在下单链路上，损失是实打实的。
团队大致是这样处理的：
- 定位：从崩溃堆栈里找到具体的类和方法，确认是空指针。
- 修复：在对应方法里加判空和默认值，在本地测试机上跑通。
- 生成补丁：把修复后的版本传到阿里云移动热修复控制台，生成差分补丁。
- 灰度：先推给约 5% 的目标用户，看崩溃率和下单功能是否正常。
- 全量：灰度数据稳定后，逐步扩大到所有受影响版本的用户。
从发现问题到全量生效，整个过程花了几个小时。走正式发版的话，大促基本已经结束了。这是热修复最直接的价值。
接入和使用时的几个坑
- 先灰度，别一步到全量。补丁本身也可能出错，分批看数据，出了问题影响面小。
- 提前准备回滚。补丁一旦带来新问题，要能快速撤回，让用户回到原始代码状态。回滚路径最好在上线前就演练过。
- 和崩溃监控联动。热修复效果只能靠数据判断，崩溃率、补丁覆盖率要持续盯着，不能推完就不管。
- 一个补丁只修一件事。多个改动混在一起，出问题时很难排查是哪一处引起的。
- 留意应用商店规则。动态更新要符合各商店的相关规定，别借这个通道改核心业务逻辑之外的东西。
团队怎么定规矩
第一次接热修复的团队，常见的问题是两头摇摆：要么完全不敢用，要么什么问题都想靠补丁解决。比较稳的做法是先把规则写下来。哪些级别的问题允许走热修复，哪些必须正式发版；补丁上线前要过哪些测试；灰度比例和观察时长是多少。规则写清楚，线上出事的时候才不会乱。
每次热修复结束后，花十几分钟做个简短复盘就够了，记下根因、补丁效果和改进点。坚持一段时间，团队对线上风险的判断会准很多。
选型时看什么
对比方案时可以看几件事：支持的平台是否覆盖你们实际用到的端，补丁体积和下发速度怎么样，有没有灰度、回滚和效果统计，能不能顺畅接进现有的研发工具链。阿里云这套在功能完整度上比较均衡，特别适合已经在用阿里云移动研发平台，或者本身有云上基础的团队。具体功能细节和价格，以官方文档和控制台说明为准，别只看别人的经验分享。
热修复终究是应急和补充手段。真正降低线上风险，还是靠测试、代码审查和发布流程本身做好。放进这套体系里，它才发挥得出作用。
