1. 从一次OTA包体优化说起：BSDiff到底解决什么问题

增量更新这四个字，在移动端、桌面软件、车载系统、游戏客户端的升级链路里几乎绕不开；而只要聊到二进制增量，BSDiff算法就一定会被拿出来。原因很直接：它不依赖源码，不需要你理解文件格式，给我一个旧版本文件和一个新版本文件，它就能算出一个补丁，客户端拿着旧文件和补丁，通过bspatch还原出新文件。这个能力听起来简单，放在真实业务里却非常值钱。一个安装包从120MB涨到122MB，如果每次全量下发，用户要重新下载122MB，CDN要重新扛122MB，弱网用户可能直接放弃升级；而增量更新只下发几MB甚至几百KB的补丁，用户下载快，服务端带宽省，升级成功率也更高。BSDiff就是这条链路里最经典的差分算法之一，它适合谁？适合做客户端升级、嵌入式固件更新、游戏资源热更、桌面软件自动更新的工程师，也适合想理解二进制差分底层原理的学生和爱好者。下面我不打算只贴一段“算法定义”，而是把它为什么出现、怎么算、怎么用、哪里会踩坑，一次讲透。

1.1 增量更新不是“压缩包”那么简单

很多人第一次听到增量更新，会把它和压缩混在一起：反正都是让下载变小，用zip压一下不就行了？这其实是两件事。压缩解决的是“同一个文件内部有重复信息”，比如文本里重复单词、二进制里大量零字节，压缩算法利用这些冗余把体积降下来。增量更新解决的是“新文件和旧文件之间有很多相同内容”，它只传输变化的部分。举一个很直观的例子：旧版本安装包100MB，新版本只改了一个图片、一个配置文件和一段代码，全量压缩后可能还是接近100MB，因为安装包本身已经被压缩过；但BSDiff拿旧包和新包一比，发现90%以上的字节都没变，于是只输出那些变化块和匹配关系，补丁可能只有2MB到5MB。客户端不需要重新下载整个新包，只需要旧包加补丁，在本地执行bspatch，最终得到完整的新包。

这也是增量更新的核心前提：用户手里必须已经有旧版本文件。首次安装、清理过数据、旧文件损坏、版本跨度过大，增量更新都不适用，或者效果很差。所以真正常见的做法是“全量兜底，增量优先”：服务端根据用户当前版本下发对应补丁，能打上就打补丁，打不上就回退到全量下载。听起来多了一层逻辑，但节省的带宽和提升的升级率通常远超这点复杂度。

1.2 为什么老设备上全量升级越来越痛

早些年App只有几十MB，全量下载还能忍。现在动辄几百MB，游戏包甚至几个GB，问题就出来了。第一是流量成本，用户用移动网络下载大包，心理负担很重，尤其是非WiFi环境；第二是服务端带宽成本，每次发版都像一次洪峰，CDN账单不会说谎；第三是下载时长，弱网下全量包可能下载十几分钟，期间切后台、断网、存储不足都会导致失败；第四是存储压力，下载新包时旧包还在，解压安装又需要额外空间，低端机很容易爆存储。增量更新的价值就在这里：补丁小，下载快，失败重试成本低，用户升级意愿也更高。

但增量更新不是没有代价。服务端要维护旧版本样本，要为多个旧版本生成多个补丁，补丁生成本身要消耗CPU和内存；客户端要执行bspatch，需要额外存储空间和一定的CPU时间。如果算法选得不对，或者文件本身已经被高压缩、强加密，补丁可能并不小。BSDiff之所以仍然被大量项目参考，是因为它在通用二进制文件上表现稳定，而且实现思路清晰，几十年来被反复验证。它不追求所有场景最优，但在“旧文件和新文件整体相似、局部变化”的场景里，它是一把很扎实的刀。

1.3 BSDiff在增量更新链条里的位置

