GraphQL Schema不支持泛型，必须用具体类型建模：如BookProduct、ElectronicsProduct；集合用[Product]表示；Optional<T>映射为nullable字段；Java Bean需避免泛型字段，改用DTO；泛型接口需TypeResolver区分实现；泛型工具类仅限DataFetcher内部使用。
GraphQL 的 Schema 本身不支持泛型语法（比如 Product<t></t> 或 List<product></product> 中的类型参数），它只认具体、静态的类型定义。Java 中的泛型在运行时被擦除（type erasure），所以不能直接“映射”泛型结构到 GraphQL Schema —— 必须转为具体类型再建模。
用具体类型替代泛型声明
GraphQL SDL 不允许写 type Product<t></t>，也不支持模板参数。你需要为每种实际使用场景定义明确的类型：
- 如果业务中有
Product<Book>和Product<Electronics>，就分别定义BookProduct和ElectronicsProduct类型 - 如果只是包装集合（如
List<Product>），GraphQL 原生用[Product]表示即可，无需泛型标记 - 字段返回
Optional<User>？Schema 中仍定义为user: User，并靠 nullable 字段修饰符（User非强制加感叹号）表达可空性
Java Bean 映射要避开泛型字段
GraphQL Java 默认用 PropertyDataFetcher 反射读取 getter，但它无法处理泛型擦除后的字段，例如：
❌ 不推荐：private List<String> tags; —— 虽然能序列化，但若 tags 是 Map<String, Object> 或嵌套泛型（如 List<Map<String, List<Integer>>>），容易触发 ClassCastException 或字段丢失
✅ 推荐做法：
立即学习“Java免费学习笔记（深入）”；
- 用具体 DTO 类替代泛型容器：比如定义
ProductTags类封装 tag 列表，而非直接暴露List<String> - 所有响应字段对应 Java Bean 的属性名必须与 Schema 字段名一致（大小写敏感），且类型需可被 Jackson / graphql-java 序列化器识别
- 避免在顶层 Resolver 返回
new ArrayList<>()这类裸泛型集合；改用带类型信息的 POJO 或 record
泛型接口/抽象类需靠 TypeResolver 区分实现
如果你有泛型基类（如 ApiResponse<T>），实际不能作为 GraphQL 类型直接暴露。常见解法是拆解：
- 定义具体响应类型：如
ProductResponse、UserResponse，各自包含data: Product!或data: User! - 若必须统一响应结构（如 REST 风格的
{"code":200,"data":{...}}），GraphQL 更倾向把code和data拆成 Query 的并列字段，或用 Union 类型（如Response = Success | Error），再配合TypeResolver动态判断返回的是哪种子类型 - Union 或 Interface 类型不关心 Java 泛型，只依赖运行时对象的实际 class，因此
ApiResponse<Product>和ApiResponse<User>实例需由TypeResolver分别映射到ProductResponse和UserResponse类型
泛型工具类不影响 Schema，但影响 DataFetcher 编写
Java 层可以用泛型工具方法复用逻辑（如通用分页查询、统一异常包装），但这些泛型不进入 Schema 构建流程：
-
DataFetcher内部可用<T> List<T> fetchByType(Class<T> type)，只要最终返回的对象结构匹配 Schema 定义的字段即可 - 避免在
RuntimeWiring中硬编码泛型类型字符串（如"List<Product>"），graphql-java 不识别这种写法 - Schema 解析阶段只认 SDL 文本或 Java 构建的
GraphQLObjectType，和 Java 源码里的泛型声明无关
