GraphQL Request 插件不支持设置 headers 或 bearer token，必须改用 Thunder Client 等支持完整 HTTP 控制的工具；调试时需确认 token 被服务端正确接收、本地 schema 正确加载、断点打在鉴权后 resolver 入口。
不能直接用 GraphQL Request 插件发带鉴权的请求——它不支持设置 headers 或 bearer token，必须换方案。
GraphQL Request 插件不支持鉴权，别浪费时间配 header 注释
很多人试过在 # GraphQL Request 注释后加 Authorization: Bearer xxx 或类似字段，结果请求发出去 401，插件还静默成功。这是因为 GraphQL Request（jimmydief 版）底层只拼 URL 和 body，完全忽略任何注释里的 header 声明。
- 它不读取、不解析、不转发任何自定义 header
- 连
Content-Type: application/json都是硬编码写死的，没法覆盖 - 错误响应（如
{"errors":[{"message":"Unauthorized"}]}）会显示在右侧面板，但没上下文提示你缺 header
用 Thunder Client 发带 Authorization 的 GraphQL 请求
Thunder Client 是目前 VSCode 里最轻量、最可控的替代方案，支持完整 HTTP 控制，且无需服务端改造。
- 新建一个
.http文件（比如auth-query.http） - 写入标准 POST 请求，显式设 header：
POST http://localhost:4000/graphql
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
<p>{
"query": "query GetUser { user(id: \"1\") { name email } }",
"variables": {}
}- 光标停在请求块内，按
Ctrl+Alt+R（Win/Linux）或Cmd+Alt+R（macOS）发送 - 响应直接内联显示，支持折叠、JSON 格式化、状态码高亮
- Token 可存为环境变量（如
{{token}}），避免硬编码泄露
调试 Node.js 后端时，断点要打在鉴权中间件之后
前端请求能发，不代表后端逻辑真跑通。如果你在 resolver 里打断点却进不去，大概率是鉴权中间件（如 Apollo Server 的 context 函数）提前 return 或 throw 了。
- 在
context函数开头加console.log(req.headers.authorization)，确认 token 被正确提取 - VSCode 调试配置中，确保
launch.json启用了"env": {"NODE_OPTIONS": "--enable-source-maps"}（尤其 TypeScript 项目） - 如果用 ESM +
ts-node/esm，runtimeArgs必须含--loader ts-node/esm，否则断点无法命中中间件代码 - Keystone 等框架默认把鉴权逻辑封装在
graphQLContext中，断点要打在该函数返回后的 resolver 入口，而不是schema.graphql文件里
本地调试时，避免用远程 endpoint 加载 schema
你配的 schema: "https://prod.example.com/graphql" 在调试阶段极不可靠：生产环境通常关闭 introspection、限制 Origin、校验 Referer，导致插件加载 schema 失败——但 VSCode 不报错，只是补全变灰、字段标红，你根本不知道是鉴权问题还是路径问题。
- 开发阶段一律用本地
schema.graphql文件（从 dev 服务导出：npx get-graphql-schema http://localhost:4000/graphql > schema.graphql） - 确保
graphql.config.yml中schema路径是相对该文件位置的，比如 config 在根目录，就写schema: "./schema.graphql"，别写./src/schema.graphql - Windows 用户注意反斜杠：写
schema: "schema\schema.graphql"会被 YAML 解析器当成转义失败，必须用正斜杠
真正卡住人的从来不是“怎么发请求”，而是“为什么发了却没进 resolver”——先确认 token 到达服务端，再确认 schema 被编辑器正确识别，最后才轮到 query 字段是否合法。三者顺序错一个，调试就陷入黑盒。