一个完整的增量更新系统通常包含这些环节：版本管理、差分包生成、补丁签名、CDN分发、客户端下载、补丁校验、bspatch合并、新文件校验、安装或替换、失败回滚。BSDiff只负责其中“差分生成”，bspatch负责“补丁合并”。它不是版本管理，也不是下载框架，更不是安装器。很多新手会误以为用了BSDiff就自动有了增量更新，其实还差得远。你需要知道哪个旧版本对应哪个补丁，补丁必须和旧文件严格匹配，合并后的新文件必须做哈希校验，否则一个字节错误就可能导致安装失败甚至更隐蔽的问题。

从工程角度看，BSDiff最适合放在服务端生成补丁，因为它的差分过程比较吃内存和时间；客户端只保留bspatch，因为bspatch逻辑简单、内存占用相对可控。这个分工很关键。移动端设备型号复杂，低端机内存小，如果让客户端做BSDiff差分，体验会很差；服务端机器资源充足，可以并行、排队、缓存。理解了这个位置，后面再看算法原理，就不会把“差分”和“合并”混为一谈。

2. BSDiff算法溯源：从二进制差异到后缀排序

BSDiff不是凭空冒出来的。它诞生于本世纪初，作者Colin Percival在2003年前后发布了这个算法和工具，最初是为了解决BSD系统更新包过大的问题。那个年代网络带宽有限，系统更新却越来越频繁，全量分发压力很大。BSDiff的核心贡献不是发明了“找相同块”这件事，而是用后缀数组把“在旧文件里找最长匹配”这件事做得足够快，同时设计了一套简单可解码的补丁格式。它的论文和源码都不长，但思想很浓缩。要真正理解它，得先明白二进制diff和文本diff完全不是一回事，然后才能理解为什么后缀数组会成为核心。

2.1 二进制diff与文本diff的根本差异

文本diff工具，比如我们熟悉的diff、git diff，通常按行比较。文本有换行符，行是天然的分割单位，算法可以先找相同行，再处理行内变化。二进制文件没有“行”这个概念，一个可执行文件、一张图片、一个压缩包，都是连续的字节流。你无法说“这一行变了”，只能说“从第N个字节开始，有K个字节不同”。更麻烦的是插入和删除：如果在文件开头插入一个字节，后面所有字节的偏移都变了，逐字节比较会认为后面全变了，但实际上只是错位。二进制差分必须能识别“错位后的相同内容”，也就是在旧文件里找到和新文件某段相同的子串。

这就是BSDiff要解决的问题：给定旧文件，快速找到新文件中每一段在旧文件中的最长匹配。找到匹配后，新文件这段就可以用“旧文件偏移+长度+差值”表示；找不到匹配的部分，就作为额外数据直接写入补丁。文本diff可以靠行号快速定位，二进制diff需要更底层的数据结构，后缀数组就是为此服务的。

2.2 BSDiff的论文思路与历史脉络

BSDiff的论文标题很直白，核心思路可以概括成三步：第一，对旧文件的所有后缀排序，构建后缀数组；第二，扫描新文件，在旧文件后缀数组中二分查找最长匹配；第三，把匹配部分编码成差值，把不匹配部分编码成额外数据，最后用bzip2压缩整个补丁。这个思路在当年并不算全新，后缀数组在字符串处理领域已经成熟，但把后缀数组用于二进制差分，并且做成可用的开源工具，BSDiff是很有代表性的一步。

后来，BSDiff被广泛用于各种系统的增量更新。Android早期OTA、Chrome组件更新、游戏热更、嵌入式固件升级里都能看到它的影子或变体。也有不少改进版本出现，比如用更省内存的后缀数组构建算法、用更快的压缩库替换bzip2、用HDiffPatch等更现代的差分工具。但无论怎么改，核心问题没变：怎么在可接受的时间和内存里，找到旧文件和新文件之间的匹配关系。理解了这一点，再看那些变体，就不容易被名词吓住。

2.3 核心数据结构：后缀数组与匹配前缀

