当 graphql 字段类型为 string 但实际需返回结构化 json 对象时，graphql 会将其序列化为带双引号和转义符的字符串字面量；解决方法是将该字段定义为自定义对象类型，而非 string。
当 graphql 字段类型为 string 但实际需返回结构化 json 对象时，graphql 会将其序列化为带双引号和转义符的字符串字面量；解决方法是将该字段定义为自定义对象类型，而非 string。
问题本质在于类型语义错配：你的 payload: String 字段在 GraphQL Schema 中声明为纯字符串，因此即使 Java 后端传入的是合法 JSON 字符串（如 {"logo": "https://www.php.cn/link/bb859699a1e4fc28c59162684235a28c", ...}），GraphQL 执行器仍会将其作为字符串值整体编码——即对内部引号、换行等字符进行 JSON 转义，并包裹外层双引号，最终导致前端收到的是一个被双重编码的字符串（例如 "{ \"logo\": \"...\" }"），而非可直接访问的 JSON 对象。
✅ 正确做法是让 GraphQL 类型系统准确反映数据结构。你需要定义明确的 schema 类型，替代模糊的 String：
type Payload {
logo: String!
name: LanguageSpecificContent!
copyrightText: LanguageSpecificContent!
help: String!
termsAndCondition: String!
}
type LanguageSpecificContent {
en: String!
ja: String!
}同时更新 StringApiResponse 定义：
type StringApiResponse {
statusCode: String!
message: String!
timestamp: String!
payload: Payload # ← 不再是 String！
}在 Java 端，对应地使用强类型对象（如 Lombok 的 @Data POJO 或 Record）替代 String 类型的 payload：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
public record Payload(
String logo,
LanguageSpecificContent name,
LanguageSpecificContent copyrightText,
String help,
String termsAndCondition
) {}
public record LanguageSpecificContent(String en, String ja) {}
// 在 Resolver 中：
@QueryMapping
public StringApiResponse getValue() {
String rawJson = ValueService.getValue(); // 假设返回原始 JSON 字符串
// ✅ 关键：解析为 Java 对象，而非保留为 String
Payload payload = new ObjectMapper().readValue(rawJson, Payload.class);
return StringApiResponse.builder()
.statusCode("S0000")
.message("Success")
.timestamp(Instant.now().toString())
.payload(payload) // ← 传递对象，非字符串
.build();
}这样，GraphQL 执行器会递归序列化 Payload 及其嵌套结构，生成原生 JSON 对象响应，不再出现多余转义：
{
"data": {
"getValue": {
"payload": {
"logo": "https://www.php.cn/link/bb859699a1e4fc28c59162684235a28c",
"name": { "en": "AAA", "ja": "aaa" },
"copyrightText": { "en": "AAA", "ja": "aaa" },
"help": "http://help",
"termsAndCondition": "http://terms"
}
}
}
}⚠️ 注意事项：
- ❌ 避免“字符串即 JSON”的反模式：String 类型字段无法表达结构，强制前端 JSON.parse() 是临时补救，破坏类型安全与 IDE 支持；
- ✅ 前端查询应显式选择所需字段（如示例中的嵌套 name { en, ja }），既提升性能，也强化接口契约；
- ? 若后端数据源动态多变（如任意 JSON Schema），可考虑 @graphql-java 的 GraphQLScalarType 自定义 JSON 标量，但静态结构推荐强类型对象——更安全、可验证、易维护。
通过精准的 schema 设计与 Java 端对象映射，你不仅能彻底消除恼人的转义字符，更能构建出真正符合 GraphQL 精神的、类型驱动的 API。
