目录模型

Last updated on

三个目录

Polymerium 中的每个实例都有三个目录。每个目录都有不同的任务和不同的生命周期：

instances/my-modpack/
├── import/     ← 整合包源：随整合包提供的文件
├── persist/    ← 本地保留：你明确选择保留的文件
└── build/      ← 运行目录：Minecraft 实际读写的游戏目录

这些名称会在 Polymerium 中反复出现。完整口径见术语表 →。

import/ — 整合包源

这是整合包作者的意图。当你导入整合包时，它的文件会放置在这里——配置、默认选项、自定义资源等。

• 谁写入它： 整合包作者（通过导入或手动放置）
• 它何时改变： 当你更新或重新导入整合包时
• 它的用途： 整合包文件的权威、可分发版本

persist/ — 本地保留

这个目录是你的，但 Polymerium 不会自动把个人数据移动进去。你决定什么内容放在这里。

关键规则很简单：只有已经放入 persist/ 的文件，才会在重置和整合包更新后保留。你的 saves/、截图、选项和模组生成的配置通常一开始都在 build/，这意味着重置会删除它们，除非你先把想保留的内容移动到 persist/。

它的工作原理：

1. 对于单个文件 —— 将文件从 build/ 移动到 persist/。例如，将 build/options.txt 移动到 persist/options.txt。在下一次部署时，Polymerium 会以最高优先级将 persist/options.txt 链接到 build/，所以你的版本总是胜出。

2. 对于目录 —— 将目录（例如 saves/）移动到 persist/，然后在其中创建一个空的 .keep 文件：persist/saves/.keep。这告诉 Polymerium 将整个目录投射到 build/ 中。

• 谁写入它： 你
• 它何时改变： 当你决定添加或更新文件时
• 它的用途： 你想要在重置、整合包更新和重建中幸存的文件
• 它不是： 自动备份。只有你放进这里的数据才会受到保护。

build/ — 运行目录

这是最终的游戏目录——Minecraft 看到的 .minecraft。它是在部署期间从其他层组装而成的。游玩时，游戏在这里读写。

• 谁写入它： Polymerium 的部署引擎，以及你游玩时的游戏
• 它何时改变： 每次部署，以及每次游戏会话
• 它的用途： 可运行的游戏目录
• 你可以删除它吗？ 只能谨慎删除。重置会清空 build/，任何只存在于这里的内容都可能永久丢失，包括存档、截图、日志，以及游戏或模组生成的配置。已经移动到 persist/ 的文件是安全的；来自 import/、包、元数据和缓存的内容可以重新构建或重新链接。

它们如何关联

import/  ──────────→  build/
persist/ ──────────→  build/
  （最高优先级）

在部署期间，文件按此顺序分层到 build/ 中：

1. 缓存文件 —— 模组、库、资源（从缓存符号链接）
2. 整合包源（import/）文件 —— 整合包源文件
3. 本地保留（persist/）文件 —— 你保留的文件（最高优先级，总是胜出）

如果同一个文件同时存在于 import/ 和 persist/ 中，persist/ 版本会在 build/ 中优先。

常见操作期间发生什么

¹ 清除的是 build/ 下 import 的工作副本，不是整个游戏目录。

关键要点

• 重置会清除 build/。除非你已经把存档和游戏配置移动到 persist/，否则它们会被删除。
• 整合包更新会替换或更新 import/，并刷新 build/ 下的 import 工作副本。persist/ 会被保留——这就是全部意义。
• build/ 只有在内容有 persist/、import/、元数据、包或缓存兜底时才是可丢弃的。只存在于 build/ 的个人数据应视为有丢失风险。

为什么这很重要

这个模型解决了模组 Minecraft 中的一个真实矛盾：

• 整合包作者想要分发一致的配置和资源。
• 玩家想要在更新之间保留他们的设置和存档。
• 双方都希望整合包更新能够在不丢失重要数据的情况下工作。

Polymerium 的答案：将这些关注点分离到具有不同生命周期的不同目录中。你控制什么被保留——将其移动到 persist/，Polymerium 保证它会在重置和更新后保留。

下一步

了解部署如何组装这些层 → 部署流水线