后缀数组是什么？假设旧文件内容是“banana”，它的所有后缀是“banana”、“anana”、“nana”、“ana”、“na”、“a”。把这些后缀按字典序排序，得到“a”、“ana”、“anana”、“banana”、“na”、“nana”，记录它们在原字符串中的起始位置，就得到后缀数组。BSDiff用的旧文件是二进制字节流，把每个字节当作字符，同样可以构建后缀数组。后缀数组本身只存整数索引，不存字符串，所以空间可控。有了它，查找某个子串是否出现在旧文件中，就可以通过二分查找快速定位。

匹配前缀是另一个关键概念。当我们想在旧文件里找新文件当前位置开始的最长匹配时，可以在后缀数组里二分查找，找到最接近的前后后缀，然后计算它们与新文件子串的公共前缀长度。公共前缀越长，说明匹配越好。BSDiff会选最长匹配，如果匹配长度超过一定阈值，就用差值编码；如果太短，就不值得引用，直接作为额外数据。这个阈值不是固定魔法数，而是和补丁体积、解码速度有关的工程取舍。

2.4 为什么用后缀排序而不是逐字节比较

最笨的二进制差分方法是：对新文件每个位置，去旧文件每个位置试一遍，看能匹配多长。这个复杂度是O(N*M)，旧文件100MB、新文件100MB，就是一万亿次级别的比较，完全不现实。后缀数组把“查找子串”从线性扫描变成二分查找，构建一次可以反复查询，整体复杂度大幅下降。原版BSDiff使用的qsufsort后缀排序算法，在当年是很高效的选择；虽然后续有SA-IS等更优算法，但BSDiff的实现已经足够经典。

用空间换时间是这里的核心逻辑。后缀数组需要为旧文件每个字节保存一个索引，如果索引是4字节整数，100MB旧文件就需要约400MB，再加上构建过程中的辅助数组、文件缓存、压缩缓冲，内存占用会更高。所以BSDiff通常跑在服务端，而不是客户端。移动端只跑bspatch，因为bspatch不需要后缀数组，只需要按补丁指令读写文件，内存占用小得多。这个分工不是随便定的，而是被算法特性逼出来的。

3. BSDiff原理解析：从旧包到新包，补丁是怎么算出来的

理解BSDiff，最好把“差分”和“合并”两条线分开看。差分是bsdiff程序做的事：输入旧文件和新文件，输出补丁。合并是bspatch程序做的事：输入旧文件和补丁，输出新文件。补丁格式是两者之间的契约。很多人只记住“BSDiff用后缀数组”，但真正写代码或排查问题时，补丁格式才是最重要的。下面从差分侧开始，把后缀数组构建、匹配扫描、差异编码讲清楚，再看bspatch怎么还原。

3.1 扫描旧文件构建后缀数组

bsdiff启动后，第一件大事是把旧文件全部读入内存，然后构建后缀数组。旧文件的每个位置i都对应一个后缀，即从i到文件末尾的字节序列。后缀数组I就是这些后缀按字典序排序后的起始位置列表。构建过程通常用qsufsort，它通过不断分组和排序，把后缀按前缀逐步区分开。这个阶段是CPU和内存消耗的大头，旧文件越大，构建越慢，内存越高。

这里有一个容易被忽略的细节：旧文件是二进制，字节值范围0到255，排序时按无符号字节比较。实现里会用int数组存索引，用额外数组存排名和临时数据。构建完成后，bsdiff就有了一个“旧文件全文索引”。后面每在新文件中找到一个片段，都可以通过这个索引快速知道它在旧文件里出现过没有、出现在哪里、最长能匹配多长。你可以把它想象成一本字典的目录，只不过这个目录不是按单词排，而是按字节后缀排。

3.2 对新文件分段匹配与扩展

有了后缀数组，bsdiff开始扫描新文件。扫描不是逐字节死板前进，而是尽可能找到最长匹配。对于新文件当前位置，它在后缀数组里做二分查找，找到旧文件中与当前子串最接近的后缀，然后计算公共前缀长度。如果匹配长度大于0，就记录一个匹配块：旧文件偏移、匹配长度、新旧字节差值。然后新文件位置向前跳过这个匹配长度。如果没有匹配，或者匹配太短，就把当前字节作为额外数据输出，位置前进一字节或一小段。

