为何匿名类型与ValueTuple的AssemblyQualifiedName不一致？如何在程序集中匹配目标类型

两种路径生成的AssemblyQualifiedName字符串从设计上就不会完全相等，核心差异集中在泛型类型的泛型参数表示部分，这种差异不是程序集加载异常导致的bug，是CLR的固有行为：

• 从已实例化的类型对象获取AssemblyQualifiedName时，运行时会对泛型参数的类型引用做简化处理：只要泛型参数的类型已经被当前程序集加载上下文解析过，就会省略该参数对应的完整程序集标识（包括程序集名称、版本号、区域信息、公钥标记），只保留参数的类型全名。
• 从程序集的GetTypes()方法枚举类型时，拿到的是元数据层面存储的原始类型结构，它生成的AssemblyQualifiedName会严格按照元数据中的引用记录，为每个泛型参数拼接完整的程序集标识，不会做任何简化处理。

两类字符串的实际差异可以通过对比直观体现：

• 从实例拿到的简化版AAN：<>f__AnonymousType01[[System.String]], TestAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null`
• 从GetTypes()枚举得到的原始版AAN：<>f__AnonymousType01[[System.String, System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a]], TestAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null`

两类字符串的差异完全集中在泛型参数的程序集标识部分，直接做全等匹配自然永远无法命中。

为什么Type.GetType(assemblyQualifiedName)可以正常定位类型？
因为该方法的字符串解析逻辑内置了兼容机制：它不需要你提供完整的泛型参数程序集标识，会自动结合当前程序集的加载上下文补全省略的信息，完成类型匹配。这种兼容逻辑不会延伸到直接的字符串全等比对上。

为什么ValueTuple场景会出现完全相同的问题？
因为ValueTuple本身就是特殊结构的泛型值类型，元数据中存储的泛型参数引用逻辑和普通泛型类型、匿名类型完全一致，简化AAN和原始AAN的字符串差异规则完全相同，自然也会出现匹配失败的问题。

• 最通用的可靠方案：放弃AssemblyQualifiedName字符串全等比对，直接利用CLR的类型单例特性做引用相等判断。同一个程序集中加载的类型对象是全局唯一的，不管它的字符串表示如何生成，引用地址完全一致。测试代码中拿到的type实例，和GetTypes()枚举出来的同类型对象，本来就是同一个CLR对象，直接判断x == type就能命中，不需要拼接字符串。
• 如果没有现成的类型实例，需要通过特征检索目标类型：
  • 针对匿名类型：先通过编译器生成特征做初步筛选，比如判断类型是否是非公共密封类、名称是否符合<>f__AnonymousType*的生成规则，再逐一核对类型的公共属性的名称、声明顺序、属性类型组成，匿名类型的唯一性完全由这组结构特征决定，和字符串表示无关。
  • 针对ValueTuple：先判断类型是否是泛型结构类型，再通过ValueTuple的泛型参数结构对比，匹配预期的元组类型组成，不需要依赖字符串比对。
• 如果必须做字符串匹配：不要直接对AssemblyQualifiedName做全等判断，可以先将两边的字符串通过Type.GetType()分别解析为类型对象，再通过引用相等判断是否为同一类型，避免因为格式差异出现误判。

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