评价 Forbric Mod Loader，最爱炒作，最爱许愿的模组加载器

本文首发于：https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/issues/59

本站的版本为补充了上下文的版本，原始版本请前往仓库查看

Forbric是一个由哔哩哔哩上的炒作狗RayT_RT制作的文不对题的狗屎模组加载器，声称自己完成了三大模组加载器的世纪和解，大一统，在评论区获得了极高的评价，虽然这个东西就是兼容性非常狗屎但是我描述了这个问题之后作者决定给我写的小作文Closed as not planned，本文将向你讲述他到底是什么东西。

首先这是一个正宗老狗屎，堪比我声称我统一了Windows、MacOS、Linux制造了一个叫做Winacunix的作业系统，然后这个作业系统有Windows的体积和响应速度、MacOS的软件生态和游戏性能、Linux的驱动支持。集成百家之短，去其精华，取其糟粕。

现在你不可能使用这个狗屎运行任何整合包或者高级mod，可能作者许愿时候已经想到要让哪些东西一起运行了可惜并没有成功，因为作者完全低估了做这个事情的难度和施工范围，可能在订阅了Claude Max之后直接开启了/loop开始力大砖飞迭迭代代，最终成功制作出了这个雷霆大肥美狗屎。

笔者看到有人在https://github.com/Ray-T-r/Minecraft-Forbric-mod-loader/issues/39 制作了一个“与此同时这是Forbric”图片

但是笔者认为这完全是因为这个图片的作者过于客气，这张图片甚至有点捧他了因为如果他能完成这三样东西的任何一样功能那他都不算失败，以下是笔者使用PowerPoint™在5普朗克时间内制作的更加准确的图片

在26.1之前，Minecraft的jar是有混淆的，然后forge和fabric分别使用srg和intermediary两种运行时Mapping，无论你使用Mojang或者Yarn Mapping进行开发，最后运行时都会转换为这两种运行时Mapping，运行时Mapping在不同的minor版本中保持稳定，这样模组有机会跨版本，比如1.18.1和1.18.2的Mapping就是兼容的，有这套做法极大的增加了作者在以前的版本的施法难度，但是由于Minecraft取消混淆，26.1开始forge和Fabric都不再有运行时Mapping，因为他没有Sinytra Connector的智慧来战胜运行时Mapping，所以他只能在26.1出现之后跳出来制作这个屎。

这个老猎奇东西应该算是吃到intermediary或者srg退网的红利了，如果有intermediary这个屎十万年之内都做不出来这个东西（的完美实现），因为你无论使用多少大语言模型代币进行力大砖飞行动都无法给所有用intermediary命名反射的mod进行妥善处理，所以这个东西可能在五个地质年代之内都不可能顺利backport到26.1以下因为以前有很多mod喜欢直接反射intermediary或者srg，他可能遭遇了一万层以上面向对象包装所以你的溜溜梅根本无法根据引用（reference）来判断，而且这个ModLoader本身没有任何跨版本架构设计，然后修复兼容性问题也是针对某一个mod的特定版本进行修补听起来就非常痛苦因为实际上你无法解决所有mod里的奇妙写法，也就是你即将不得不抛弃mod生态最肥美的1.20.1和1.21去玩这个Mojang跟风苹果使用的年份命名版本和这个发展程度堪比海地共和国的版本就爲了使用这个雷霆东西。

所以笔者认为，本项目的视频和读我.妈的以至于这个项目的名字都涉嫌了虚假宣传，虽然本项目叫Forbric听起来非常美妙，健壮性非常好，但是实际上他的兼容性完全就是一个屎，文不对题，既不能顺利执行Forge或者NeoForge的功能，也不能顺利的执行Fabric的功能，就像朝鲜民主主义人民共和国并不民主主义、也不是人民共和国一样。