实际实现里，bsdiff还会做“向前扩展”和“向后扩展”的优化，尽量把匹配拉长，减少控制块数量。匹配块之间可以有重叠，也可以跳过旧文件的某些区域。补丁最终由很多“引用旧文件+差值”和“直接写新数据”的片段组成。匹配质量越高，差值块和额外块越少，补丁越小。如果新旧文件差异巨大，匹配很少，补丁就会接近新文件大小，增量更新也就失去意义。

3.3 生成差异序列：控制字节、差值、额外数据

BSDiff补丁文件有一个固定头部，开头是魔术字节“BSDIFF40”，然后是三个长度字段：控制块压缩后长度、差值块压缩后长度、新文件大小。头部之后是三段数据：控制块、差值块、额外数据块。控制块里是一组组三元组，每个三元组包含三个整数：x、y、z。x表示从旧文件读取多少字节参与差值计算，y表示差值块中读取多少字节，z表示额外数据块中读取多少字节直接写入新文件。差值块里的每个字节，通常等于新文件字节减去旧文件字节，按256取模；额外数据块则直接保存新文件中无法匹配的字节。

补丁生成时，bsdiff会把控制块、差值块、额外数据块分别收集起来，然后用bzip2压缩。注意，压缩的是这三段，而不是整个文件简单压一遍。这样做的好处是解码时可以先解压控制块，按控制指令逐步解压差值块和额外数据块，不需要一次性解开所有数据。补丁格式设计得比较紧凑，但也带来一个问题：如果补丁损坏，bspatch可能在中途失败，所以下载后必须做完整性校验。

3.4 bspatch还原新文件的解码流程

bspatch的流程比bsdiff简单很多。它先读取补丁头部，确认“BSDIFF40”魔术字，然后读取三个长度和新文件大小。接着打开旧文件，准备一个新文件输出流。它会解压控制块，然后循环读取三元组。对于每个三元组，它先根据x从旧文件读取一段数据，同时从差值块读取y字节，把两者逐字节相加，写入新文件；然后从额外数据块读取z字节，直接写入新文件。旧文件读取位置会根据x调整，x可以是负数，表示向前回退，这样补丁可以引用旧文件中已经读过的区域。

这里有几个关键点。第一，差值计算是模256的，写入时按字节处理，不需要考虑符号。第二，旧文件必须和生成补丁时使用的旧文件完全一致，差一个字节都可能导致还原失败或结果错误。第三，bspatch需要同时打开旧文件、补丁文件和新文件，所以磁盘空间要留够。第四，补丁中的新文件大小是校验依据之一，还原完成后要检查输出大小是否一致，最好再用SHA-256或MD5校验最终文件。很多增量更新事故不是算法错，而是校验缺失，导致坏包被安装。

4. 动手实现与参数调优：一个可复现的BSDiff实操路径

理论讲完，得落到能跑的命令上。原版BSDiff工具在Linux、macOS、Windows上都有移植版本，最常用的是C语言版本，依赖bzip2。很多发行版仓库里直接有bsdiff和bspatch包，但版本可能不同，补丁格式未必完全兼容。如果你要用于生产，最好固定源码版本，自己编译，自己控制压缩库和构建参数。下面给出一条从编译到验证的完整路径，尽量让你能直接复现。

4.1 环境准备与工具选型

先明确工具选型。原版BSDiff适合通用二进制差分，优点是成熟、资料多、格式简单；缺点是内存占用高、差分速度一般、只支持bzip2。xdelta3更偏向通用差分，支持多种压缩和流式处理；HDiffPatch在现代项目里更常见，内存和速度优化更好，支持大文件和多种压缩；Courgette是Chrome用的方案，针对可执行文件做反汇编再差分，适合代码段变化。选哪个取决于你的文件类型和资源限制。如果是APK、固件、资源包，且服务端资源充足，BSDiff仍然可以作为基线方案。

