graphql.config.yml 的路径必须相对于其自身位置，schemaPath 等路径以该配置文件所在目录为基准；Windows 必须用正斜杠；多文件 schema 需写成数组；LSP 服务器不自动重启，需手动执行 LSP: Restart Server graphql；gql 模板字符串需满足命名约束才能触发补全；补全是静态的，依赖本地 schema 快照，需手动同步更新。
graphql.config.yml 路径必须相对于配置文件自身位置
Sublime 的 LSP-graphql 插件读取 graphql.config.yml 时，所有路径（如 schemaPath）都是以该配置文件所在目录为基准，不是项目根目录，也不是当前打开的 .graphql 文件位置。这点和 VSCode 行为一致，但 Sublime 不提示错误，只静默失效。
常见踩坑点：
-
schemaPath: "schema.graphql"—— 如果graphql.config.yml在config/目录下，它会去config/schema.graphql找，而不是项目根目录下的schema.graphql - Windows 用户必须用正斜杠：
schemaPath: "src/graphql/schema.graphql"合法，schemaPath: "src\graphql\schema.graphql"是非法 YAML，LSP 直接跳过加载 - 多文件 schema 必须写成数组：
schemaPath: ["src/graphql/types.graphql", "src/graphql/queries.graphql"]，单字符串不支持 glob 或目录递归
LSP-graphql 服务不会自动重启，schema 更新后必须手动触发
你改了 schema.graphql，保存后 Sublime 里字段提示还是旧的？不是插件卡顿，是 LSP 服务器根本没重载 schema。它只在启动时读一次配置，后续变更全靠人工干预。
正确做法：
- 按
Ctrl+Shift+P（Mac 为Cmd+Shift+P）调出命令面板 - 输入
LSP: Restart Servers并执行 - 或者更精准：输入
LSP: Restart Server graphql（确保 server name 是graphql，可在LSP.sublime-settings中确认） - 别依赖“保存即生效”——这是最常被忽略的同步断点
JS/TS 中 gql 模板字符串需满足命名约束才能触发补全
Sublime 的 GraphQL 插件（princjef 版）能识别 gql 标签，但前提是它能静态推断出该变量确实指向 GraphQL 操作。否则只会高亮语法，不提供字段补全或类型校验。
有效写法：
-
const query = gql`{ user { name } }`—— 全局存在gql函数（如从graphql-tag全局注入） -
import { gql } from 'graphql-tag'; const q = gql`...`—— 命名导入且变量名是gql或以gql开头（如gqlQuery）
无效写法：
-
const myGql = gql`...`—— 插件无法关联上下文，补全失效 -
const q = graphql.gql`...`—— 非标准调用形式，不识别 - 没 import
gql，仅靠全局变量但未在 Sublime 的 JS 环境中声明（如没配 JS Custom 或 ESLint 环境）
前端与后端 schema 不一致时，补全无报错但运行时报字段不存在
Sublime 的补全是纯静态的，只依赖本地 schemaPath 文件内容。如果后端已删掉 user.profile.avatar 字段，但你的本地 schema.graphql 还保留着，编辑器照样提示、补全、不报错——直到你真正发请求才收到 Cannot query field "avatar" on type "Profile"。
规避方法：
- 把 schema 更新纳入开发流程：每次后端 schema 变更后，运行
npx apollo schema:download --endpoint=http://localhost:4000/graphql刷新本地schema.graphql - 配合
graphql-codegen自动生成 TypeScript 类型，利用 TS 编译阶段提前暴露字段不匹配 - 别把 Sublime 的补全当契约——它只是本地快照，不是实时 API 文档
graphql.config.yml 路径的理解、对 LSP 重启时机的把握、以及对本地 schema 更新节奏的掌控上。稍一松懈，补全就变成幻觉。 
