GraphQL在C#中推荐用GraphQL.Client.Http的GraphQLHttpClient发起强类型查询，需配置PropertyNameCaseInsensitive=true、显式传变量、严格匹配响应结构，避免反序列化静默失败。
GraphQL 在 C# 中没有官方“一揽子” SDK，直接用 HttpClient 手写请求最轻量、最可控；所谓“完整指南”往往混淆了服务端实现（如 HotChocolate）和客户端调用，而你真正需要的，是快速安全地从 C# 客户端发查询、收数据。
用 GraphQLHttpClient 发起强类型查询（推荐）
别自己拼 JSON 字符串。用 graphql-client 提供的 GraphQLHttpClient，它基于 System.Text.Json，支持泛型响应解析、自动错误映射、请求上下文透传。
常见错误现象：GraphQLResponse.Data 为 null 但 Errors 为空 —— 很可能是服务器返回了非标准结构（比如没包在 data 字段里），或 JSON 序列化时字段名不匹配。
- 安装包：
dotnet add package GraphQL.Client.Http - 初始化时必须指定
IGraphQLClient的序列化选项，尤其注意PropertyNameCaseInsensitive = true（服务端字段常为 camelCase，C# 类用 PascalCase） - 查询变量必须用
new Dictionary<string object>()</string>或new GraphQLRequest { Variables = ... }显式传入，不能靠匿名对象自动推导（会丢类型信息） - 不要复用
GraphQLHttpClient实例做并发请求而不加ConfigureAwait(false)—— 在 ASP.NET Core 同步上下文里容易死锁
GraphQLHttpRequest 和 GraphQLResponse<t></t> 怎么配对写
响应类型 T 必须严格对应查询返回结构。GraphQL 不强制 schema 与 C# 类一一映射，但字段名、嵌套层级、可空性（string? vs string）必须一致，否则反序列化失败且静默丢数据。
使用场景：查询用户列表带分页、获取单个订单及其商品明细、执行带输入校验的 mutation。
-
GraphQLRequest的Query字段要写纯字符串（建议用 verbatim string@""避免转义混乱），别拼接变量值 - 如果服务端返回
extensions字段（如 tracing、cost analysis），默认会被忽略；需继承GraphQLResponse<t></t>并添加[JsonPropertyName("extensions")]属性才能捕获 - mutation 返回的
id是 ID 类型？C# 端必须用string接收 —— GraphQL 的ID没有固定 .NET 对应类型，一律当字符串处理
绕过客户端库：手写 HttpClient + PostAsync（适合调试/简单场景）
当你只想验证一个 query 是否通、或服务端 schema 变动频繁来不及更新 C# 类型时，手写更直接。关键不是“能不能”，而是“怎么避免踩坑”。
性能影响：比 GraphQLHttpClient 少一层抽象，吞吐略高，但丢失错误分类、重试策略、请求日志等能力。
- Content-Type 必须设为
application/json，不是text/plain或空 - 请求体必须是合法 JSON 对象，至少包含
{"query": "...", "variables": {...}}；空variables要写成{}，不能省略或传null - 响应状态码为 200 不代表成功 —— GraphQL 规范允许 200 +
{"errors": [...]}，必须检查响应体里的errors数组 - 用
JsonDocument.Parse(responseString)先粗筛再取data，比直接反序列化到强类型更容错
真正的难点不在语法，而在 schema 变更时 C# 类型是否及时同步、nullable 字段是否与 GraphQL 的 !（非空）标记对齐、以及 mutation 错误如何映射成业务异常而非 HTTP 异常。这些地方不写测试，上线后第一波报错就来自这里。
