我是做独立开发的，主要写一些 Windows 平台的小工具和效率软件。说实话，开发者圈子里一提打包安装包，言必称 Inno Setup、NSIS、InstallShield，好像不用这些就不专业。但我做了三年独立开发，发布了十几个小工具，用得最多的打包工具居然是 WinRAR—— 就是那个大家电脑里都有的压缩软件。

不是说 Inno Setup 不好，而是对我这种 “小而美” 的独立开发者来说，WinRAR 的 SFX 自解压功能实在太顺手了 —— 轻量、灵活、不用学脚本语言、几分钟就能出一个专业的安装包。今天就从一个开发者的角度，聊聊 WinRAR 在软件开发、打包发布、自动化构建场景中的真实用法，给同行们一个不一样的视角。

一、SFX 自解压包：小工具发布的终极武器

先说说我为什么用 WinRAR 做安装包。

独立开发者做的小工具，通常就是一个 exe 主程序加几个 dll 依赖、一个配置文件、一个说明文档，总共也就几兆到几十兆。用 InstallShield？太重了，光安装包模板就几百兆，学习成本也高。用 Inno Setup？确实好用，但得学它的脚本语言，写一个安装脚本至少要半小时，还得调试。

WinRAR 的 SFX（Self-Extracting Archive，自解压档案）就不一样了。它本质上是把压缩包和一个解压模块打包成一个 exe 文件，用户双击之后自动解压，还能设置解压路径、解压后自动运行程序、创建快捷方式、显示许可协议。对小工具来说，这些功能完全够用了，而且操作全是图形界面，不用写一行代码。

我发布小工具的标准流程是这样的：编译好 Release 版本，把主程序、依赖 dll、配置文件、readme 都放到一个文件夹里，全选右键 “添加到压缩文件”，勾选 “创建自解压格式压缩文件”，然后点 “高级”→”自解压选项”，开始配置。

配置项其实不多，但每一个都很实用：

常规选项卡：设置解压路径。我一般填%ProgramFiles%\MyApp，这样不管用户系统装在 C 盘还是 D 盘，都会自动解压到正确的 Program Files 目录下。还可以设置 “解压前运行” 和 “解压后运行”，我一般在 “解压后运行” 里填主程序名MyApp.exe，这样用户解压完自动启动程序，体验跟正规安装包没区别。

模式选项卡：设置安静模式和覆盖方式。安静模式选 “全部隐藏” 的话，用户双击之后后台自动解压运行，连界面都不弹，非常干净。不过我一般选 “隐藏启动对话框”，让用户能看到解压进度，心里有底。覆盖方式选 “覆盖所有文件”，这样用户升级覆盖安装的时候不会弹确认框。

文本和图标选项卡：自定义安装包的图标和窗口标题。我会把自己软件的图标设上去，窗口标题写 “某某软件安装程序”，看起来就很专业。还能设置解压时显示的文本，我一般写个简短的欢迎语和版本号。

许可选项卡：这个就跟正规安装包一样了，用户双击之后先弹一个许可协议窗口，必须点 “我同意” 才能继续安装。我把 MIT 协议的内容贴进去，看起来有模有样的。

整个配置过程不到五分钟，出来的安装包用户双击→同意协议→自动解压到 Program Files→自动启动程序，整个流程跟专业安装包体验几乎一样，但制作成本低了一个数量级。

有个细节很多人不知道：SFX 自解压包还能创建桌面快捷方式和开始菜单快捷方式。在自解压选项的 “高级” 选项卡里有个 “添加快捷方式” 按钮，可以设置快捷方式的名称、目标程序、工作目录、图标。我一般会创建一个桌面快捷方式和一个开始菜单文件夹里的快捷方式，用户安装完就能从桌面或者开始菜单启动，跟正规安装的软件完全一样。

二、命令行工具 rar.exe：开发者的隐形瑞士军刀

WinRAR 安装目录下有个rar.exe，这是命令行版本的压缩工具，很多人根本不知道它的存在。但对开发者来说，这个小工具简直是瑞士军刀级别的存在 —— 能压缩、能解压、能加密、能加恢复记录、能生成自解压包，全部通过命令行参数控制，完美集成到脚本和自动化流程里。

我日常用得最多的几个命令：

压缩整个项目：rar a -r -ep1 output.rar .\src\*

• a是添加文件到压缩包
• -r是递归子目录
• -ep1是排除基础目录，解压出来不会多套一层文件夹

加密压缩：rar a -pMyPassword -hp encrypted.rar .\src\*

• -p是加密文件内容
• -hp是连文件名一起加密（别人看不到压缩包里有什么）

