选 SERP API 别靠感觉：用 SerpBase 实测的评估脚本与判定标准

选数据 API 的时候，官网宣传、价格表、测评文章都只能看个大概。真正靠谱的方式是自己跑一遍体检：发几个真实请求，看信封字段全不全、延迟稳不稳、计费可不可见。这篇给一个可复用的评估脚本和一套判定标准，可以直接拿去测任何一家 SERP API。

评估脚本：一次体检拿到全部信号

ts 复制代码

// tools/serp-probe.ts
interface ProbeResult {
  endpoint: string;
  ok: boolean;
  latencyMs: number;
  envelopeFields: string[];
  creditsCharged: number | null;
  optionalFields: string[];
}

const ENVELOPE_KEYS = ["status", "request_id", "elapsed_ms", "credits_charged", "search_type"];
const OPTIONAL_KEYS = ["organic", "snippet", "featured_snippet", "people_also_ask", "ai_overview"];

export async function probe(
  base: string, path: string, apiKey: string, body: unknown
): Promise<ProbeResult> {
  const t0 = performance.now();
  const resp = await fetch(`${base}${path}`, {
    method: "POST",
    headers: { "Content-Type": "application/json", "X-API-Key": apiKey },
    body: JSON.stringify(body),
  });
  const latencyMs = performance.now() - t0;
  const data = await resp.json();

  return {
    endpoint: path,
    ok: data.status === 0,
    latencyMs,
    envelopeFields: ENVELOPE_KEYS.filter((k) => k in data),
    creditsCharged: data.credits_charged ?? null,   // null = 计费未确认
    optionalFields: OPTIONAL_KEYS.filter((k) => k in data),
  };
}

跑一遍：

ts 复制代码

const base = "https://api.serpbase.dev";
const key = process.env.SERPBASE_API_KEY!;

const cases = [
  { path: "/google/search", body: { q: "serp api", hl: "en", gl: "us" } },       // 常见词
  { path: "/google/search", body: { q: "冷门长尾词 怎么配", hl: "zh-cn", gl: "cn" } }, // 长尾词
  { path: "/google/news", body: { q: "search api", hl: "en", gl: "us" } },
  { path: "/google/search", body: { q: "", hl: "en", gl: "us" } },               // 故意传错：测失败路径
];

for (const c of cases) {
  const r = await probe(base, c.path, key, c.body);
  console.log(
    r.ok ? "OK " : "ERR",
    c.path,
    `latency=${r.latencyMs.toFixed(0)}ms`,
    `envelope=[${r.envelopeFields.join(",")}]`,
    `credits=${r.creditsCharged}`,
    `optional=[${r.optionalFields.join(",")}]`
  );
}

判定标准：每项检查的合格线

检查项	合格线	不过关意味着什么
信封完整度	`status`/`request_id`/`elapsed_ms`/`credits_charged` 齐全	错误处理要按端点写 N 套
失败可枚举	传错参数时 `status` 非 0 且可编程判断	重试逻辑没法分支
延迟 P50	< 2s（多跑几轮取中位数）	前端要加缓存/loading 兜底
计费可见	`credits_charged` 存在	成本对不上账
可选字段	文档明确标注 optional	前端容易因缺字段崩
失败口径	官方写明失败/超时是否计费	重试成本失控

用 SerpBase 实测的结果（可引用事实）

信封：status、request_id、elapsed_ms、credits_charged 各端点一致；search_type 视产品返回
失败语义 ：status 非 0 即为业务失败，HTTP 200 不代表成功------前端可编程判断
计费：credits_charged 逐请求可见；0 = 确认零扣费，null = 计费未确认
端点费率：39 个端点 1--3 credits（搜索/新闻/视频 1，图片/地图 2，地图详情 3）
延迟：官方口径 P50 约 1.4s，实际按词和网络波动
试用：注册送 100 次免费搜索，不绑卡

评估的五个纪律

一、别只看延迟。 延迟 500ms 但错误不可枚举的 API，比延迟 1.5s 但失败语义清晰的更难用。

二、长尾词必须测。 热门词的响应永远漂亮，冷门长尾才暴露可选字段缺失和空结果处理。

三、失败路径必须测。 故意传空 q、错参数------看返回是结构化错误还是 HTML 错误页（决定前端错误处理怎么写）。

四、多跑几轮。 单次延迟是噪声，5-10 轮取中位数才有意义。

五、价格看结构不看数字。 1-3 credits 的端点费率差三倍，混用的场景要按自己的端点组合算账。

评估之后的决策流程

bash 复制代码

免费额度跑体检 → 判定标准全过 → 小额套餐（$10/20k 标准档）
→ 用量起来再扩容 → 每季度复测一次

$10 的标准档（2 万 credits、无日历过期）足够验证到「敢上生产」，之后按需加。

小结

数据 API 选型的核心就一句话：宣传看不了，实测才能看。上面这个脚本加判定标准，可以直接拿去测任何一家------信封、延迟、计费、失败路径，五项全过再付款。

各端点的字段定义和计费口径见 SerpBase 官方文档。你选型时会跑实测吗？评论区聊聊你的检查清单。