3、升级包制作与管理：升级包格式（差分包/全量包）、包签名与加密、版本号管理策略

好，咱们接着聊升级包。这部分内容，说白了就是「怎么把代码打包好，安全地送到车上」。我见过不少团队，代码写得漂亮，结果升级包管理一塌糊涂，最后车机变砖。嗯，这里头门道不少。

3.1 升级包格式：全量包 vs 差分包

先说说最基础的选择。你想想看，一辆车可能有几十个 ECU，每个都要升级。如果每次都发全量包，那流量成本可吃不消。但差分包也不是万能的。

全量包

全量包就是完整的固件镜像。我个人的习惯是，在新车首次升级或者跨大版本升级时，必须用全量包。为什么？因为这时候系统变化太大，差分算法容易出错。

差分包

差分包只记录新旧版本之间的差异。我在项目中遇到过，有一次用 bsdiff 算法做差分，把 1.2GB 的全量包压缩到了 80MB。效果确实惊人。

但要注意，差分算法对内存有要求。我曾经在某个低端 MCU 上跑差分还原，结果内存爆了。所以，差分包的还原过程必须在资源充足的条件下进行。

3.2 包签名与加密：安全是底线

升级包如果不加密不签名，那等于把车钥匙挂在门外。我记得有一次帮客户做安全审计，发现他们的升级包居然是用明文传输的。嗯，这要是被中间人攻击，后果不堪设想。

签名机制

签名是为了验证「这个包是谁发的」以及「包有没有被篡改」。常用的做法是：

# 签名流程（以 RSA 为例）
1. 生成密钥对：私钥（车厂保留），公钥（预置在车机）
2. 对升级包的哈希值用私钥加密 → 得到签名
3. 车机收到包后，用公钥解密签名，比对哈希值

加密机制

加密是为了防止升级包被窃取或逆向分析。我建议使用 AES-256 对称加密，密钥通过非对称加密传输。

安全层级	推荐算法	用途
签名	RSA-2048 / ECDSA	验证完整性、来源
加密	AES-256-GCM	保护包内容
哈希	SHA-256	校验数据一致性

3.3 版本号管理策略

版本号看似简单，但搞砸了会出大问题。我见过一个案例：因为版本号没管理好，导致车机误判「当前版本比新版本还新」，拒绝升级。你说冤不冤？

语义化版本号

我强烈推荐使用语义化版本号（SemVer）：主版本.次版本.修订号。

• 主版本：不兼容的 API 修改，或重大架构变更
• 次版本：向下兼容的功能新增
• 修订号：向下兼容的问题修正

举个例子：v2.3.1 → v2.4.0 表示新增了功能，但兼容旧版。v2.4.0 → v3.0.0 表示有破坏性变更。

版本号比较规则

车机端必须能正确比较版本号。我建议用整数比较，而不是字符串比较。为什么？因为字符串比较会把 "v2.10.0" 判为小于 "v2.9.0"（因为 "1" < "9"）。

// 正确的版本号比较（伪代码）
function compareVersion(v1, v2) {
    parts1 = v1.split('.')
    parts2 = v2.split('.')
    for i in 0..2 {
        if int(parts1[i]) > int(parts2[i]) return 1
        if int(parts1[i]) < int(parts2[i]) return -1
    }
    return 0
}

版本号与升级策略

版本号还决定了升级路径。我建议遵循以下原则：

1. 禁止降级：除非有特殊的安全补丁需求
2. 允许跨版本升级：但必须经过充分测试
3. 版本号单调递增：不能出现 v2.0.0 → v1.9.0 的情况

3.4 升级包管理流程总结

好了，咱们把这一章的核心点串一下。升级包管理，说白了就是三件事：

• 格式选对：小版本用差分，大版本用全量
• 安全做足：签名防篡改，加密防泄露
• 版本管好：语义化版本，单调递增，禁止降级

你想想看，如果这三件事都做好了，升级成功率至少能提升 30%。我见过太多团队，代码写得漂亮，结果在升级包管理上栽跟头。嗯，希望你能少走这些弯路。