安装模组时自动安装前置依赖

[FriskYan]

安装模组时自动安装前置依赖

在通过 PCL2 安装单个模组（拖拽 jar 文件，或从内置下载源安装）时，自动检测该模组声明的前置依赖，结合本地 mods 目录中已有模组的状态与版本信息，进行兼容性判定后，提示用户确认并一键下载安装缺失的前置模组。

当前安装单个 Mod 的典型流程如下：

1. 从 CurseForge 或 Modrinth 下载目标 Mod。
2. 拖入 PCL2，启动游戏。
3. 游戏报错，提示缺少前置模组，例如 flywheel、cloth-config。
4. 关闭游戏，手动搜索并下载对应版本的前置。
5. 重复上述步骤，直到所有依赖满足。

一个 Mod 可能携带 2 到 4 个前置依赖，且前置本身还可能有递归依赖。整个过程需要用户自行判断版本兼容性、加载器类型（Forge、Fabric、NeoForge），对新手极不友好，也是从"玩整合包"过渡到"自主搭配 Mod"的最大门槛。

PCL2 在安装整合包时已具备完整的依赖解析与自动安装能力，但单 Mod 安装场景下尚未复用这一能力，体验存在明显落差。

安装模组时，PCL2 应读取目标 Mod 的元数据文件，提取依赖声明。具体来说：

1. Fabric 加载器：读取 fabric.mod.json 中的 depends、recommends、suggests 字段。
2. Forge 加载器：读取 META-INF/mods.toml 中 dependencies 段内 mandatory 为 true 的条目。
3. NeoForge 加载器：读取 META-INF/neoforge.mods.toml，结构同 Forge。
4. Quilt 加载器：读取 quilt.mod.json 中的 depends、provides 字段。

解析应支持递归。若 A 依赖 B，B 依赖 C，则 B 和 C 均需纳入检测范围，构建完整依赖树。

对依赖树中的每一项，扫描当前实例的 mods 目录，判定其状态。具体分为以下几种情况：

1. 已安装且版本满足：本地存在该 Mod，且版本号在依赖声明的允许范围内。标记为"已满足"，跳过。
2. 已安装但版本过低：本地存在该 Mod，但版本低于依赖要求的下限。标记为"需更新"，提示升级。
3. 已安装但版本过高：本地存在该 Mod，但版本超出依赖声明的上限。标记为"版本冲突"，给出警告。
4. 未安装：本地 mods 目录中不存在该 Mod。标记为"待安装"，纳入下载列表。
5. 存在同名但加载器不匹配：本地有该 Mod 的 Forge 版，但当前实例为 Fabric。标记为"加载器不匹配"，提示替换。

检测方式：读取 mods 目录下所有 jar 文件的元数据（fabric.mod.json 或 mods.toml 等），提取 id 与 version 字段进行比对。

这是本功能的核心难点，需处理以下维度：

1. 依赖版本范围解析。依赖声明中通常包含版本约束，需正确解析。Fabric 格式例如 "大于等于 11.0.0"、"约等于 11.1"、"兼容 11.x"。Forge 格式为 Maven 风格区间，例如 "[11.0,12.0)" 表示大于等于 11.0 且小于 12.0。若依赖声明中无版本约束，仅声明了依赖 id，则取最新兼容版即可。

2. Minecraft 版本匹配。前置模组必须与当前实例的 MC 版本兼容。例如当前实例为 MC 1.20.1，目标 Mod 依赖 cloth-config，则应下载 cloth-config 的 11.x 分支（对应 MC 1.20.x），而非 13.x（对应 MC 1.21.x）。

3. 加载器类型匹配。同一前置模组在不同加载器下可能是不同的构建产物。例如 cloth-config 的 Fabric 版与 Forge 版是不同的 jar 文件，部分 Mod 仅提供单一加载器版本。需确保下载的前置与当前实例的加载器类型一致。

4. 前置之间的相互兼容。依赖树中的多个前置之间也可能存在版本约束。例如 Mod A 依赖 architectury 大于等于 9.0，同时依赖 cloth-config 大于等于 11.0，而 cloth-config 11.1 又声明依赖 architectury 大于等于 9.1。此时若自动选择 architectury 9.0，虽满足 A 的直接声明，却不满足 cloth-config 的间接要求。应取交集，选择 architectury 大于等于 9.1 的版本。

5. 与已安装 Mod 的兼容。新安装的前置不应破坏已有 Mod 的依赖关系。例如本地已有 Mod X 依赖 cloth-config 大于等于 11.0 且小于 11.2，新 Mod 要求 cloth-config 大于等于 11.1，则应选择 11.1.x 范围内的版本，而非直接安装最新的 11.3。若无法找到同时满足所有约束的版本，应明确提示冲突，由用户决定处理方式。

确认待安装和待更新的前置列表后，执行以下流程：

1. 通过 Modrinth API 或 CurseForge API 查询候选版本列表。

2. 按上述兼容性规则筛选出最优版本，优先选择最新兼容版。

3. 弹窗展示完整列表，供用户确认。列表应包含：模组名称、所需版本范围、本地当前状态（未安装/已安装某版本/版本过低等）、计划执行的操作（安装某版本/更新至某版本/无需操作/跳过）。

4. 用户确认后，批量下载并放入 mods 目录。

5. 若为"更新"操作，替换旧版 jar 文件。旧文件可移至 mods 目录下的 .backup 子文件夹以备回滚。

6. 无网络连接：仍解析本地依赖声明，列出缺失项，提示用户手动下载并给出下载链接。

7. API 查询无结果：提示"未在 Modrinth 或 CurseForge 找到该前置"，给出 Mod 名称供用户自行搜索。

8. 依赖存在但无兼容当前 MC 版本的构建：明确提示"该前置暂无对应 MC 版本"，建议用户检查目标 Mod 是否选对了版本。

9. 版本约束无解（循环冲突）：列出冲突链路，提示用户手动介入。

10. 可选依赖：recommends、suggests、optional 类依赖默认折叠显示，不自动勾选，用户可手动展开选择。

11. 下载源优先级：默认 Modrinth 优先、CurseForge 备选，允许用户在设置中调整。

12. 批量安装：用户一次拖入多个 Mod 时，应合并依赖树统一处理，避免重复下载。

13. 日志记录：每次自动安装或更新操作写入日志，便于出问题时回溯。

14. 回滚机制：更新前置前备份旧版文件，若游戏启动失败可一键还原。

15. Prism Launcher：安装 Mod 时自动提示并安装前置依赖，支持版本范围校验。

16. Modrinth App：基于 Modrinth API 实现完整依赖树解析与自动安装。

17. PCL2 自身：整合包安装流程中已实现依赖解析、版本匹配、批量下载逻辑。

单 Mod 安装是 PCL2 日常使用频率最高的操作之一。当前该流程缺少依赖自动处理能力，用户需手动完成"识别前置、判断版本、匹配加载器、逐个下载"的全部工作，门槛高、易出错。

本功能的核心难点不在于"下载"本身，而在于多维度的版本兼容性判定，包括依赖版本范围、MC 版本、加载器类型、前置间相互约束、与已有 Mod 的兼容。PCL2 在整合包安装中已积累了相关解析能力，将其扩展至单 Mod 安装场景，实现成本可控，用户体验提升显著。

[llsgllsg]

是不是发错地方了

[lactobionicAcid]

• 基于 Mod 网站数据检查 Mod 问题（重复/前置缺失/版本错误） #179
  自动检测缺失的前置 Mod，并在 Mod 管理页面提示 #6633

^{好浓的 AI 味……}