自建爬虫迁到 SerpBase 一个月复盘：工时、成本、稳定性三项对照

维护了两年的自建 Google 搜索采集器，上个月整体迁到了 SerpBase（官网 serpbase.dev）的 API 上。不是拍脑袋换的——是代理池、验证码、页面改版这三件事每个月都在吃掉维护时间。这篇把迁移后 30 天的三项关键指标做个对照复盘：工时、成本、稳定性，以及迁移过程本身踩的坑。

一、先看结论（30 天对照）

指标	自建爬虫（迁移前均值）	SerpBase API（迁移后）	变化
维护工时	每周约 3-6 小时（代理/验证码/解析修复）	每周约 0.5 小时（看监控）	降 80%+
直接成本	代理 + 小服务器，约 $15-25/月	按量：月 6,000 次搜索约 $3	降约 85%
采集成功率	87%-93% 波动（被识别就掉）	观测 99%+（信封 status 可统计）	明显更稳
排查方式	翻日志猜是代理挂了还是页面变了	一个 request_id 追到底	定位快得多

（数字是我这个项目的观测，规模不同会有出入，但方向性差异很明确。）

二、迁移过程（三步，没停机）

第一步：抽数据源接缝。 迁移前先做一件最重要的事——把「抓取」和「解析」从业务代码里抽出来，收成一个接口：

class Searcher:
    def search(self, keyword: str, gl: str, hl: str) -> list[dict]:
        raise NotImplementedError

class CrawlerSearcher(Searcher):
    ...   # 老的自建实现

class SerpBaseSearcher(Searcher):
    def search(self, keyword, gl, hl):
        resp = requests.post(
            "https://api.serpbase.dev/google/search",
            headers={"Content-Type": "application/json", "X-API-Key": os.environ["SERPBASE_API_KEY"]},
            json={"q": keyword, "gl": gl, "hl": hl}, timeout=(5, 30),
        )
        data = resp.json()
        if data.get("status") != 0:
            raise ApiError(data.get("status"), data.get("request_id"))
        return [
            {"rank": r.get("rank"), "title": r.get("title"),
             "link": r.get("link"), "snippet": r.get("snippet", "")}
            for r in data.get("organic", [])
        ]

第二步：双跑验证。 同一批词，两个实现各跑一遍，比对前 10 的域名集合和排名差异。差异在可接受范围（SERP 本身有抖动），且新实现字段更全，才进第三步。

第三步：切换 + 缓存。 业务侧只改了配置（Searcher 的实现类），然后给查询层加缓存——这一步很关键，见下面的坑。

三、哪些能力留下，哪些交出去

迁移不是「全换掉」，是重新分工：

交出去的（这些正是维护成本的来源）：代理池、验证码处理、页面结构解析、反爬对抗。

留下的（这些是业务价值）：调度与重试策略、存储与建模、指标与告警、以及所有的业务解析逻辑（从结果里挑什么字段、怎么算排名）。

四、踩坑记录

坑 1：迁移后调用量直接翻倍。 老爬虫有本地缓存，换 API 时没把缓存带过去，同样的词反复请求。迁移清单里必须有「缓存与去重」一项。（API 很便宜，但白白翻倍没必要。）

坑 2：低估解析差异。 自建解析的字段名和 API 的不一样（比如摘要字段），且 API 的可选字段会缺。老代码硬索引的地方全量改成 .get() 兜底，先跑 fixture 测试。

坑 3：没做双跑就切。 双跑是为了确认「排名/域名集合差异在合理范围」。跳过这步，出了问题分不清是数据源差异还是自己改坏了。

坑 4：失败当成功吞掉。 HTTP 200 不代表业务成功——要判信封里的 status。不做这一步，异常数据会静默入库。

坑 5：Key 管理沿用老习惯。 老项目把代理凭证写在配置里，迁移时差点把 Key 也写进去。Key 只走环境变量，日志打掩码。

五、复盘后的几点感受

1. 维护时间才是自建的主要成本。每周 3-6 小时的代理/解析修复，折算下来远超 API 费用。
2. 迁移的技术难点不在调用本身，而在「别把老问题一起搬过去」：缓存、可选字段、失败判定、Key 管理——这四样在旧系统里欠的债，换数据源不会自动还。
3. 信封字段（status/request_id/credits_charged）让运维省心：成功失败可统计、每笔花费可对账、排障有追踪号。这些是老爬虫时代要自己搭的。

小结

自建迁 API 这笔账，算的不是「API 比服务器贵不贵」，而是「每周省下的维护小时值多少钱」。三项对照里，工时和稳定性是收益的大头，成本只是明面上的小头。想做迁移的同行，建议按「抽接缝 → 双跑 → 切配置 → 补缓存」的顺序走，坑基本都能提前排掉。

信封字段与端点说明见 SerpBase 官方文档。你们自建采集还在维护吗？每个月花多少小时？评论区聊聊。