GET 接口也会改状态？给只读查询补上六条验收

给内部系统增加列表、详情和导出接口时，最容易出现的误判是：接口能返回 JSON，就算做完了。今天用 CodeArts 智能问答评审一个只读查询方案后，我把验收收敛成了下面六条。本文使用虚构分类和示例数据，不包含真实系统地址、凭据或业务记录。

1. 无效密钥必须被拒绝

分别测试没有 Authorization、空 Bearer、错误密钥和已经撤销的密钥。它们都应该被拒绝，不能带出业务字段。静态 API key 与 JWT 的验证方式不同，不要把“篡改签名”的测试直接套到静态 key 上。鉴权失败日志也不应记录完整密钥。

2. 分类必须精确匹配

假设需要查询 TEAM，却还有 TEAM_EXT。前缀匹配可能把两个分类混在一起。验收数据应同时包含这两种值，验证返回集只包含 TEAM。不能只依赖页面上的筛选文字，详情接口也应检查同样的范围，避免只过滤列表。

3. 列表与详情应该能对得上

从列表取 ID，再查询对应详情，至少核对 ID 和分类。状态或负责人可能在两次请求之间被正常修改，所以不能把所有字段变化都判成程序错误。需要严格一致时，应提供快照时间、版本号或同一批次导出机制。

4. 查询不能推进每日提醒基线

有些查询复用了定时监控函数，顺手更新了“上次结果”。随后每日提醒比较不到变化，看起来就像通知失灵。解决方式是分开“读取当前数据”和“提交比较基线”。验收时，查询前后计算基线文件校验和，确认一致；定时任务运行时再单独验证基线能正常推进。

这里的只读指业务数据和监控基线不被修改。必要的访问审计、指标和缓存并非一概禁止，应明确它们的边界，并控制体积与保留时间。

5. 超额并发要让调用方知道怎么重试

设并发限制为 R，测试 R 个正常请求与超出配额的请求。接口若用 429 表示限流，应给出 Retry-After，并说明单位。调用方不能看到失败就立即无限重试，否则保护机制反而形成请求风暴。

6. 上游超时不能伪装成空列表

“没有数据”和“没查到数据”是两个结果。超时应返回明确错误及 request_id，例如 504 与 UPSTREAM_TIMEOUT。若支持缓存结果，也要显式标注数据来源、采集时间和失效原因，让用户能判断是否继续使用。

一个最小验收结果

{
  "auth_rejection": "passed",
  "scope_exact_match": "passed",
  "detail_scope_check": "passed",
  "baseline_unchanged": "passed",
  "overload_retry_after": "passed",
  "timeout_is_explicit": "passed"
}

这份 JSON 仅是结果结构示例，不代表任何真实系统已经通过验收。每个 passed 都应对应具体请求、响应摘要和测试时间。AI 能帮助列出用例，最终是否完成仍要看真实接口的行为。