加恢复记录：rar a -rr5 backup.rar .\src\*

• -rr5是添加 5% 的恢复记录，压缩包轻微损坏能自动修复

生成自解压包：rar a -sfx -sconfig config.txt setup.exe .\release\*

• -sfx是生成自解压 exe
• -sconfig是从配置文件读取 SFX 设置，不用每次手动配

解压：rar x -o+ archive.rar .\dest\

• x是带完整路径解压
• -o+是自动覆盖已有文件

这些命令看起来简单，但组合起来威力巨大。我写了一个批处理脚本build.bat，把编译、压缩、加密、生成自解压包、重命名带版本号这一整套流程全自动化了。每次发布新版本，双击一下脚本，喝口水的功夫，一个带版本号、加密、加恢复记录的自解压安装包就生成好了，不用手动操作任何一步。

脚本大概长这样（简化版）：

@echo off
set VERSION=1.2.3
set OUTPUT=MyApp_v%VERSION%_setup.exe

:: 编译Release版本
msbuild MyApp.sln /p:Configuration=Release

:: 用WinRAR生成自解压安装包
"C:\Program Files\WinRAR\rar.exe" a -sfx -sconfig sfx_config.txt -p%VERSION% -rr3 %OUTPUT% .\Release\*

echo 构建完成: %OUTPUT%

就这么十几行脚本，把整个发布流程自动化了。以前手动打包要十分钟，现在十秒搞定，而且不会出错 —— 不会忘记加密，不会忘记加恢复记录，版本号不会写错。对独立开发者来说，这种自动化太重要了，能省出大量时间写代码。

三、CI/CD 集成：Jenkins 和 GitHub Actions 里自动打包

命令行工具最大的价值，是能集成到 CI/CD 流水线里。我后来项目多了，就搭了个 Jenkins 做持续集成，代码提交到 Git 之后自动触发构建，编译完自动用 WinRAR 打包，然后上传到发布服务器。

Jenkins 里的配置很简单，就是在构建步骤里加一个 “执行 Windows 批处理命令”，把上面那个 build.bat 的内容贴进去就行。Jenkins 构建完，工作区里自动生成好带版本号的安装包，然后用另一个步骤通过 FTP 或者 SCP 上传到下载服务器。

整个流程是这样的：我在本地写完代码，push 到 Git 仓库，Jenkins 检测到变更自动拉代码、编译、用 WinRAR 打包、上传到服务器，全程不用我干预。我 push 完代码就可以去喝杯咖啡，回来之后新版本已经在下载服务器上等着用户下载了。

GitHub Actions 也一样，在 workflow 的 yaml 文件里加一步调用 rar.exe 就行。不过要注意，GitHub Actions 的 runner 默认没有装 WinRAR，需要在构建步骤里先下载安装 WinRAR，或者把 rar.exe 提交到仓库里直接调用。我是把 rar.exe 和它的依赖 dll 放到仓库的tools目录里，构建的时候直接用相对路径调用，不用额外安装，简单粗暴但有效。

有个坑要提醒：WinRAR 是商业软件，在 CI/CD 环境里使用需要确保有合法授权。我买的是企业版授权，支持在多台机器（包括构建服务器）上使用，所以没问题。如果是个人开发者，用免费试用版在自己的构建脚本里用问题不大，但如果是商业项目或者公开的 CI/CD，建议买个正版授权，别因小失大。

四、代码版本归档：每个 Release 都打一个加密包

做开发的都知道，代码版本管理很重要。Git 虽然能管理代码，但有些东西不适合放 Git—— 比如编译好的二进制文件、第三方依赖包、数据库快照、设计稿源文件。这些东西体积大，放 Git 里仓库会膨胀，不放又怕丢。

我的做法是：每个 Release 版本发布的时候，除了打 Git tag，还用 WinRAR 把整个项目目录（包括源码、二进制、依赖、文档、设计稿）打一个加密压缩包，加上恢复记录，存到备份硬盘和云盘各一份。

压缩命令就是：

rar a -p密码 -hp -rr5 -m5 project_v1.2.3_full_backup.rar .\project\*

• -m5是最高压缩率，源码和文档压缩率很高，能省不少空间
• -p和-hp双重加密，防止备份泄露
• -rr5加 5% 恢复记录，备份文件损坏了能修

这样每个版本都有一个完整的快照包，以后想回溯某个版本的完整状态，直接解压这个包就行，不用从 Git 重新拉代码、重新装依赖、重新编译。我有一次想找两年前一个版本的编译好的 exe，Git 里只有源码，重新编译环境都配不好了，最后就是从备份的 RAR 包里找到的，当时真的庆幸自己有这个归档习惯。

