在 spring boot graphql 中可选参数的正确处理方式是在 spring boot 的 graphql 服务中，需通过 kotlin 的可空类型（如 `int?`）或 java 的包装类（如 `integer`）来安全接收可选参数，避免因缺失字段导致的解析异常。
Spring Boot 官方 GraphQL 支持（基于 GraphQL Java 和 Spring for GraphQL）要求所有 @Argument 参数必须严格匹配 GraphQL 查询中传入的字段。若 schema 中某参数定义为可选（即未加 ! 非空修饰），但 Java 方法中使用了基本类型（如 int、boolean），则当客户端未提供该参数时，GraphQL 执行器无法将 null 赋值给基本类型，从而抛出 CoercingParseValueException 或类似运行时异常。
✅ 正确做法是：使用对应的包装类型（Java）或可空类型（Kotlin）。
✅ Java 方案（推荐）
@QueryMapping public ListgetRecord( @Argument String email, @Argument int dateFrom, @Argument Integer dateTo) { // ← 使用 Integer 而非 int int actualDateTo = (dateTo != null) ? dateTo : 0; // 提供默认逻辑 return repository.findSpecific(email, dateFrom, actualDateTo); }
注意：@Argument Integer dateTo 允许 GraphQL 传入 null，且无需额外注解（如 @RequestParam）——后者仅适用于 REST 控制器，不适用于 GraphQL 端点。
✅ Kotlin 方案（更简洁）
@QueryMapping
fun getRecord(
@Argument email: String,
@Argument dateFrom: Int,
@Argument dateTo: Int? // ← 可空 Int，自动支持 null
): List {
val actualDateTo = dateTo ?: 0
return repository.findSpecific(email, dateFrom, actualDateTo)
} ⚠️ 注意事项
- 不要混用 @Argument 和 @RequestParam：后者属于 Spring MVC，GraphQL 请求不经过 Servlet 容器的请求参数解析流程，因此 @RequestParam 在 @QueryMapping 方法中完全无效。
- Schema 必须与实现一致：例如，GraphQL SDL 中应定义为 dateTo: Int（可选）而非 dateTo: Int!（必填），否则客户端强制传值，失去“可选”意义。
- 方法重载不可行：Spring GraphQL 的 @QueryMapping 不支持基于参数数量/类型的重载解析，会引发 AmbiguousMappingException。
✅ 总结
处理 GraphQL 可选参数的核心原则是：让方法参数类型能容纳 null 值。Java 用 Integer / Boolean / String（本身引用类型）等包装类；Kotlin 直接用 Type? 语法。配合合理的空值处理逻辑（如 Elvis 运算符或三元判断），即可健壮、清晰地支撑灵活的查询契约。
