Postman 的 GraphQL Body 类型仅自动组装 JSON 并设 Content-Type: application/json，不校验 query 语法或 variables 结构，故易因缺失 query 字符串、variables 不匹配、URL 多余斜杠等报错；需手动补全字段、配齐 Headers（Content-Type、Authorization、Accept），并用 Pre-request Script 动态注入变量。
Postman 发送 GraphQL 查询不是「选对 Body 类型就行」那么简单——它默认不自动加 Content-Type: application/json，也不校验 query 字段结构，稍不注意就返回 "message": "Must provide query string." 或 400 Bad Request。
为什么选 GraphQL 类型却发不出请求？
Postman 的「GraphQL」Body 类型看似方便，实则只做两件事：把输入的 query 和 variables 自动组装成标准 JSON 格式，并设好 Content-Type: application/json。但它不会帮你补全缺失字段，也不会提示语法错误。
常见失败场景：
- 后端要求
query字段必须是字符串（哪怕空格换行都算合法），但你粘贴了未包裹引号的裸对象 - 变量没填，但 query 里写了
$id却没在 Variables 栏输入{"id": "123"} - 端点 URL 尾部多了一个
/graphql/（注意斜杠），而服务实际监听的是/graphql
建议直接用 raw → JSON 手动构造体更可控，尤其调试初期：
{
"query": "query GetUser($id: ID!) { user(id: $id) { name email } }",
"variables": { "id": "abc123" }
}Headers 里哪些字段不能漏？
GraphQL 是 HTTP 协议之上的查询层，该配的头一个都不能少：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Content-Type: application/json—— 必须，否则服务端可能拒收 -
Authorization: Bearer <token></token>—— 如果接口启用了 JWT/OAuth，漏掉就401 Unauthorized -
Accept: application/json—— 非强制，但部分网关（如 Apollo Federation）依赖它做内容协商
注意：Authorization 不要写在 Body 里，也不要在 URL 后拼 ?token=xxx —— GraphQL 规范不认这些位置。
Variables 栏和 Pre-request Script 怎么配合？
Variables 栏适合静态值；一旦要动态生成（比如用上一个响应里的 id），就得靠 Pre-request Script 注入：
- 在 Variables 栏留空，或填占位符如
{"id": "{{user_id}}"} - 在 Pre-request Script 里写：
pm.environment.set("user_id", pm.response.json().data.createPost.id); - 确保该脚本所在请求已成功执行过（即有响应），否则
pm.response为空
别在 Variables 栏直接写 JS 表达式——它不解析，只会当字符串发出去。
Postman 对 GraphQL 的支持是“能用”，但不是“傻瓜式安全”。最容易被忽略的是：它不会拦截语法错误的 query 字符串（比如少个大括号），也不会警告你 variables 类型和 schema 不匹配——这些都得靠你手动核对 schema 文档或用 GraphiQL 调通后再迁移到 Postman。
