热修复流程是什么
热修复（Hotfix）指线上问题紧急修复后快速发版的受控流程：从发布分支切出热修分支、最小化改动、经过快速验证、发布并回合并到主干与后续版本。它的核心矛盾是速度与安全：流程要压缩但不能消失。热修复走后不补记录、不回合并，等于给未来版本埋雷。
基本信息
| 触发条件 | 线上严重故障、数据错误、安全漏洞等止损类问题 |
|---|---|
| 分支策略 | 从当前线上版本分支切出 hotfix 分支，改完先回线上再合并主干 |
| 改动原则 | 最小改动，只碰问题相关代码，不带任何顺手优化 |
| 验证要求 | 围绕缺陷点的定向验证加关键路径冒烟，不可完全免测 |
| 发布要求 | 固定版本号、留发布记录、有回滚方案 |
| 收尾动作 | 回合并到主干、补正式缺陷记录、安排事后复盘 |
分支流转示意
分支流转示意
git checkout -b hotfix/order-timeout release/v2.3 # 从线上分支切出
# 最小改动 + 定向验证 + 代码评审快速通道
git commit -m 'fix: order timeout on large cart' # 提交修复
git tag v2.3.1 && 走紧急发布通道 # 先救线上
git checkout main && git merge hotfix/order-timeout # 回合并主干
git checkout release/v2.3 && git merge hotfix/order-timeout # 同步发布分支
# 补缺陷记录与复盘，标记热修复来源典型使用场景
- 线上阻塞故障：核心功能不可用，等待正常排期损失不可接受。
- 数据修正：错误数据持续产生，需要代码级修复先止损。
- 安全漏洞：在野利用风险高，必须尽快打补丁。
- 资损问题：金额计算错误，每多运行一小时损失都在扩大。
- 合规时限：监管或合同要求限时修复的缺陷。
热修复不是省略测试：验证范围可以缩但必须定向覆盖缺陷点与周边关键路径。
热修不回合并是最常见的债：下个版本把修复覆盖掉，故障原地复发。
每次热修后要复盘：为什么常规测试没拦住，把结论落进用例或检查清单。