Java注解处理器数据模型：TypeElement与TypeMirror对比选型

TypeElement作为数据模型的优势 #

• 跨处理轮次稳定可用：注解处理是多轮执行的，TypeMirror属于当前轮次的临时类型视图，轮次切换后可能失效，直接存储会偶发IllegalStateException。TypeElement是Java元素的持久化元数据表示，只要类结构不变，跨任意轮次都能正常读取，适合需要多轮复用数据模型的场景。
• 可直接获取类的完整声明信息：无需额外转换就能拿到类的全限定名、修饰符、声明的注解、内部字段/方法/内部类等信息，比如调用getEnclosedElements()就能遍历类的所有成员，比从TypeMirror反向解析效率高很多。
• 类型判断更严谨：要判断类的继承关系、接口实现、是否为某个特定类的派生类时，TypeElement提供的getSuperclass()、getInterfaces()返回的信息不受使用处泛型参数的影响，不会出现泛型擦除导致的误判。
• 消除类型引用歧义：如果拿到的TypeMirror是泛型参数、通配符、参数化类型等非原始声明类型，直接存储后续处理很容易出错，转成TypeElement可以明确指向类型的原始声明节点，不受使用场景的类型参数干扰。

TypeMirror作为数据模型的优势 #

• 保留使用处的完整类型信息：比如你拿到的是Map<String,User>的类型，直接存TypeMirror的话，传给JavaPoet的API可以直接生成带完整泛型的代码。如果转成TypeElement只会保留Map的原始类型信息，泛型参数会丢失，需要额外存储泛型相关的元数据。
• 对接JavaPoet的成本更低：JavaPoet的TypeName.get()原生支持TypeMirror作为入参，不需要写额外的转换逻辑，减少编码量的同时也避免了类型转换过程中可能出现的错误。
• 支持全类型场景覆盖：TypeMirror可以表示所有Java类型，包括原生类型、数组、泛型参数、通配符、void等，TypeElement只能表示类、接口、枚举、注解这几种声明式元素，如果你要处理的类型包含上述非声明类型，只能选择存储TypeMirror。
• 简单类型校验更高效：比如判断某个参数是不是int类型、是不是数组、是不是通配符类型，直接读取TypeMirror.getKind()就能快速判断，不需要做类型转换。

实践建议：如果你的数据模型只需要记录原始类的声明元数据，需要跨轮次复用，优先选TypeElement；如果生成代码时需要保留使用处的具体类型（比如带泛型的参数/返回值），不需要跨轮次存储，直接存TypeMirror更省心。

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