你有没有经历过这种经典剧情？

• 上午：给整合包加了三个“绝对不会冲突”的 Mod。

• 中午：顺手更新了加载器、任务系统和十七个前置。

• 下午：游戏启动失败。

• 晚上：你盯着 mods 文件夹，开始凭记忆删除文件，试图复原“那个能玩的状态”。

最后，你在桌面上得到了一排极具人类文明特色的文件：

整合包备份.zip　整合包备份2.zip　最终版.zip　最终版修复.zip　最终版真的能玩.zip

这不叫版本管理，这叫考古。更可怕的是，三周后的你会成为最不了解这些文件的人。

这篇文章就来解决这个问题：不要求你先学会 Git，不要求你把整合包工程化到能发射火箭，而是先用一个基于 7-Zip 的轻量高性能的图形界面工具——FolderRewind（中文名“存档时光机”）——建立一套看得懂、用得上、出事能救命的版本化管理流程。

一、整合包为什么必须“版本化”管理？

所谓“版本化管理”，并不是每隔半小时把文件夹复制一次，然后在名字后面加一个“新”。真正有用的版本，需要回答三个问题：

1. 这个版本是什么时候保存的：至少要知道它是在加 Mod 前、调完配方后，还是发布测试版之前。

2. 这个版本为什么值得保留：例如“完成第一章任务线”“更新机械动力前”“旧存档升级测试通过”。

3. 出了问题能不能可靠恢复：版本历史不是纪念册。点下恢复之后，实例必须真的能回到当时的状态。 整合包尤其需要版本化，因为它并不是一个单独的软件，而是一群 Mod、配置文件、脚本、资源包、任务数据、启动器设置和存档挤在同一间屋子里。你更新一个 Mod，可能顺便改变配置格式；你删除一个 Mod，可能留下旧配置；你测试一次世界，某些文件又会被游戏自动改写。

二、你真正需要管理的，其实是三样东西

1. 整合包开发实例

也就是你在 HMCL、PCL2 或其他启动器中实际运行的那个实例。里面不仅有 mods，还包括 config、defaultconfigs、kubejs、资源包、按键设置、启动参数以及游戏运行后生成的各种文件。

2. 测试存档

开发整合包时，测试世界往往比正式存档更重要。你可能有一个世界专门测试前期流程，一个世界测试世界生成，还有一个世界被你塞满机器，用来检验服务器重启后会不会原地升天。

测试存档最好单独建立备份配置。这样当任务线测试失败时，你只需要回滚世界，不必把整个整合包实例一起送回石器时代。

3. 发布产物

你真正发给玩家的 .mrpack、整合包压缩包、服务端包，也应该保留。

三、用 FolderRewind 给整合包建立时间轴

FolderRewind 是一款面向文件夹备份与恢复的图形界面应用。它可以为任意文件夹创建自动化备份，并通过历史时间轴让你回到某个状态。对于整合包作者来说，它最大的价值不是“备份”这两个字，而是把混乱的复制粘贴，变成可识别、可备注、可恢复的版本节点。

主页面

第一步：给开发实例建立一个配置

找到启动器中的整合包实例目录，把它作为 FolderRewind 的源文件夹。建议配置名称直接写清楚，例如：

• 「我的整合包 - 开发实例」

• 「我的整合包 - 旧存档升级测试」

• 「我的整合包 - 发布产物」

不要把所有 Minecraft 实例、全局资源库和启动器缓存一股脑塞进去。备份范围越大，恢复时越容易出现“为了救一只鸡，把整个村庄倒带了”的效果。

第二步：选择合适的备份模式

FolderRewind 提供全量、智能增量和覆写等备份方式。其实可以这样理解：

入门阶段可以采用一个非常稳妥的组合：平时使用智能增量，进行大规模 Mod 更新、加载器升级或正式发布前，再手动创建一个全量备份。这样既不会让硬盘迅速长成一座压缩包山脉，又能保留清晰的关键节点。

第三步：设置过滤规则

整合包实例里有些东西很重要，有些东西只是日志在努力证明自己来过。合理过滤可以显著减少备份体积。

通常值得保留的内容包括：

• mods、config、defaultconfigs

• kubejs、scripts、任务数据、数据包

• resourcepacks、shaderpacks，以及你自制的美术资源

• 实例描述、启动参数和与整合包相关的启动器配置

通常可以考虑排除：