RAR5 格式的压缩率在这方面也有优势。RAR5 默认字典大小是 32MB，最大能到 1GB（64 位 WinRAR 7.x 版本甚至支持到 64GB 字典），对源码这种大量重复文本的压缩率特别高。我一个 500MB 的项目目录（含源码和二进制），用 RAR5 最高压缩率压完大概 80MB，压缩率超过 80%，比 ZIP 格式小了差不多 30%。

五、日志文件压缩归档：服务器运维的刚需

虽然我是独立开发者，但自己的软件也有服务器端，日志文件是刚需。服务器上的日志每天都在涨，一个月下来能有几个 G，不压缩的话硬盘很快就满了。

我在服务器上写了个定时任务，每天凌晨自动用 WinRAR 命令行把前一天的日志压缩归档，压缩完删除原始日志文件。压缩包按日期命名，存到日志归档目录，保留最近 90 天的，超过 90 天的自动删除。

脚本很简单：

@echo off
set YESTERDAY=%date:~0,4%%date:~5,2%%date:~8,2%
rar a -m5 -rr3 -ep1 "D:\logs\archive\%YESTERDAY%.rar" "D:\logs\*.log"
del "D:\logs\*.log"

就这么几行，日志归档全自动。压缩率很高，一天 100MB 的日志压完大概 10MB，90 天的归档也就 1GB 左右，硬盘压力小很多。而且加了恢复记录，日志归档文件损坏了也能修复，对需要保留日志做问题排查的场景来说很重要。

六、RAR5 算法技术细节：开发者为什么该关心

作为开发者，我对压缩算法本身也有点兴趣。RAR5 相比老的 RAR4 和通用的 ZIP，在技术上确实有几把刷子，了解这些对选择压缩参数有帮助。

字典大小：这是影响压缩率最关键的参数。RAR4 最大字典只有 4MB，RAR5 直接干到了 1GB（WinRAR 7.x 版本 64 位下甚至支持 64GB 字典）。字典越大，算法能 “记住” 的重复数据范围越大，对大文件和大量相似文件的压缩率提升越明显。我压代码项目的时候一般用 64MB 字典，压缩率比默认 32MB 再高 5% 左右，但压缩时间会增加，内存占用也会上去（字典多大就占多少内存），所以要根据自己机器配置选。

固实压缩：RAR 的固实压缩是把所有文件当成一个连续的数据流来压缩，而不是每个文件单独压缩。这样做的好处是跨文件的重复数据也能被压缩，大量小文件的时候压缩率提升特别明显。坏处是修改压缩包里的任何一个文件都要重建整个固实流，而且压缩包部分损坏可能影响多个文件。我归档旧版本的时候用固实压缩（因为归档了就不改了），日常备份用普通压缩（因为可能要增删文件）。

BLAKE2 校验和：RAR5 用 BLAKE2 替代了老的 CRC32 校验，检错能力更强，能检测到 CRC32 检测不到的损坏。对开发者来说，这意味着压缩包的数据完整性更有保障，尤其是长期归档的文件。

多线程解压：RAR5 解压支持多 CPU 核心，虽然不如压缩时提升那么大，但大文件解压的时候速度提升明显。我解压一个几个 G 的代码归档，RAR5 比 RAR4 快了大概 30%。

这些技术细节可能普通用户不关心，但对开发者来说，了解这些能帮你在不同场景下选择最优的压缩参数 —— 归档用大字典 + 固实 + 最高压缩率，日常备份用默认参数，快速分享用最快压缩率。

七、跟专业安装工具比，差在哪

说了这么多 WinRAR 打包的好处，也得客观说说它跟专业安装工具的差距，免得大家盲目用。

注册表操作：Inno Setup 和 NSIS 能写注册表、注册 COM 组件、注册服务，WinRAR 的 SFX 做不到。如果你的软件需要写注册表或者注册系统组件，SFX 就不够用了，得上专业安装工具。

卸载功能：专业安装工具能生成卸载程序，在控制面板的 “程序和功能” 里能看到，能正常卸载。WinRAR 的 SFX 没有卸载程序，用户想删只能手动删文件夹和快捷方式，体验上差一截。我一般会在程序目录放一个uninstall.bat，手动删文件夹和快捷方式，算是个简陋的替代方案。

依赖检测：专业安装工具能检测.NET Framework、VC++ 运行库这些依赖，没装的话提示用户安装。SFX 做不到，只能把依赖 dll 一起打包进去，或者在说明文档里告诉用户需要装什么。

安装界面定制：专业安装工具的安装界面可以高度定制，有欢迎页、许可页、选择路径页、选择组件页、进度页，跟商业软件一模一样。SFX 的界面比较简单，就是一个解压进度条加一个许可协议弹窗，定制空间有限。