然而令人蒙古的是虽然《我的世界》在26.1以上并没有混淆，但是笔者在观赏使用患有创伤后应激障碍并且不太喜欢写缩进的大语言模型生成式预训练转换器编写的神秘代码时，还是在代码中莫名其妙发现了intermediary映射相关的代码，也许是以后打算兼容一下迷你世界然后证明萌趣的世界才受大众喜爱什么的。

正在GitHub上和网友汴京的作者

第一次启动Sodium（NeoForge）版本我居然惊讶的发现这个NeoForge版本的Sodium想在这个mod发射台上启动居然他妈的需要安装Fabric API，虽然我猜这大概是Sodium不认为自己运行在NeoForge了比如你成功误导了Class.forName什么的或者你的polyfill大全成功给默认渲染器Indigo操飞了导致的，我不太理解这是什么操作逻辑但是只能尊重一下了，于是决定安装一下FabricAPI令人蒙古的是FabricAPI里的组件都能加载失败四个，造成了加载两个mod失败四个mod的奇景。

这个现象进一步证明了我的观点，就是你永远无法打过所有mod的奇怪写法，你只能挨个修补，如果要维护多个版本那更是地狱难度，你可能想说你可以不维护旧版本，但是你这个东西只要不维护就永远有你不知道的mod里的写法恶心你。

说起AI开发大伙都在骂我说实话没什么意见，但是有一个严肃的问题，就是你的Harness验收标准可能不太符合一个科学的提示词工程思想，就是你的测试标准是能进世界并且Mixin注入进去了从你不知道是不小心还是故意的commit上来的一些文档可以看出，很显然这个验收方案只适用于渲染类mod比如Sodium，大部分mod实现的功能可能都无法验证，也就是mod运行时的问题可能需要人工或者靠受害者提交issue来找到，毕竟现在溜溜梅的视觉能力可能对这些mod是否工作正确没有任何识别方法。

然后这个modloader的兼容性也是非常的诡异，在我安装了一个Modrinth定位为Utility的Mod也就是甚至没有在《我的手艺》里添加很多新物品新方块精密机器的ViaFabricPlus之后弹出了一个崩溃甚至让我游玩六年《我的手艺》第一次见这个诡异的弹窗大半夜给我睾丸吓爆一颗，导致我以前和我老婆平均有一颗睾丸，现在我和我老婆平均只有0.5颗睾丸了。

请注意这是一个Fabric mod弹出来的

当然笔者喷了这么多肯定会有人说我是杠精，接下来笔者给作者提供一个解决方案，是笔者没有消耗任何token使用大脑想出来的。

对于反射intermediary/srg笔者认为可以通过给所有反射相关的API（例如getMethod，getField）在加载类过程中使用ASM Transformer进行劫持到你自己的API（例如ForbricReflection.getMethod()），这样他输入的就是最终拼接的引用，这样你可以不用任何启发式分析就可以backport你的力作到1.20.1这样的肥美版本了，还可以节省你的Claude Max订阅代币。

当然对于奇妙写法的处理笔者也没有启发式分析以外的方案，除非你直接研发一个接入OpenAI兼容API就可以让溜溜梅来自动操字节码运行时修复冲突，所以这大概是无解的，这个项目大概在家用显卡推理DeepSeek 671B速度达到350tps来修复字节码之前都不能上桌生产环境，也就是大概无法完美运行任何整合包，笔者建议直接去寻找最适合你的用户群体，只要Mod协议的CustomPayload工作正常能在服务器里游玩就行了的用户群体，也就是那些想在整合包服务器里开挂的神经病们，这样你就可以在NeoForge整合包服务器里开LiquidBounce了，毕竟外挂是最不吃ModLoader特性的，只靠Mixin来挂载hook。

什么？你的modloader连LiquidBounce都加载不了。？那没事了。！

然而你点击了继续启动还是会崩溃因为其实他会在加载Fabric Kotlin Language决定崩溃一下

你就缝吧，三个事件巴士一点都不累，大Max猛蹬，大token猛烧，给GitHub上灌输更多狗屎。