• logs、临时缓存、重复下载文件

• screenshots（除非你把它当开发记录）

• crash-reports（已定位问题后可移走；正在排错时别排除）

• 与整合包无关的测试录像和性能分析大文件

FolderRewind 支持黑名单、白名单和正则规则。刚开始不熟悉规则时，建议使用黑名单：只排除你明确知道不需要的目录。白名单威力很大，但少写一个目录，就可能在恢复时收到一份“缺胳膊少腿但压缩率很优秀”的整合包。

第四步：让备份自动发生 / 让备份触手可及

人类最不可靠的自动化方案叫“我记得一会儿备份”。因此，FolderRewind 支持间隔、计划和文件夹变化触发等自动备份方式。

整合包开发可以参考下面的节奏：

• 日常调配置：每 30～60 分钟自动备份一次。

• 集中更新 Mod：更新前手动备份，确认稳定后再手动备份。

• 关键测试世界：每次开始测试前创建节点，测试结束后视结果决定是否保留。

• 正式发布：导出前创建全量备份，并在备注中写明版本号。

另外，设置快捷键和 mini 悬浮窗有助于提升你日常备份的积极性哦~

mini悬浮窗，随时查看状态！

四、每个备份都要写备注，否则未来的你会失忆

版本历史最怕出现一排时间戳，却没有任何上下文。你当然可以通过日期推理，但三个月后的你大概率只记得那天吃了什么，不记得为什么更新 Architectury。

建议把备注写成“动作 + 目的 + 风险”的形式：

• 更新机械动力及其附属前；可能影响动力网络。

• 完成第一章任务线；前期流程已通关测试。

• 移除旧世界生成 Mod 前；旧存档必须保留。

• v0.4.0-beta.2 发布候选；服务端加入测试通过。

• 修复配方冲突后；仅修改 KubeJS 脚本。

一个好备注不需要写成论文，但应该让你在半年后看懂。当你准备进行危险操作时，先创建备份，再把备注写清楚。这个动作只需几十秒，却能避免你之后用几个小时进行“反向猜谜”。

五、FolderRewind 能不能完全替代 Git？

这里需要坦白：不能，而且没必要。两者解决的不是同一类问题。

因此，入门作者可以先用 FolderRewind 建立版本化习惯：每次危险操作前留节点，定期自动备份，重要版本写备注，必要时回滚。等整合包开始出现大量 KubeJS 脚本、自定义数据包、多人协作和自动发布需求，再加入 Git。

六、备份的几个常见误区

误区 1：备份放在同一块硬盘，就绝对安全

如果源文件和备份都在同一块硬盘上，硬盘损坏时它们会非常团结地一起消失。重要版本至少再同步到另一块磁盘、NAS 或云端。FolderRewind 支持将备份对接 WebDAV、FTP 等远端存储，但无论使用哪种方案，都建议定期验证远端文件能否恢复。

误区 2：只要备份成功，就不必测试恢复

从未恢复过的备份，属于“理论上有用”。正式制作整合包前，先选一个测试目录进行几次备份与还原，熟悉覆盖、清理和保留规则。你需要在灾难发生前知道恢复按钮会做什么，而不是在灾难发生后边点边读说明。

误区 3：自动备份可以替代里程碑

自动备份负责防止你丢掉最近一小时的工作，里程碑负责告诉你“这个版本为什么重要”。两者都需要。否则你会得到两百个时间点，但仍然不知道哪个能玩。

误区 4：热备份、热恢复永远没有风险

MineRewind/MineBackup-Mod 等联动组件可以帮助协调热备份与热恢复，但涉及重要世界时，仍建议先在测试存档验证，并保留额外的离线副本。技术可以降低风险，不能消灭“我点错了”这种自然现象。

结语：允许自己犯错，但别让错误无法撤销

整合包制作的乐趣，本来就在于不断尝试：这个 Mod 能不能和那个系统组合？这个配方是否更合理？这个任务流程会不会让玩家在第一小时就开始怀疑人生？

尝试越多，犯错越正常。真正危险的不是改坏，而是改坏以后不知道自己改了什么，也回不到修改之前。

FolderRewind 想做的事情很简单：让整合包作者敢于折腾。你可以更新、替换、重做，甚至在凌晨两点做出一些第二天无法解释的决定——只要提前留下一个版本节点，时间轴上就还有一颗“后悔药”

—— 为你的数字世界留一份后悔药。——