所以我的建议是：小工具、内部使用的软件、快速原型验证，用 WinRAR SFX 打包完全够用，省时省力。但如果是商业软件、需要写注册表、需要正规卸载、需要精美安装界面的，还是老老实实用 Inno Setup 或者 NSIS。我自己的小工具用 SFX，接的商业项目用 Inno Setup，各取所长。

八、踩过的坑和注意事项

用 WinRAR 做开发打包三年，也踩过不少坑，分享给同行避避坑。

第一，SFX 自解压包的路径变量要写对。%ProgramFiles%在 32 位系统和 64 位系统上指向的目录不一样，32 位程序在 64 位系统上会被重定向到Program Files (x86)。如果你的程序是 32 位的，解压到%ProgramFiles%实际上会到Program Files (x86)，这是 Windows 的正常行为，但有时候会让用户困惑。建议在说明文档里写清楚安装路径，或者直接用%LocalAppData%\Programs，这是现在推荐的用户级安装路径，不需要管理员权限。

第二，自解压包需要管理员权限的问题。如果解压路径选了%ProgramFiles%，写入这个目录需要管理员权限，用户双击的时候 Windows 会弹 UAC 提示。如果用户不是管理员账号，就装不了。我的小工具一般选用户级路径（%LocalAppData%\Programs\MyApp），不需要管理员权限，普通用户也能装，体验更好。

第三，命令行的密码参数要注意安全。在脚本里用-p密码的话，密码会明文写在脚本里，如果脚本提交到 Git 仓库就泄露了。我的做法是密码从环境变量读取，脚本里写-p%PASSWORD%，密码存在构建服务器的环境变量里，不写进脚本，更安全。

第四，大字典压缩的内存问题。用 1GB 字典压缩的时候，WinRAR 会占用 1GB 以上的内存，如果机器内存不够（比如只有 4GB 内存还开着别的程序），可能会内存不足报错或者用虚拟内存导致速度极慢。我一般在内存 16GB 以上的机器上用大字典，8GB 以下的机器用默认 32MB 字典就够了。

第五，SFX 包被杀软误报。这个是最头疼的。自解压 exe 因为行为特征跟某些恶意软件相似（自动解压、自动运行程序、写入 Program Files），有时候会被杀毒软件误报为病毒。我发布的小工具就被 Windows Defender 误报过几次，用户下载之后直接被删了，投诉很多。解决办法是给 exe 做数字签名，签名之后误报率大大降低。如果没有代码签名证书，至少在发布前用 VirusTotal 扫一下，看看哪些杀软误报，然后去对应厂商的误报申诉页面提交申诉。

九、写在最后

做独立开发三年，我最大的体会是：工具没有高低贵贱，适合自己的就是最好的。开发者圈子里有一种风气，好像不用最专业的工具就不够格 —— 写代码不用 VS Code 就不专业，打包不用 Inno Setup 就不专业，部署不用 Docker 就不专业。但实际上，对独立开发者来说，效率才是第一位的，能用最简单的工具解决问题，就没必要折腾复杂的。

WinRAR 对我来说就是这样一个工具。它不是专业的安装制作软件，不是专业的 CI/CD 工具，不是专业的备份软件，但它的 SFX 自解压功能、命令行工具、高压缩率、加密和恢复记录，组合起来刚好能满足我在打包发布、自动化构建、代码归档、日志压缩这些场景的需求。而且它学习成本极低，不用学新的脚本语言，不用看厚厚的文档，图形界面几分钟就能上手，命令行参数查一下就会。

当然，它也有局限 —— 做不了注册表操作，没有正规卸载，安装界面简陋，容易被杀软误报。这些局限决定了它不适合商业级软件的打包，但对小工具、内部软件、快速原型来说，它完全够用，而且效率碾压专业工具。

我的建议是：如果你是独立开发者或者小团队，做的是轻量级 Windows 工具，不妨试试用 WinRAR 的 SFX 做安装包，用 rar.exe 做自动化打包。先跑起来，快速发布，收集用户反馈，等产品成熟了、有商业需求了，再迁移到 Inno Setup 或者 NSIS 也不迟。别在工具选择上浪费太多时间，把精力放在产品本身才是正道。

最后说一句：WinRAR 的开发者 Eugene Roshal 从 1993 年开始做 RAR 格式，到现在三十多年了，一直在持续更新维护。一个工具能用三十年还没过时，本身就说明它的设计是经得起时间考验的。我们开发者做产品，也应该有这种工匠精神 —— 把一个工具做到极致，让用户用了就离不开。