docker-minecraft-server项目中的CurseForge依赖排除机制缺陷分析

在docker-minecraft-server项目中，当使用AUTO_CURSEFORGE类型安装Modpack时，发现了一个关于依赖排除机制的重要缺陷。该问题表现为：当指定的排除项与CurseForge平台上的其他项目（如Modpack）具有相同slug时，排除机制可能会错误地匹配到非预期的项目。

问题现象

在配置文件中使用CF_EXCLUDE_MODS参数指定需要排除的mod时，系统会通过slug（URL标识符）来查找对应的mod ID。然而，当前实现存在一个关键问题：它没有限定只搜索mod类别，导致可能匹配到同名的modpack或其他类型项目。

以"lighty"为例：

• 期望排除的是ID为986380的mod
• 实际却匹配到了同名的modpack项目

技术原理

CurseForge API允许通过slug查询项目ID，但默认不区分项目类型。在Minecraft生态中，mod和modpack使用相同的slug命名空间，这就导致了潜在的冲突。

当前实现直接调用slugToId方法进行转换，没有添加任何类型过滤条件。这种方法在遇到同名不同类项目时就会出现错误匹配。

解决方案

正确的实现应该：

1. 明确限定只搜索mod类别（categoryClassId=6）
2. 使用专门的mod搜索接口而非通用slug转换
3. 在结果处理时验证项目类型

具体到代码层面，应该：

• 使用searchMod方法替代slugToId
• 在查询参数中明确指定mod类别
• 对返回结果进行类型验证

影响范围

该缺陷影响所有使用以下配置的情况：

• 使用AUTO_CURSEFORGE安装方式
• 通过CF_EXCLUDE_MODS指定要排除的mod
• 排除项的slug与平台上其他类型项目重名

最佳实践建议

在实际使用中，建议：

1. 尽可能使用项目ID而非slug进行排除
2. 对于必须使用slug的情况，检查是否有重名风险
3. 定期验证排除列表的实际效果

这个问题的修复将提高mod依赖管理的准确性，确保自动化安装过程按预期工作。