环境上，你需要一台Linux机器，安装gcc、make、bzip2开发库。Debian/Ubuntu可以装build-essential和libbz2-dev。源码可以从公开仓库获取，注意选择稳定版本。编译前看一眼Makefile，确认优化级别和链接库。生产环境建议用-O2或-O3，并固定编译器版本，避免不同环境生成行为差异。如果要做自动化，可以把bsdiff和bspatch封装成命令行工具，由任务系统调用。

4.2 编译与基础命令

假设你已经拿到bsdiff和bspatch的源码文件，编译命令通常是这样：

gcc -O3 -o bsdiff bsdiff.c -lbz2 gcc -O3 -o bspatch bspatch.c -lbz2

如果源码分多个文件，就用Makefile或把相关.c文件一起编译。编译完成后，先做一次小文件测试。准备两个版本文件old.bin和new.bin，生成补丁：

./bsdiff old.bin new.bin patch.bin

然后用旧文件和补丁还原：

./bspatch old.bin new_out.bin patch.bin

最后比较new.bin和new_out.bin：

sha256sum new.bin new_out.bin

两个哈希一致，说明补丁可用。这个流程看起来简单，但生产环境要注意文件路径、权限、磁盘空间和并发。建议把补丁生成放在独立工作目录，避免多个任务互相覆盖；补丁文件名带上旧版本号和新版本号，方便追踪；生成后立即记录补丁大小、旧文件哈希、新文件哈希，作为元数据入库。

4.3 差分参数与内存占用计算

原版bsdiff几乎没有可调参数，这是优点也是缺点。优点是行为稳定，缺点是面对大文件时不够灵活。它内部的压缩级别、后缀数组构建方式、匹配阈值都写在代码里。你能调的主要是编译优化、bzip2版本、系统内存和并发度。内存占用怎么估算？假设旧文件大小为N字节，后缀数组通常需要4N字节，构建过程中还会有辅助数组，可能再增加几N；加上旧文件本身、新文件读取缓冲、压缩缓冲，粗略估计峰值可能是旧文件大小的10到20倍。也就是说，100MB旧文件，峰值内存可能到1GB到2GB；500MB旧文件，服务端单机跑多个任务就很容易OOM。

时间上，后缀数组构建和后缀查找是主要成本。旧文件越大，构建越慢；新文件越大，扫描和匹配次数越多。实际测试中，100MB对100MB的文件，bsdiff可能几十秒到几分钟，具体看CPU和磁盘。补丁大小则取决于相似度。如果新旧文件90%以上相同，补丁可能只有原文件的百分之几；如果只有50%相同，补丁可能接近新文件的一半。压缩级别越高，补丁越小，但生成越慢。生产环境要权衡：补丁生成可以离线做，慢一点没关系；客户端下载补丁，越小越好。

4.4 验证补丁正确性与回滚方案

补丁生成后，不能只看文件存在就算完。必须做三层验证。第一层，用同一份旧文件和补丁执行bspatch，比较输出和新文件的哈希。第二层，故意用错误的旧文件执行一次，确认会失败或输出错误哈希，避免校验逻辑形同虚设。第三层，在目标设备或模拟环境上测试，确认磁盘空间、权限、路径、签名校验都没问题。增量更新最怕“服务端生成成功，客户端合并失败”，所以客户端侧必须保留完整日志，记录旧文件哈希、补丁哈希、输出哈希和错误码。

回滚方案也要提前设计。补丁合并失败时，不能把旧文件删掉再下载，否则用户可能既没有旧文件也没有新文件。正确做法是先把新文件写到临时路径，校验通过后再原子替换；失败就删除临时文件，保留旧文件，回退全量下载。如果全量下载也失败，至少应用还能用旧版本启动。这个顺序听起来保守，但能避免大量“升级后打不开”的投诉。

5. 常见问题与排查技巧实录

