众所周知，NeoForge（以及 Minecraft Forge 本身）配置每个项目的开发环境时，都会跑一遍 NeoForm + NeoForge（对于 MCF 即为 MCP + Forge） 的 Rename + Decompile + Patch + Recompile。本人的电脑有幸被其中最耗费性能的 Decompile 环节差点卡死。
（看了一下，就 NeoGradle 有这个毛病，ForgeGradle 会把反编译结果扔到 ~/.gradle/caches/forge_gradle，是可复用的）
虽然 Architectury 工具链会把 MCP 的缓存和结果扔到 ~/.gradle/caches/fabric-loom 以让其他同版本的跨平台项目共用反编译+补丁后的 JAR 和源码，但是 Architectury 尚未完全支持 NeoForge（虽然他们正在搞），并且支持一个和 MinecraftForge 终究不太一样的平台需要改整套工具链的代码，所以短期还是无法将 Architectury 作为替代方案。
我的想法是：既然用同样的MC版本和同样的参数反编译出来的MC代码是一模一样的（毕竟人家 NeoForm 和 NeoForge 敢直接上 Patch），那么我们就可以整一个托管这些源码及其编译结果的静态网站，并通过 GitHub Actions 定期更新。
同时，整一个 Gradle 插件，用来修改 NeoGradle（以及(?) ForgeGradle）对应的 task，使其转而下载这个镜像站上的成品。（不阻止NG/FG下载NeoForm/mcp_config，但阻止它运行mcp_config，并重定向为下载成品）。
当然，为了避免公开分发 MojMaps 下的 Minecraft 源码带来的 EULA 及法律风险，应当使用某种准入手段。
目前我想到的就是通过加token。网站端怎么实现我没想好，但是用户端进行访问，我的想法是使用 HTTPS，但是将 token 作为 URL 的 username，或者作为 HTTP Header 的一部分。
个人精力有限，可能没有时间来完成这一项目。希望各位提出宝贵意见。
（看了一下，就 NeoGradle 有这个毛病，ForgeGradle 会把反编译结果扔到 ~/.gradle/caches/forge_gradle，是可复用的）
虽然 Architectury 工具链会把 MCP 的缓存和结果扔到 ~/.gradle/caches/fabric-loom 以让其他同版本的跨平台项目共用反编译+补丁后的 JAR 和源码，但是 Architectury 尚未完全支持 NeoForge（虽然他们正在搞），并且支持一个和 MinecraftForge 终究不太一样的平台需要改整套工具链的代码，所以短期还是无法将 Architectury 作为替代方案。
我的想法是：既然用同样的MC版本和同样的参数反编译出来的MC代码是一模一样的（毕竟人家 NeoForm 和 NeoForge 敢直接上 Patch），那么我们就可以整一个托管这些源码及其编译结果的静态网站，并通过 GitHub Actions 定期更新。
同时，整一个 Gradle 插件，用来修改 NeoGradle（以及(?) ForgeGradle）对应的 task，使其转而下载这个镜像站上的成品。（不阻止NG/FG下载NeoForm/mcp_config，但阻止它运行mcp_config，并重定向为下载成品）。
当然，为了避免公开分发 MojMaps 下的 Minecraft 源码带来的 EULA 及法律风险，应当使用某种准入手段。
目前我想到的就是通过加token。网站端怎么实现我没想好，但是用户端进行访问，我的想法是使用 HTTPS，但是将 token 作为 URL 的 username，或者作为 HTTP Header 的一部分。
个人精力有限，可能没有时间来完成这一项目。希望各位提出宝贵意见。