NMPA 备案 1.5M 看门狗采集器

6 周首版 里我们做了这些

背景

NMPA 化妆品备案库 2014 年至今已积累超过 150 万条产品备案数据，是中国所有行业 SaaS / 数据服务的"必备底座"。但 NMPA 网站从 2022 年起多次升级反爬，行业里普遍只能拿到 2014-2020 年的存量数据，2021 年后的增量大多缺失或滞后。 这套采集器的诞生是为了解决 INCILABSV2 / CosPulse / INCISIGHTS 三个上层产品共同的数据底座问题。后期顺势开放给 12 家外部订阅客户（每家 ¥3-8 万/年的数据 API 服务）。

我们做了什么

架构分两层：探测进程负责按 BABH 备案号穷举，发现有效号写入队列；抓取进程从队列消费，获取详情写入 PG。 第 1-2 周｜单进程基础版本。验证 NMPA 反爬规则：图形验证码（中文混合 + 数字 + 滑块）+ IP 限流（同 IP 30 分钟 30 次封）+ 行为指纹检测（鼠标轨迹 / 滚动模式 / 点击间隔）。结论：不能纯 HTTP，必须 Chrome。 第 3-4 周｜并发架构。7 个端口（7401-7415）跑独立 Chrome 实例，每个实例对应独立 IP 段（住宅代理）。探测覆盖 2026→2025→2024→2023 倒序，2026 数据增量为主、历史数据查漏为辅。一个实例每天能稳定采 600-800 条。 第 5-6 周｜验证码自动处理。验证码识别用阿里云 OCR + 滑块用 PyAutoGUI 真实拖动（不是 JS 触发，绕过滑块的 JS 检测）。识别失败自动重试 3 次，失败超阈值就触发实例重启。 第 7-8 周｜看门狗。监控目标：① 每个端口的 code_{port}.png 截图超 15 分钟未更新 → 实例冻结，重启；② 探测进程 poll() 返回非 None → 进程崩溃，重启；③ NMPA 网站 412 / 502 → 暂停 30 分钟换代理；④ 重启后 6 分钟宽限期不再触发冻结检测。每 2 分钟巡检一次。 第 9-10 周｜尾部省份专项。2025 年下半年发现尾部 6 个省（青海 / 西藏 / 宁夏 / 海南 / 云南 / 甘肃）数据稀缺，单独跑一个 7416 端口专项采集。 第 11+ 周｜运维。每周一次代理池滚动 + 每月一次验证码模型微调（NMPA 偶尔会换验证码风格）。

数据结果

上线 14 个月连续运行： · 累计入库 1,508,127 条产品备案数据 · 0 次人工干预（看门狗全自动处理重启 / 切代理 / 验证码失败回退） · 平均每日新增 1,800-2,400 条（增量为主） · 反爬触发率 < 8%，全部由看门狗自动恢复 · 12 家外部数据订阅客户，月均 ¥18 万订阅收入 · 服务器成本：¥2,400/月（1 台 Windows + 7 个 Chrome 实例）

复盘 · 哪里做得不够

前 3 个月调过 4 次代理策略，从纯住宅 IP → 数据中心 IP 混搭 → 按时段切换 → 最终定型为"白天住宅 + 夜间数据中心"分时方案（NMPA 反爬在工作时间更严）。这种"先动手做 → 数据驱动调优"的迭代节奏对反爬采集器很关键，前期不要试图设计完美架构。 另一个教训：看门狗本身的代码反而要写得"傻"——所有判断条件都是固定阈值（15 分钟 / 6 分钟 / 2 分钟），不要试图加自适应逻辑。一个看门狗能跑 14 个月，靠的不是代码巧妙，靠的是当时多想了 5 个边界 case 并且不再去优化它。