拆开看，就不难理解为什么城市一级总会飘
第一段来自各地区互联网注册管理机构公布的分配记录。它记的是某一段地址归哪个组织、登记在哪个国家和地区，粒度到段不到人。申请与回收都要走流程，所以这段数据的刷新天然慢一些，刚变更过的段短期内会滞后。
第二段来自运营商申报的持有信息。同一家运营商在不同省份的分公司可能各自握着地址，申报里能看到名称与大致用途，却看不出这段地址实际服务哪一片区域。
第三段是商业库自己做的探测与校正：观察这段地址从哪条路由宣告出去、往返延迟落在什么区间，再据此回填省市一级的推测。它最接近实际情况，也最容易受探测线路与样本量的影响。
三段数据合并时，登记记录负责兜底，探测结果负责细化。所以只保留一个省份字段的结果往往更稳，出现精确到街道的结果时，就要留意它的更新日期了。
刷新节奏与偏差类型都不一样
| 数据来源 | 记录的内容 | 刷新节奏 | 典型偏差 |
|---|---|---|---|
| 分配记录 | 地址段归属的组织与登记地区 | 按管理机构节奏，以周或月计 | 只到组织与国家，落不到城市 |
| 运营商申报 | 持有的地址与大致用途 | 随申报变动 | 不体现实际服务的区域 |
| 路由宣告 | 该段地址从哪条路由出去 | 接近实时 | 只能说明接入点，说明不了使用者 |
| 探测校正 | 按延迟与线路推测所在城市 | 滚动更新，取决于样本量 | 跨省汇聚时整体偏移 |
把这几项固定下来，批次之间才可比
少一个字段，后面的复用就会卡住
先合并再查询，请求量能降一个数量级
把日志或名单里的单条记录合成连续区间，按起点排序。先去重，往往能省掉一多半的查询次数。
两次省份一致的直接采信，不一致的单独挑出来，这部分通常不到总量的十分之一。
看这段地址实际从哪儿宣告出去。宣告点与城市对不上时，以宣告点为准，城市宁可留空也别填错。
每次核对留档，下次对比时能立刻看出哪几条变了，不必整批重查。
碰上这几种，别急着怪工具
问的都是结果该信到什么程度
先比快照日期，新的优先；日期接近时取两家省份的公共部分，城市参考路由宣告点。城市不一致而省份一致，说明偏差只出现在汇聚点这一级。
该段可能整体登记在某个组织名下，申报信息里没有更细的行政区划，探测样本也不足以支撑判断。这类结果只适合做国别分类。
看用途。做访问来源统计，半年内的结果差别不大；要判断某台机器此刻在哪儿，超过一个月的地址段结果就该重新查一次。
看规模。几百条用表格配合导出功能就够了；上万条建议先合并成段，请求量能显著下降，人工核对量也跟着减少。
两种可能：库更新了，或者这段被重新分配。对比两次结果的字段变化能区分，只有城市变通常是库更新，登记地区与接入类型一起变多半是重新分配。