先说个我遇到过不止一次的场景：一个六七 G 的素材包要发给合作方，邮件收不了，临时建个传输入口对方又嫌麻烦，事情就卡在那里。真正把问题解开的不是去找更快的通道，而是把这一坨东西切成几个能各自独立传过去的小块——这就是RAR 分卷压缩最朴素的用途。它不新鲜，也不是什么高级技巧，但每次到"文件太大传不动"的时候，能想起来用它、并且参数填对的人，其实没那么多。

很多人第一次听说分卷压缩，脑子里浮现的是"把文件切成几段"，跟剪视频差不多。这两件事差别很大。剪开的视频要按顺序严丝合缝拼回去，少一段就废了；而分卷压缩出来的每一个卷都是压缩包的一部分，卷齐了解压时它会自己按顺序接上，还原成和原始文件一模一样的东西，中间不用你手动拼接、不用担心顺序搞错。代价也很明确：少任何一个卷，整个包就打不开。

这篇写的是我在实际项目里反复用过的一套RAR 分卷压缩技巧，从"卷大小该填多少"这种最容易被拍脑袋决定的参数，到命令行批量处理，再到卷出问题时的排查顺序。零基础能照着做，用过几次的人大概率也能从里面挑出一两个以前没注意的点。全文不需要你懂压缩算法，但我会把几个关键参数背后的道理讲清楚——不知道道理，参数就只能靠一次次试。

1. 分卷压缩真正在解决的问题，以及它解决不了的部分

1.1 三种最典型的"传不过去"场景

第一种是单文件体积上限，而且这个限制藏得很深，很多人第一反应是网络问题，其实是下游根本不接收。最典型的是 FAT32 文件系统，单个文件最大 4294967295 字节，也就是 4GB 减 1 字节，多一个字节都写不进去。老 U 盘、车载记录仪、部分相机的存储卡、不少嵌入式设备，出厂就是这个格式。你把一个 5GB 的包往里拖，系统直接弹"文件过大无法复制"，连进度条都不给你看。

第二种是邮件和部分传输通道的附件限制。多数邮件服务的单封附件总量在几十 MB 这个量级，超过就退信。企业内部的一些传输系统也卡在类似的阈值上。

第三种是断点续传的代价。一个 8GB 的文件传到九成断了，很多工具要从头再来。切成 8 个 1GB 的卷，坏哪卷重传哪卷，代价小一个数量级。这个理由在网速不稳的环境里特别实际，我在外地用临时网络传东西的时候基本都靠这一招。

1.2 分卷和物理切割的本质区别

理解这一点，后面所有参数选择都会变得顺理成章。分卷压缩是把压缩数据流按固定大小切断，每一卷开头都有自己的结构信息——卷头、卷号、校验值。解压时程序读第一卷的头，知道总共有多少卷、每卷多大、下一卷叫什么名字，然后一路读下去，把数据流重新接成一整条，再交给解压引擎。整个过程对用户是透明的，你只需要指定第一卷。

生活里最接近的类比是一套分册出版的书。每册有独立的封面和页码，缺了第二册你读不完整，但第一册和第三册本身不会因此变成废纸——你可以翻开、可以看目录、可以确认它没被水泡过。而把一张纸剪成三段，拼不齐就是三片废纸，没有任何自我描述能力。这个区别决定了分卷压缩的两个特性：可校验和强依赖。每一卷都能单独验证完整性，但少一卷就解不出完整结果。

1.3 什么情况下用分卷反而是自找麻烦

分卷不是万能钥匙，有几个场景我劝你别用。第一种是"我只想从大包里单独拿一个文件出来"——分成二十卷之后，为了取一个几十 MB 的文件，你得先集齐所有卷。这种情况用普通压缩包加目录结构更合适。

第二种是包里的文件需要频繁增删改。分卷包没法像普通压缩包那样追加更新，改一个文件往往要整个重做一遍。

第三种是包里全是已经压过的媒体文件——视频、照片、音频、安装包。这些东西熵已经很高了，再压一遍可能只小 1% 到 3%，白花时间。这种场景下如果只是想过体积限制，用"存储"模式（不压缩，只打包分卷）反而更快更稳，后面会讲具体怎么设。

2. 卷大小到底填多少：一个不该拍脑袋的数字

2.1 从下游限制倒推，而不是从上游猜

我见过太多人在这里随手填个"100"或者"500"，然后发现对方收不了。正确的顺序是先问清楚对面能吃什么，再定卷大小。填之前把这张表在脑子里过一遍：

