· 全部指南
GraphQL 与 REST 查询语言
GraphQL 暴露单一 HTTP 端点与强类型 schema。客户端只请求所需字段，相较固定 REST 载荷可减少 over-fetching。灵活性把复杂度转移到 resolver、N+1 查询，以及调试时难以阅读的多层嵌套 JSON。
graphql-formatter 可在本地美化 GraphQL 查询字符串与 JSON 响应，便于发现缺失的 __typename、分页 cursor 与 errors 扩展，而不用盯单行压缩输出。对接 REST 微服务或遗留 SOAP 网关时，仍要从 JSON 体提取字段——JSONPath 与 JMESPath 成为临时查询语言。
典型场景：移动应用 POST /graphql 查询 user { orders { items { sku price } } }，响应嵌套四层。流程：复制响应 JSON → graphql-formatter → 确认 price 是字符串还是数字 → 修正 schema 或客户端解析。迁移期可与等价 REST 端点并排用 json-formatter 对比 GraphQL data。
JSONPath 入门
JSONPath 在 JSON 树上做选择，灵感来自 XPath。$.store.book[*].author 返回书中所有作者；$..price 递归找全部 price 键——方便但在大文档上可能昂贵。过滤 [?(@.price < 10)] 保留低价项，但各实现支持度不同。
jsonpath-tester 可粘贴样例 API JSON 交互式试表达式——比在未测试路径写进生产代码更快。步骤：从预发抓取真实 200 响应（脱敏 PII）→ 粘贴 → 从 $ 根选择器开始 → 用 [*] 钻数组 → 最后加过滤。
示例载荷：
{ "store": { "book": [
{ "title": "GraphQL Guide", "price": 29.99 },
{ "title": "JSONPath Handbook", "price": 9.99 }
]}}
表达式 $.store.book[?(@.price < 15)].title 得 ["JSONPath Handbook"]。常见错误：以为 JSONPath 可写回文档（多数引擎只读）；键含空格仍用点号而未用方括号；在请求处理器中对兆字节数组跑 $.. 递归。
JMESPath 对比
JMESPath 语法一致，支持投影、管道与内建函数（length()、sort_by()、join()）。AWS CLI 与许多云控制面默认用 JMESPath 做 --query 过滤。jmespath-tester 可与 jsonpath-tester 用同一 payload 评估，便于团队选定标准。
JMESPath 示例：store.book[?price < \15`].title 返回相同标题，数字用反引号。管道便于重塑：store.book | sort_by(@, &price) | [-1].title` 无需命令式代码即可得最贵书名。
在写入 CI 前用相同 fixture 对比两工具。JSONPath 对熟悉 XPath 者友好；JMESPath 对 AWS 工程师友好。在测试 README 文档化所选方言，避免每人发明一次性 jq 咒语。
实践建议
繁重提取与业务逻辑应在服务端——数据库投影、GraphQL resolver 或 ETL——而非每页在浏览器跑 JSONPath。客户端 JSONPath 适合调试面板、QA 脚本与一次性数据迁移。
注意性能：在浏览器工具中对万元素数组做递归搜索会阻塞主线程。XML/SOAP 遗留接口可用 xpath-tester 平行 JSON 工作流。响应在 partial data 旁带 GraphQL errors 时，用 graphql-formatter 格式化两段并记录 correlation id。
安全：勿在无沙箱情况下对用户提供的 JSONPath 对任意对象求值——路径表达式可被滥用以对大载荷 DoS。Towalles 测试器本地运行；结对调试时仍避免把生产客户记录贴到共享屏幕。
查你需要的
GraphQL 的优势是客户端有意识地选字段。避免无界嵌套查询；服务端设置深度/复杂度限制。
运维中的 JSONPath
JSONPath 便于从大型 JSON 日志与 fixture 抽取字段。把表达式与样例文档一起放进版本库。
安全
生产环境不要在无鉴权下开放「随意内省」。把灵活查询面当代码执行风险——限流并鉴权。
GraphQL 安全限制
动生产前先写操作程序：输入、期望输出、负责人与回滚。Towalles 上的工具便于本地检查样例，不能替代变更控制。
前置条件
- 有代表失败案例的脱敏 fixture。
- 清楚谁是真相来源（应用、网关、CMS 或网络设备）。
- 能在非生产环境或用合成数据复现问题。
步骤
- 用 fixture 复现，记录精确命令或 UI 路径。
- 按需用格式化、哈希或解析工具与已知正确样例对照。
- 做最小修复；同一变更里避免顺手重构。
- 补充回归测试或清单项，避免下一任 on-call 重复踩坑。
- 更新 runbook：症状 → 检查 → 修复。
善后
观察 24–72 小时错误率与支持工单。若做过一次性数据修复，安排后续防止复发。工单里保留截图与哈希，不要留真实密钥。
反模式
- 把生产密钥贴到公开页面「只是看一下」。
- 上线却不写回滚说明。
- 把本地绿色演示当成多区域生产的证明。