BSDiff用起来不难，难在排查问题。增量更新链路长，服务端、CDN、客户端、存储、权限任何一环出问题，表现都可能是“补丁打不上”。下面整理几类最常见的问题，都是我实际踩过或帮别人看过的坑。每类问题先讲现象，再讲原因，最后给排查动作。你可以把它当成速查表，但不要只背结论，理解原因才能举一反三。

5.1 补丁体积异常：为什么没有变小

最常见的问题是：生成了补丁，但补丁几乎和新文件一样大，增量更新没省多少。原因通常有三类。第一，新旧文件差异本身很大，比如换了整套资源、改了压缩参数、重新打包导致大量字节偏移。第二，文件已经被高度压缩或加密，BSDiff在压缩后的字节流上找匹配，差一个字节就可能让后续所有字节错位，匹配率极低。第三，打包过程不可复现，同样的源码每次编译出的二进制都不同，导致旧包和新包看起来完全不同。APK就是典型例子，zip压缩、对齐、签名都会影响字节布局。

解决思路是“先归一化，再差分”。对于APK，可以按zip条目逐个解压，对未压缩资源做文件级差分，对已压缩资源先解压再差分，最后重新压缩打包；对于固件，可以固定编译工具链、编译时间、路径、签名顺序，让构建可复现；对于资源包，可以保持压缩参数一致，避免无意义字节变化。表5-1给一个简单对照。

5.2 内存溢出与超时：后缀数组的代价

第二个高频问题是服务端生成补丁时OOM或超时。前面算过，BSDiff峰值内存可能是旧文件的10到20倍。如果你在容器里只给2GB内存，却要处理500MB的旧文件，基本一定失败。表现可能是进程被kill、报Cannot allocate memory、任务卡死不动。排查时先看旧文件大小，再估内存，再看同时跑了几个任务。很多团队一开始并发开太高，十个大文件一起差分，机器直接崩。

处理办法有几个。第一，限制并发，大文件任务串行或单独队列。第二，升级机器内存，或者用内存更省的差分工具，比如HDiffPatch。第三，如果业务允许，按模块拆分文件，分别生成补丁，客户端分别合并。第四，设置超时和重试，失败任务不要无限挂起。第五，监控补丁生成耗时和峰值内存，建立基线，超过阈值告警。注意，bspatch客户端侧也要留足磁盘空间，虽然内存占用小，但需要同时存在旧文件、补丁和新文件。

5.3 bspatch失败：版本错配与校验缺失

客户端bspatch失败，日志里常见错误是“corrupt patch”“old file mismatch”“write error”。第一类原因是旧文件不匹配。用户可能安装过修改版、旧文件被清理工具改过、上次更新失败留下半截文件。第二类原因是补丁损坏。下载中断、CDN缓存了旧补丁、存储坏块都会导致补丁字节变化。第三类原因是磁盘空间不足或权限不够。第四类原因是补丁和新版本不匹配，比如服务端配置错了版本映射。

排查时按这个顺序：先核对旧文件哈希是否等于生成补丁时记录的旧文件哈希；再核对补丁哈希是否等于服务端发布的哈希；再看磁盘剩余空间是否大于新文件大小加临时空间；最后看bspatch返回码和日志。表5-2可以作为客户端自检清单。

5.4 增量更新链路中的安全与兼容性检查

增量更新不只是算法问题，还是安全问题。补丁从服务端到客户端，中间要经过网络、CDN、本地存储，任何一个环节被篡改，都可能让客户端合并出错误文件。所以补丁必须签名，客户端必须验签；补丁清单要带旧版本、新版本、文件哈希、补丁哈希、文件大小；下载要用HTTPS，本地写入要原子操作。兼容性方面，要处理旧文件缺失、存储权限、系统版本差异、CPU架构差异。比如某些设备不支持大文件映射，某些系统对临时目录有限制，这些都要在灰度阶段验证。

我的经验是：不要假设用户环境是干净的。旧文件可能被用户手动改过，可能被安全软件锁定，可能因为上次升级失败处于中间状态。客户端在执行bspatch前，先做一轮轻量校验，失败就直接走全量，不要把用户卡在错误页面。同时，服务端要保留全量包作为兜底，并且全量包的下载地址要稳定可用。增量更新是优化手段，不是唯一路径。

