# 加载器差异与后端设计（实测）

用户判断（2026-09-25）：**mod 支持分 fabric/forge，两者不同版本还有差异，
所以各应有一个独立后端。** —— 实测支持这个结论，且差异比"方法签名"更深一层。

## 实测：Fabric 客户端能启动（2026-09-25）

命令（成功的形态）：

```
# ★ 必须剔除 1.20.1 自带的 asm（9.2 + 9.6 两版并存），改用 Fabric 的 asm 9.10.1
#   否则 Knot.<clinit> 抛 "duplicate ASM classes found on classpath"
grep -v "/org/ow2/asm/" vanilla_libs.txt > base.txt
CP="$(paste -sd: base.txt):fabric-loader:asm*:sponge-mixin:intermediary:1.20.1.jar"
DISPLAY=:98 java -cp "$CP" -Djava.library.path=nativ \
    net.fabricmc.loader.impl.launch.knot.KnotClient --gameDir ... --assets ... --assetIndex 1.20.1
```

实测输出（证明真的启动了）：

```
[main/INFO]: Loading Minecraft 1.20.1 with Fabric Loader 0.19.5
[main/INFO]: SpongePowered MIXIN Subsystem Version=0.8.7 ... Env=CLIENT
[Render thread/INFO]: Created: 1024x512x4 minecraft:textures/atlas/blocks.png-atlas
... 共 12 个资源图集
```

Fabric 必需的 8 个库（从 meta API 的 profile 拿，**纯声明式**）：
asm / asm-analysis / asm-commons / asm-tree / asm-util /
sponge-mixin / intermediary / fabric-loader

## 为什么加载器必须各有独立后端（不只是版本差异）

| | vanilla | fabric | forge |
|---|---|---|---|
| 主类 | **我们自己的** `McfoldRenderServer` | `KnotClient`（固定，不可替换） | ForgeWrapper → FML |
| 我们的代码形态 | 直接 `new Minecraft(cfg)` | **必须作为 mod 被加载** | 必须作为 coremod/mod |
| 命名空间 | Mojang official（已反混淆） | **intermediary**（运行时重映射） | SRG/TSRG |
| 起 Minecraft 实例 | 自己 new | 由 Loader 创建，我们**拿不到控制权** | 同 fabric |

★ 关键：Fabric/Forge 下**我们不拥有启动流程** —— Loader 起游戏、进主菜单、
  跑主循环。我们的「不跑主循环 + 手动喂世界数据」模型与它们**根本冲突**。

所以后端身份是 **(加载器, API 世代)** 二元组：

```
vanilla:
  gen_1_20        已实测（渲染通过）
  gen_1_21        已实测（渲染通过）
fabric:
  gen_1_20        待设计（架构与 vanilla 不同，见下）
  gen_1_21        待设计
forge:
  gen_1_20        待设计
  gen_1_21        待设计
```

## ✅ 已实测落地：路线 C（`Knot.init()` + `loadIntoTarget()`）

**上面的 A/B 都不是实际采用的 —— 两者都假设了「游戏由 Loader 起」，
而 `Knot.init()` 是 public 的，它做完 mod 加载 + mixin 后**返回**，
根本不需要进入官方主循环。**

```
LoaderBoot.main:
  ① Knot knot = new Knot(EnvType.CLIENT)
  ② ClassLoader cl = knot.init(args)     ← 发现 mod / 建 KnotClassLoader / 应用 mixin
                                             / invokeEntrypoints(preLaunch)
                                             **不**启动官方主循环（那在 GameProvider.launch()）
  ③ knot.loadIntoTarget("McfoldRenderServer")
     → 把我们的服务端注入**同一个** KnotClassLoader（与 mod 共享 classloader 与 mixin）
  ④ 调用它的 main → 我们的渲染服务照常跑
```

★ 关键：**mod 生态与我们的控制权可以同时拿到** —— 不需要把服务改写成 mod。

### 实测结果（`tests/test_loader_render.py`，6/6 绿）

```
[loaderboot] KnotClassLoader = net.fabricmc.loader.impl.launch.knot.KnotClassLoader
[loaderboot]   mod fabricloader 0.19.5 / java 21 / minecraft 1.20.1 / mixinextras 0.5.5
[loaderboot] 注入 McfoldRenderServer 到 KnotClassLoader
{"event":"ready"}  {"ok":true,"sectionsCount":24,…}
渲染: chunks=10..25  colors=4391..4547
```

### 两个必需条件（缺一则我们的 named 代码在加载器下跑不起来）

1. classpath 放**反混淆后的** client jar（`client-named.jar`），不是官方 obf jar
2. `-Dfabric.gameMappingNamespace=named`

否则游戏被 remap 成 intermediary，堆栈里是 `enn.<init>`，
我们的代码抛 `NoClassDefFoundError: net/minecraft/client/Minecraft`（实测）。

### ★ 第三个必需条件：asm 必须只留一份

1.20.1 自带 asm **9.2 与 9.6 两版并存**，与 Fabric 的 9.10.1 同时在场会让
`Knot.<clinit>` 抛 `duplicate ASM classes found on classpath`。

⇒ 这两步（去 asm + 加 Fabric 8 库）已**从用户手里移到后端**：
`RenderBackend._fabric_classpath()` 自动完成（67 → 68 条：去 7 asm，加 8 fabric）。
Fabric 库放在内容根 `.mcfold/fabric/`（随版本隔离，不再散在 /tmp）。

### 可判差异：加载器 vs 零加载器

两条路线不是「高级/低级」，而是**能做的事不同**：

| | 零加载器（`cmd=mods`） | Fabric 加载器 |
|---|---|---|
| 方块外观 / state id | ✅ | ✅ |
| mod 的硬依赖校验 | ❌ 无脑注册 | ✅ **会拒绝** |
| mixin 变换 | ❌ | ✅ |
| Iris 光影 | ❌ | 待验 |

The negative control proves this: `Explorify`（依赖 `fabric-api`，缺失）在 Fabric 下被**拒绝** ——
而 vanilla 那条「无脑注册」路线根本无从知道这件事。

## 仍未做

```
Iris 光影加载        —— 加载器已通，但未验过一次真实 shader pack
forge / neoforge     —— gen_1_20 / gen_1_21 均待设计
```

## 当前已具备的零加载器能力（不依赖加载器）

`cmd="mods"`（已在两个 vanilla 后端实现，实测通过）：
Java 侧自己扫 mods 目录 → 读 jar 的 `assets/<ns>/blockstates/*.json`
→ 解冻 BLOCK 注册表 → 注册占位方块 + state → jar 挂为资源包。

覆盖范围（诚实标注）：
  方块**外观** ✅ / state id ✅ / 变体属性 ⚠️ / 行为 ❌ / Iris 光影 ❌