表里"减一点余量"这件事别嫌啰嗦。我曾经按 4GB 整填过一次，结果对方系统是按 4×10^9 字节算的，不是 4×2^30 字节，差了 7% 左右，第一卷就超了。单位换算是分卷压缩里翻车率最高的一环，下面还会专门说。

2.2 卷数越多，失败面越大

每一卷都是一个独立的文件，多一卷就多一个可能丢失、损坏、漏传的点。二十卷里丢一卷的概率，粗略地说是单卷的二十倍。我给自己定的规矩是尽量控制在十五卷以内，超过就说明该换通道了，比如改用支持大文件直传的方式，而不是硬切。

另外一个容易被忽略的点：卷数多的时候，接收方解压失败的排查成本会指数上升。你得先确认卷齐不齐、命名对不对、有没有重复下载的副本混在里面。我曾经收到过一个 30 卷的包，里面混进了两个同名但大小不同的"第九卷"，解压程序读到一个就报错停下，查了半小时才发现是对方重复点了两次下载。

2.3 4GB 这条线为什么反复出现

4GB 这个数字不是随便定的，它来自 32 位文件系统对单文件大小的寻址上限。FAT32 的目录项里记录文件大小的字段是 32 位，最大值 2^32-1 字节，换成十进制就是 4294967295。很多老设备和精简系统至今只认这个格式，所以你在做"要给很多人用"的包时，按 4GB 以下切是最稳的选择。

实际操作里我一般填3900MB。原因有两层：一是留出 100MB 出头的余量，防止不同工具对单位理解不一致；二是最后一卷通常会小一些，总体体积不会因此膨胀多少。

提示：图形界面里"分卷大小"这个输入框，默认单位经常是字节，不是 MB。你填100得到的是一百字节，不是一百兆。填完一定要看一眼右边的单位下拉框，或者干脆在输入框里直接带上单位写成100m。

2.4 固实压缩和分卷之间那点微妙关系

固实压缩（solid）的做法是把包内所有文件当成一条连续的数据流来压，文件之间共享字典，压缩率通常比非固实高几个百分点，文件数量越多、类型越杂，收益越明显。但它有个代价：所有文件被绑在一起了，想单独解出中间某一个文件，得把前面所有数据都解一遍。

分卷场景下这个代价会被放大。固实流被切成若干段之后，如果中间某一卷损坏，影响的不只是那一卷里的文件，后面依赖同一段字典的数据也可能受影响。所以我给的建议是：归档备份用固实，需要分发和容错的分卷包慎用固实。

还有个坑值得单独说。图形界面创建分卷时，固实压缩那个勾选框往往是默认勾上的；而命令行版不加-s参数时默认不固实。同一个原始文件，用界面和用命令做出来的包，体积和容错特性可能不一样。如果你要对同一批文件做多次归档、要求结果可复现，这一点必须留意。

3. 图形界面跑一遍完整流程：先改对三处，再看三个数

3.1 打开"添加到压缩文件"之后，先把这三格改掉

右键选中文件或文件夹，选"添加到压缩文件"，弹出的面板里参数多得吓人，但真正决定成败的就那么几处，按顺序来：

第一格，压缩格式。必须选 RAR。这一点很多人栽过跟头——ZIP 格式本身不支持分卷，面板上的分卷输入框会直接变灰。你想做分卷，格式只能是 RAR。

第二格，压缩分卷大小。就是上面 2.3 说的那个带单位的输入框。我习惯直接在里面敲3900m或者20m，用带单位写法比事后选下拉框更不容易出错。

第三格，压缩选项里的"创建固实压缩文件"。按 2.4 的判断决定勾不勾。分发用，取消勾选；归档用，勾上。

剩下那些选项，第一次做的话保持默认就行，不要一上来就全调一遍。

3.2 压缩等级、字典大小、恢复记录怎么搭配

这三个参数经常被一起乱调，其实各有各的适用面。压缩等级从"存储"到"最好"大概五档，字典大小从 1MB 到几百 MB，恢复记录是按百分比加到包里的冗余数据。

字典大小有个反直觉的地方：它吃的是压缩和解压时的内存，不是磁盘。字典设到 256MB，解压端也得有相应内存才能顺利处理。给不确定环境的人发包，字典别超过 32MB，这是兼容性和压缩率之间比较舒服的位置。

恢复记录我一般给 3%。它能修复的是卷内部的局部损坏，比如几个扇区读错、传输中少量字节翻转。它救不了整卷丢失，那是恢复卷的活。

3.3 生成之后，用三个数字对一遍账

包做完别急着发，看一眼这三处：

第一，卷的数量。用原始总大小除以卷大小，向上取整，就是理论卷数。如果实际多出一卷，通常是最后剩了一点点数据单独成卷，正常；如果少一卷，说明你对原始大小的估计错了，重新算。