6. 进阶优化与适用边界：BSDiff不是万能钥匙

BSDiff很经典，但工程上不能迷信。它的优势是通用、成熟、格式简单；劣势是内存高、速度一般、对已压缩数据不友好。实际项目里，我通常先把BSDiff当基线，测一轮补丁大小和生成耗时，再决定是否换更现代的方案。下面从工具对比、压缩选择、适用场景和后续扩展四个角度，把边界讲清楚。你不需要记住所有工具，但要知道什么时候该换刀。

6.1 与xdelta、HDiffPatch、Courgette的简单对比

xdelta3是老牌差分工具，支持流式处理和多种压缩，适合大文件和网络传输；HDiffPatch在内存和速度上优化明显，支持大文件、多线程、多种压缩，近年来在很多游戏和客户端项目里替代了BSDiff；Courgette针对可执行文件，先反汇编再差分，能处理代码地址变化，但通用性差。BSDiff的优势是简单、资料多、二进制格式容易理解，适合做教学和中小规模增量更新。表6-1给一个粗略对比。

6.2 压缩算法叠加：bzip2还是zstd

原版BSDiff用bzip2压缩控制块、差值块和额外数据块。bzip2压缩率不错，但速度慢，尤其是解压时在低端设备上可能成为瓶颈。很多改进版把bzip2换成zstd或lzma。zstd解压速度快，压缩率接近bzip2，适合客户端；lzma压缩率更高，但解压更慢。换压缩算法不是简单改一行代码，因为补丁格式要两端一致，头部长度字段、压缩块边界都要对应。如果你自己维护补丁格式，可以把压缩算法做成可扩展字段，服务端和客户端按版本协商。

我的建议是：如果客户端性能紧张，优先考虑zstd；如果补丁大小极度敏感，且客户端能接受解压耗时，可以考虑lzma；如果只是做实验或兼容老工具，保持bzip2最省事。无论选哪种，都要在真实低端机上测解压时间和内存，不要只看服务端测试结果。

6.3 什么场景适合BSDiff，什么场景别硬上

适合BSDiff的场景有几个共同点：新旧文件整体相似，变化集中；文件没有被强压缩或加密，或者可以先解压；差分在服务端做，客户端只合并；版本跨度不大，旧文件可稳定获取。比如固件小版本升级、桌面软件补丁、游戏资源包局部更新、文档二进制格式微调。这些场景下，BSDiff能明显降低下载体积，而且实现成本可控。

不适合硬上的场景也很明确：首次安装、旧文件不可靠、版本跨度过大、文件已经高压缩且无法解压、客户端内存极小、需要实时差分。还有些场景虽然能算出补丁，但补丁并不小，比如换了整套图片资源、重新打包导致大量偏移、加密文件每次密钥不同。这时候不如直接全量，或者改用文件级差分、资源级差分。算法是工具，不是信仰。

6.4 后续扩展：多版本补丁与差分服务化

真实业务里，用户不会只停留在一个旧版本。你可能要面对几十个历史版本，每个版本都要能升级到最新版。最直接的做法是为每个旧版本生成一个到新版本的补丁，形成补丁矩阵。版本多了以后，存储和生成任务会膨胀，所以要做策略：只保留最近几个版本，老版本强制全量；热门版本优先预生成；补丁按旧版本、新版本、平台、架构建索引；CDN缓存热点补丁；任务队列按文件大小和优先级调度。差分服务化之后，bsdiff只是其中一个worker，外面还要有元数据管理、签名服务、监控告警和回滚开关。

我自己在实际项目里的体会是，增量更新最值钱的部分不是算法本身，而是那套围绕算法的工程保障：旧文件校验、补丁签名、失败回退、灰度发布、数据监控。BSDiff帮你省带宽，但只有把校验和回滚做扎实，才敢真正放到线上。否则补丁越小，出事时越难查。