批量查询真正的瓶颈是速率，不是速度
直觉上会以为批量查询的挑战是「跑得够快」。实际上单笔查询大概一到两秒，五百个域名就算完全串行也只要十几分钟——那不是问题。真正的瓶颈是上游愿意让您查多快。
备案数据的来源最终都指向工信部，中间可能经过云服务商的查询接口或第三方数据库，而每一层都有自己的速率限制。我们实测过一个公开的免费接口，它的演示密钥大约每 20 秒才允许一次查询——用那个跑五百个域名要将近三小时，而且中途只要一次没退避就会被连续拒绝。 下表是几种常见做法的取舍。
| 做法 | 实际上会遇到什么 | 适合的规模 |
|---|---|---|
| 人工逐一查询 | 可行但耗时，而且不会有人真的每月做一次 | 十个以内 |
| 自己写爬虫打官方查询页 | 要处理验证码、版面改版与封锁，维护成本远高于预期 | 不建议 |
| 接免费公开接口 | 速率限制严格，冷门域名覆盖率不足，错误报告不可靠 | 几十个，可容忍漏查 |
| 接付费查询 API | 需要确认配额、错误语义与数据来源是即时或快照 | 数百到数千 |
| 自建缓存层加排程 | 上游仍有限制，但可以摊平，并且能侦测变动 | 持续监控的场景 |
第二行是多数人一开始会选、然后撞墙的那一种。自己写爬虫打官方查询页看起来最省钱，但验证码、版面改版与封锁都要自己处理，而且对方每改一次版您就要修一次——这份维护成本通常在三个月后才会被认真计算。
三个实作上的重点
这三件事决定您的批次跑得完、还是跑一半就被挡。
- 退避要读对方给的数字 被限流时，很多接口会在错误信息里明确写出要等多久。固定间隔重试会持续撞墙，而读取那个数字再等对应秒数，一次就能过。我们自己测试时第一轮就是因为固定 1 秒间隔，19 个域名有 14 个被限流——换成读取对方指定的秒数之后，同一批全部跑完。
- 缓存要分清楚「查过」和「查到」 备案状态变动不频繁，所以缓存很有效。但要注意：失败的查询不能当成结果缓存。如果上游超时被存成「无备案」，那个错误会留在您的数据里，而且因为有缓存，之后也不会再查一次。缓存的键应该包含查询是否成功，失败的只重试不写入。
- 真正要存的是变动，不是状态 存「当前状态」只能回答「现在如何」。存每次查询的结果与时间戳，才能回答「什么时候掉的」——而那才是您真正需要的告警。备案消失的时间点通常比发现的时间早好几周，有历史记录才查得出来是哪次改动造成的。
错误语义：批量查询最容易出事的地方
单笔手动查询时，响应看起来怪您会自己发现。批量跑的时候没有人在看——所以错误必须在结构上可区分，否则它会安静地变成数据。
这不是假设性的风险。我们实测一个公开接口时，它对 google.com 返回的是 HTTP 200、code 200，而 icp、unit 等字段的值全部是字符串「查询失败」。写成 if resp["icp"]: mark_as_filed() 的程序会把 google.com 标记为已备案，并把那四个字存成备案号。
所以接任何数据来源之前，先确认三种情况在响应上分得开：确定有备案、确定没有备案、这次查不到。第三种必须有自己的表达方式——独立的状态码或字段，而不是塞进数据字段里。分不开的来源，不能直接接进会写入数据库的流程。这一点与数据准不准是两回事，我们在备案查询工具实测那篇有完整的测试过程。
自建还是接 API
如果您要查的是几十个域名、每季一次，自己写个脚本打免费接口、加上退避与重试就够了，不需要付费。这篇前半讲的实作重点足够让它稳定运作。
需要考虑付费方案的通常是三种情况：域名数量到数百以上、需要的是持续监控而不是一次性盘点、或是冷门域名查不到的比例太高。最后一项最容易被低估——免费来源在知名域名上表现正常，在冷门域名上可能大量漏查，而冷门域名往往正是您要查的那些。
三个层次的规划
依序决定，可以避免过度设计：
一、先确定查询的频率需求
一次性盘点和持续监控是两种系统。盘点跑完就结束，不需要数据库；监控需要历史记录、变动侦测与告警。先确定是哪一种，再决定要盖多少东西。
二、估算批次需要多久跑完
用「域名数 × 每笔最小间隔」估算。如果结果超过您的排程窗口，问题不是加机器能解的——那是上游速率限制，要靠缓存、分批、或换数据来源处理。
三、决定查不到的时候怎么办
这是最常被略过的设计决定。查不到要重试几次、重试完还是失败要不要告警、以及绝对不能把失败写成「无备案」。先想清楚，比事后清理数据容易得多。
接任何备案查询 API 前该确认的三件事
不论是我们的还是别人的，这三项决定它能不能接进自动化流程：
- 速率限制、配额与超时行为 每秒与每日上限各是多少、超过返回什么、上游超时的时候是返回错误还是返回「无备案」。最后这一项最容易在上线后才踩到。
- 失败与「无备案」在响应上如何区分 要看实际的响应结构，不是文档上的描述。确认错误有独立的状态码或字段，而不是被塞进备案号字段里。
- 数据是即时查询还是快照 这决定冷门域名查不查得到，也决定备案失效之后多久才会反映出来。要求对方说明快照的更新频率与覆盖范围。
小结
批量查询备案状态的难点不在速度，在速率限制与错误语义。前者决定批次跑不跑得完，后者决定跑完之后那份数据能不能信。实作上三件事最关键：退避时读对方给的秒数、失败绝对不要当成结果缓存、以及存变动而不只是存状态。
规模不大就自己写，这篇的做法足够。如果您的域名数量到数百以上、或是需要持续监控并在备案消失时收到告警，欢迎来信说明用量与使用场景，我们再看怎么配合。