PandoraLauncher 是一款现代 Minecraft 启动器，它的核心亮点之一就是Mod 去重与内容库（Content Library）：无论你在多少个游戏实例里安装了同一个 Mod，磁盘上只保留一份文件。对于管理多个实例的 Minecraft 玩家来说，这意味着实实在在的磁盘空间节省——本文用通俗的方式讲清这套机制背后的工作原理。

一、为什么 Minecraft 启动器特别"吃"硬盘？

先看看痛点。Minecraft 玩家通常会维护多个实例：Fabric、Forge、NeoForge，不同版本号，不同的 Mod 组合。而传统启动器的做法是每个实例都带一个独立的.minecraft/mods文件夹——于是 Sodium、Fabric API 这类"人人都有"的 Mod 会被原样复制多份。

在 PandoraLauncher 的实例页面中，你可以看到每个实例各自管理自己的 Mods 列表（启用/禁用开关、版本信息一应俱全）：

一个装有 50 个 Mod 的实例轻松超过 1GB。三个实例共享大量相同 Mod 时，重复占用往往占总空间的一大半——这正是 PandoraLauncher 要解决的问题。

二、内容库：所有 Mod 只存一份 📦

PandoraLauncher 在启动器根目录下维护了一个contentlibrary目录，所有通过启动器下载的内容（Mod、Mod 包、资源包等）都统一存放在这里，而不是直接丢进实例。

它的组织规则非常巧妙：用文件的 SHA1 哈希值当文件名。

• 前 2 位哈希字符作为子文件夹（避免单目录文件过多）
• 完整哈希作为文件名，并保留原扩展名

也就是说，同一个文件无论在多少个实例里被引用，contentlibrary中永远只有一份实体文件：

contentlibrary/ ab/ ab3f...e9c2.jar ← 文件内容唯一的身份

相关源码可以查看 directories.rs（目录定义）和 create_content_library_path 函数（哈希路径生成）。

除了contentlibrary，还有一个配套的contentmeta目录，用于缓存 Mod 的元数据（名称、版本、图标、来源等），避免每次启动都重新解析。

三、安装 Mod 时的去重流程：先查库，再下载 ⚡

当你在 Modrinth 或 CurseForge 页面点击Install时，PandoraLauncher 并不是无脑下载，而是走一套"内容库优先"的流程（实现在 install_content.rs）：

1. 算出目标文件的 SHA1 哈希，拼出它在内容库中的"应有路径"；
2. 检查该文件是否已在库里：如果存在，直接校验磁盘上的哈希值，校验通过则完全跳过下载，进度条瞬间跑满；
3. 只有库中没有（或校验失败）才会真正下载，并逐块计算哈希，下载完成后再校验一次，哈希或大小不符立即删除坏文件；
4. 下载完成后，内容就"定居"在contentlibrary中，供所有实例共享。

这个流程还做了一层并发保护：多个任务同时要下载同一个哈希的文件时，通过文件锁排队（见 fs.rs 的 lock_file），确保同一次下载只发生一次。

💡 这就是"去重"的第一层：同一个文件，全网只下载一次。

四、reflink 与硬链接：让"复制"几乎不占空间 🔗

内容库存了一份，实例的mods文件夹里又该放什么？PandoraLauncher 用三级策略把库文件"放置"到实例中（fastcopy 函数）：

硬链接的效果可以这样理解：实例A/mods/sodium.jar、实例B/mods/sodium.jar和contentlibrary/.../sodium.jar是三个不同的路径，但它们在磁盘上共用同一份数据。删掉实例 A 的 Mod 完全不影响其他实例——数据块只有被所有引用删光后才会真正释放。

五、复制实例也自动去重 🚀

这套机制的价值在"复制实例"时体现得淋漓尽致。在 duplicate.rs 中，PandoraLauncher 的实例复制流程是：

1. 先尝试对每个文件做 reflink；
2. 若源文件已被发现是从内容库硬链接来的（链接数大于 1），就对文件重新计算哈希，回到内容库找到原件，再为新实例建立一条硬链接；
3. 只有真正独有的文件（比如你的存档）才执行完整复制。

结果就是：复制一个 2GB 的 Mod 实例，可能只花不到 1 分钟，并且几乎不增加磁盘占用。

顺带一提，左侧菜单里的Syncing页面是"空间节省者"的第二个帮手：它把saves、screenshots、resourcepacks等文件夹在多个实例间共享（Unix 上用符号链接，Windows 上用 junction），原理与 syncing.rs 中实现一致，让公共文件夹也只存一份。

六、元数据缓存：让去重"又快又聪明" 🧠

光有哈希还不够，PandoraLauncher 还要"认识"每个文件。ModMetadataManager 会解析 Mod 包内部的fabric.mod.json、META-INF/mods.toml、mcmod.info、pack.mcmeta等文件，提取名称、作者、版本、图标，并以 SHA1 为键建立内存缓存——同一个文件只需解析一次。

它还会记录每个哈希的来源（Modrinth / CurseForge / 手动安装），写入contentmeta/sources目录。这带来了额外的好处：

• 更新检查时能直接判断库里已有文件是否就是最新版；
• 安装 Mod 包时，先查库中已有哪些子文件，缺什么只下什么。

七、能省多少空间？一个简单估算 📊

假设你的配置是：3 个实例，共享 40 个常见 Mod（平均每个 15MB），另有 10 个各自独有的 Mod：

实例越多、Mod 重叠度越高，节省比例越接近"一半以上"。这也是官方功能列表里明确宣称的卖点之一（见 README.md 中 "Mod deduplication when installed through launcher (using reflinks or hard links)"）。

总结

PandoraLauncher 的 Mod 去重本质上是一套"哈希寻址 + 链接共享"的组合拳：

• 内容库contentlibrary：以 SHA1 命名的统一存储，同文件只下载、只保存一份；
• reflink / 硬链接：让实例中的"副本"零额外空间占用，复制实例飞快；
• 元数据缓存contentmeta：哈希即身份，解析一次终身受益；
• 文件夹同步 Syncing：跨实例共享公共文件夹，进一步消除重复。

对多实例玩家而言，这是一项"装完就受益"的默认能力，无需任何配置。想了解完整实现，可以顺着 install_content.rs、fs.rs 和 duplicate.rs 三个文件读一遍，逻辑清晰且相当精炼。