第二，每一卷的实际大小。除了最后一卷，其余应该都等于你设定的值，误差在几十字节以内（那是卷头开销）。如果某一卷明显偏小，可能是磁盘写满或中途出错，得重做。

第三，跑一次测试。图形界面里有"测试压缩文件"的功能，命令行是rar t。这一步我强烈建议养成习惯——压缩过程中出问题不一定当场报错，磁盘满、权限不足、文件被占用，都可能留下一个看起来正常但实际残缺的包。测试会逐卷校验，几秒钟的事，能省掉后面几小时的扯皮。

4. 命令行这条路：批量化、可复现、能写进脚本

4.1 为什么做过几次之后我更愿意敲命令

图形界面点几下很方便，但它有三个绕不过去的短板：参数不记录，下次做同样的包还得凭记忆再点一遍；没法批量，十个目录就要点十次；服务器环境根本没界面。命令行把参数变成一行文本，可以存进文档、写进脚本、交给别人复现，出了问题还能逐字检查当初到底设了什么。

4.2 一条命令里每个参数在干什么

最常用的骨架长这样：

rar a -v3900m -m5 -md32m -rr3 -rv3 -ma5 backup_data.rar ./data/

逐个拆开看：

• a是添加并创建压缩包。
• -v3900m指定分卷大小 3900MB，生成backup_data.part1.rar、backup_data.part2.rar这样一组文件。单位可以是k、m、g，不带单位就是字节。
• -m5压缩等级最高。想快就换成-m1，只想打包不压缩用-m0。
• -md32m字典 32MB。文件很杂、重复模式跨度大的时候可以往上调，但记得考虑解压端内存。
• -rr3加 3% 的恢复记录，用来修复卷内局部损坏。
• -rv3额外生成 3% 的恢复卷（.rev文件），这个能重建整个丢失或严重损坏的卷，比恢复记录更强。
• -ma5强制用 RAR5 格式。想要更好兼容老工具就换成-ma4，但 RAR4 不支持超过一定大小的字典和某些加密特性。
• 最后的./data/是要打包的源目录。

注意：命令行默认不启用固实压缩，需要显式加-s。这一点和第 2.4 节说的界面默认值相反，跨工具复用同一套参数时特别容易在这上面出偏差。

4.3 文件列表、排除规则、密码

真正干活的时候，源目录往往没法整包打，总有些临时文件、缓存目录要剔除。这里几个参数很实用：

rar a -v500m -m3 -s -rr3 \ -x"*.tmp" -x"*.log" -x"cache/*" \ -n"*.csv" -n"*.json" \ -p"你的口令" -hp \ report_2024.rar ./export/

-x是排除，支持通配符，可以写多条。-n是只包含匹配的文件，适合从一个大目录里挑特定类型。-p设解压口令，-hp连文件名一起加密——不加-hp的话，别人不输密码也能看到包里有哪些文件名，敏感场景下这算信息泄露。

口令这件事我多说一句：分卷加密码之后，每一卷都参与解密链条，任何一卷损坏或缺失都会导致整体打不开，而且没有密码谁也救不回来。给外部发加密分卷包时，密码走另一个通道传（比如另一条消息、电话），别和压缩包放在同一封邮件里，这是基本的操作习惯。

4.4 验证和解压：只需要指定第一卷

做完之后先测一遍：

rar t backup_data.part1.rar

解压的时候同样只给第一卷，程序会自己顺着找后面的：

rar x backup_data.part1.rar ./restore/

如果只想看包里的结构不解压，用rar l backup_data.part1.rar。这个命令在排查"包到底有没有做全"的时候特别顺手，它会列出所有卷以及每卷包含哪些文件。

5. 卷出问题时的排查链路：按这个顺序走，别乱试

5.1 提示"找不到下一个卷"

这是最高频的报错，原因基本集中在三处，按顺序排查效率最高。

第一步，看命名。RAR 分卷的命名是强约定的，名字.part1.rar、名字.part2.rar这样递增。所有卷的前缀必须完全一致，part后面的数字必须连续。改前缀一般没问题（把十个卷的名字前缀统一改掉，解压时指定新的第一卷，它能找到新的第二卷），但改数字一定出事。有人为了排序方便把part10改成part010，程序就找不到了。

第二步，看目录。所有卷必须在同一个目录下，不能分散在几个文件夹里。合并的时候经常有人把不同批次下载的卷放在不同子目录，然后逐个别名解压。

第三步，看有没有多余副本。浏览器重复下载会自动加(1)、(2)后缀，这会让目录里出现两个"第一卷"。程序读到哪个不确定，读到小的那个就报缺失。

