加载TypedEvolutionLookup泛型结构体触发TypeLoadException问题排查

核心原因 #

• 循环泛型类型引用触发加载死锁：你的TypedEvolutionLookup<T>是只读泛型结构体，其OtherCommands属性直接引用了自身泛型类型（比如ImmutableArray<TypedEvolutionLookup<int>>）。.NET的类型加载器在解析这种循环依赖的泛值类型时，会陷入“加载类型需要先解析成员类型，成员类型又依赖未加载完成的自身类型”的死循环，最终抛出TypeLoadException，且因为是加载阶段异常，所以没有代码执行栈和行号。
• 只读结构体的编译优化放大问题：readonly struct的编译器优化（比如内存布局、不可变性校验）会改变类型元数据的生成逻辑，和循环泛型引用结合后，更容易触发类型加载的异常路径，而普通类或非只读结构体的加载逻辑更宽松，所以其他类型无此问题。

可行解决方法 #

• 打破循环引用链
  • 引入抽象接口：定义一个非泛型接口ITypedEvolutionLookup，让TypedEvolutionLookup<T>实现该接口，将OtherCommands的类型改为ImmutableArray<ITypedEvolutionLookup>，通过抽象层切断直接的自身泛型引用。
  • 增加包装类型：创建一个泛型包装类EvolutionLookupWrapper<T>，内部持有TypedEvolutionLookup<T>实例，将OtherCommands改为ImmutableArray<EvolutionLookupWrapper<T>>，通过中间类型间接关联自身。
• 临时切换类型定义：如果业务逻辑允许，将readonly struct改为class，类的类型加载机制不限制这种循环泛型引用，能快速验证问题根源，后续再根据需求调整回结构体（需配合打破循环引用的方案）。
• 统一程序集和包版本
  • 检查所有项目对Brendan.IC.Typed程序集的引用，确保版本完全一致，避免跨项目引用不同版本导致类型元数据不匹配。
  • 统一System.Collections.Immutable包的版本，在解决方案级管理包版本，消除包版本冲突带来的类型加载异常。
• 强制类型加载顺序：在控制台应用的Main方法最开始，先手动触发基础类型的加载，比如先执行typeof(ITypedEvolutionLookup)（如果定义了接口），再执行typeof(TypedEvolutionLookup<int>)，强制类型加载器先完成依赖类型的初始化，避免加载死锁。

内容的提问来源于stack exchange，提问作者Brendan Lynn