HUDCachingEarlyReturnTransformer

基本信息

属性	值
类	`...loading.fml.compat.transformers.generic.HUDCachingEarlyReturnTransformer`
路径	`src/main/java/com/gtnewhorizons/angelica/loading/fml/compat/transformers/generic/HUDCachingEarlyReturnTransformer.java`
行数	42
类型	`public class`（`:16`），不实现 `IClassTransformer`
入口签名	`public static void transform(ClassNode cn, List<String> patchMethods)`（`:20`）
硬编码目标	`:18` `com/gtnewhorizons/angelica/hudcaching/HUDCaching$HUDCachingHooks`
数据来源	ICompatHandler.getHUDCachingEarlyReturn()

它是什么 / 挂在哪个阶段

4 个 generic/ transformer 中最小的（42 行），也是唯一不做 obfuscation 处理的（无 AngelicaClientTweaker.obf 调用）。被 GenericCompatTransformer :80-82 调用，跑在 LaunchWrapper 类加载期；RFB 路径不提供。

它改写什么

对 patchMethods 列出的每个方法，在指令序列最开头（method.instructions.insert(list)，:38）插入 4~6 条指令：

INVOKESTATIC  HUDCaching$HUDCachingHooks.shouldReturnEarly()Z
IFEQ          exitLabel
  <返回类型分派>
exitLabel:

返回类型分派（`:25-36`）

描述符结尾	注入	行
`Z` 或 `I`	`ICONST_0` + `IRETURN`	`:26-28`
`V`	`RETURN`	`:29-30`
其他	`LOGGER.warn("HUDCaching Conditional Return - Unknown return type: {}#{}:{}", ...)` 并 `return`	`:31-35`

与 TileEntityNullGuardTransformer 的差异

两个类结构高度相似（模式匹配 → 返回类型分派 → 未知类型则 return），但注入位置不同：

	HUDCachingEarlyReturn	TileEntityNullGuard
注入位置	方法开头（无条件执行）	`ASTORE` 之后（模式匹配驱动）
触发条件	方法名在表中	字节码含 `getTileEntity`+`CHECKCAST`+`ASTORE`
是否用 `obf()`	否	是（`getTileEntity`/`func_147438_o`）
行数	42	94

HUDCaching 走「方法开头无条件插入」是因为判断本身是一次静态方法调用（shouldReturnEarly() 读标志位），不需要字节码模式分析。

已知问题

未知返回类型时 return 丢弃该方法的剩余匹配（:34）。由于 transform 是外层 for (MethodNode method : cn.methods) 循环，被 return 抛出的是整个类的处理，而非仅当前方法——即一个类里有 2 个目标方法、第 2 个返回类型不支持，第 1 个方法已经注入的补丁会保留，但第 1 个方法里若有多个匹配点只处理了第一个……实际上因为是方法开头插入，语义仍正确；但该类其余目标方法全部不再处理。这是真实缺陷。
shouldReturnEarly() 在每个目标方法的每次调用都执行一次静态方法调用，即使 HUDCaching 未启用（:22）。缓存未命中时这是一次可忽略但非零的额外调用。
目标类名硬编码在 :18，不能通过配置替换。
RFB 路径完全失效——这是本 transformer 最大的实际影响：装 RFB 时 Thaumcraft 与 ThaumicHorizons 的 HUDCaching 补丁不生效。

耦合点

HUDCaching$HUDCachingHooks.shouldReturnEarly() 是唯一跨子系统依赖点，指向 HUDCaching 的内部类（:239）。数据提供方恰好 2 个 handler，且都是 renderOverlay。