5.2 某一卷校验失败

如果报错明确指出某一卷损坏，而其他卷都正常，处理路径有两条。

一是有恢复卷（.rev文件）。把这些文件放在同一目录，用修复命令让它重建损坏的那一卷：

rar r backup_data.part3.rar

程序会扫描同目录下所有.rev文件，尝试重建。恢复卷的比例决定了能救回多少——3% 大概能重建一到两卷中小体积的损坏，比例越高能救的越多，但包的整体体积也越大。

二是没有恢复卷，但包内加了恢复记录。这种情况修复的对象是卷内的局部损坏，不是整卷丢失。修复完通常会生成一个rebuilt.开头的文件，内容可能有少量损失，但大部分能拿回来。

提示：修复这件事越早做越好。发现某一卷有问题，先把这一组卷原样复制一份再做修复操作，不要直接在原始文件上动手。修复过程有可能覆盖原文件，而万一修复失败，你连原件都没了。

5.3 换设备、换工具之后的兼容性问题

同样的卷，在自己机器上好好的，发到对面就解不开，这种问题我遇到过几次，原因大多是格式版本对不上。RAR5 是较新的格式，老版本的工具可能压根不认；RAR4 兼容面广，但压缩率和某些特性弱一些。给不确定环境的人发包，用-ma4生成 RAR4 格式更保险。

还有一种情况是编码问题。包里的文件名含非 ASCII 字符时，不同系统下的解压结果可能有差异。这种场景我一般会在包里加一个纯 ASCII 命名的说明文件，把原始目录结构写清楚，万一文件名乱了还能照着重命名。

5.4 分卷的"独立性"边界：哪些操作是安全的

整理一下我在实践中验证过的边界，省得你一条条试：

6. 几个我自己踩出来的经验

6.1 别对已经压过的文件用最高压缩等级

视频、照片、音频、已经打包过的安装程序，这些数据的熵已经很高，再用最高等级压一遍，收益通常只有 1% 到 3%，CPU 却要多跑几倍时间。我做过一次对比，一个 5GB 的视频素材目录，最高等级压了四十多分钟，出来 4.89GB；换成存储模式，两分钟出结果，4.98GB。差距不到 2%，时间差了二十倍。这种场景直接用-m0配合分卷，又快又省心。

反过来，代码仓库、文本日志、CSV 导出这类数据，压缩等级拉满非常值。一个 3GB 的日志目录，标准等级大概能到 300MB，最高等级能到 180MB 左右，差距相当可观，而且字典调大之后收益还会继续涨。

6.2 分卷必须"一起走、一起备份、一起传"

这是我吃过最大的一次亏。当时做了 12 卷，发出去之后对面只收到 11 卷，问是哪一卷少了，双方来回对了半天——因为没有一份完整的清单。从那之后我养成了习惯：做完分卷，立刻生成一份文件清单（卷名、大小、校验值），和包一起发。

清单可以这样生成：

ls -l backup_data.part*.rar > manifest.txt sha256sum backup_data.part*.rar >> manifest.txt

对方收到之后跑一遍校验，一行行比，缺哪卷一眼就看出来。这几十秒的操作，能省掉后面几十分钟的来回确认。

6.3 参数写在文件里，别只留在脑子里

同一个项目往往要定期做归档，每次的参数最好保持一致，否则前后两批包的字典大小、固实设置不一样，后面合并处理的时候容易出问题。我的做法是在项目目录下放一个纯文本的pack.txt，里面写着这次用的完整命令和生成时间，下次直接复制粘贴改日期就行。

6.4 做完立刻测，别等对方反馈

这条经验最朴素也最有用。压缩完当场跑rar t，几十秒的事。我见过太多"发出去才发现包有问题"的情况，而那时候文件已经传完、对方已经下班，重新来一遍要等第二天。

如果包特别大、测试要跑很久，至少测第一卷和最后一卷。第一卷能过说明卷头正常，最后一卷能过说明收尾完整，中间出问题的概率相对低——虽然不能完全排除，但能挡掉大部分低级错误。

6.5 关于卷大小的一个个人偏好

最后分享一个纯个人习惯：给别人发包，我很少用超过 2GB 的卷，哪怕对方说没有限制。原因很简单——卷越大，单卷传输失败重来的成本越高，而且一旦某卷损坏、又没有恢复卷，损失的数据量就是整整一卷。1GB 到 2GB 这个区间在我看来是"重传不吃力、卷数不失控"的平衡点。当然，如果你的通道特别稳定、文件又特别大，往上调也没问题，只是记得把恢复卷的比例一起提上去。