最近在 Hacker News 上看到一个很有意思的项目Show HN: Scraper that probes a site before promising it works。一句话概括设计思路在承诺“我能抓这个站”之前先对目标站点做一次探测。这个思路看起来简单但对做爬虫工程的人来说几乎打中了日常最大痛点——配置了一整套规则真正跑起来才发现网站早就改版、加了登录墙、换了反爬策略或者 robots.txt 已经明确禁止抓取。与其等到批量任务跑完再收拾一堆无效数据不如在任务开始前就用一个 probe 阶段把所有潜在问题暴露出来。为了便于叙述下文用 ProbeScraper 作为这个项目的代称。这篇文章会围绕它的核心能力、适用边界、部署方式、探测流程、API 调用和批量任务展开重点说明为什么“先探测、再抓取”能节约开发时间、减少无效请求以及如何把它接到自己的数据采集链路里。在往下读之前先想三个问题你现在的爬虫任务有没有一上来就盲目请求目标网站直到反爬响应或结构变化后才发现问题你的站点解析规则有没有因为目标网站改版而突然失效你的批量采集任务有多少是跑了很久才发现整体失败如果对这三个问题有共鸣这篇文章建议收藏。先看核心能力速览。1. ProbeScraper 核心能力速览能力项说明项目类型站点探测 网页爬虫工具核心卖点抓取前先 probe 目标站点确认可抓取后再执行采集探测对象robots.txt、HTTP 状态码、页面结构、反爬验证页、编码主要功能站点可用性检查、解析规则校验、批量任务、API 服务运行平台Windows / Linux / macOS硬件要求极低CPU 即可无 GPU 依赖推荐环境Python 3.9依赖 requests、lxml、BeautifulSoup4启动方式CLI 命令、API 服务、Docker 容器是否支持 API支持可提供 JSON 接口是否支持批量任务支持按站点清单批量探测和抓取适合场景数据采集工程、爬虫巡检、网站结构监控、自动化测试从材料看这个项目并不依赖特定显卡或深度学习框架本质上是工程型工具。它不适合用来处理验证码绕过、JS 渲染破解等高对抗场景核心价值是“把能爬的站快速爬好把不能爬的站提前识别出来”。2. 适用场景与使用边界2.1 这个工具适合谁先说适合的人爬虫脚本经常跑挂的开发者。如果你维护过几十个站点采集任务一定遇到过“某天某个站突然返回 403但脚本还在跑最后全量失败”的情况。ProbeScraper 的设计就是让这类问题在任务启动前暴露。做数据采集平台或采集服务的团队。在用户提交一个采集任务时先执行 probe如果探测不过直接返回“该站点暂不支持采集”或“需要人工确认”比任务跑到一半再失败要友好得多。做网站结构监控的人。网站改版后解析规则会失效。ProbeScraper 的“选择器校验”功能可以在规则失效时及时告警。自动化测试工程师。把 probe 当成一个只读的 URL 健康检查工具检查站点首页是否 200、robots.txt 是否限制、是否出现反爬验证页面。2.2 什么场景不适合高并发高强度抓取。这类工具的定位是先探测、再小批量验证不适合直接用几十个线程冲某个站点。需要登录才能访问的内容。如果目标页面在登录墙后面probe 只能验证登录页是否能访问无法真实评估登录后的数据解析情况。需要渲染 JS 的动态页面。如果目标依赖浏览器渲染probe 阶段需要额外接入 Playwright 或 Selenium否则只能探测到空壳 HTML。以绕过访问控制为目的的行为。这不是工具该干的事也不应该在工程里出现。2.3 合规边界任何爬虫工具都要强调合规。使用 ProbeScraper 时至少做到遵守目标网站的 robots.txt 和使用条款。控制请求频率设置 User-Agent 并确保可识别。只抓取公开、合法授权的数据。不以任何方式绕过登录、验证码或访问控制。涉及个人信息、版权内容时先确认授权范围再决定是否采集。探测阶段本身就应该把“网站不允许抓取”当成一个正常结果返回而不是把它当成要解决的问题。3. 工作原理从 probe 到 scraperProbeScraper 的核心设计可以拆成两个阶段probe 阶段和 scrape 阶段。probe 阶段只做轻量检查和确认scrape 阶段才真正执行数据抽取。3.1 probe 阶段检查什么一次典型的 probe 会按顺序执行以下检查robots.txt 检查拉取目标站点的 robots.txt判断请求路径是否在 Disallow 列表中。如果明确禁止直接返回不可抓取。HTTP 状态检查发起一个带预设 User-Agent 的 GET 或 HEAD 请求看返回状态码。200 正常403/401 可能被拦截404 可能是路径失效301/302 需要确认重定向目标。响应内容检查拉取目标页面 HTML检查是否存在反爬验证特征比如“captcha”“verify you are human”“安全验证”“刷新页面”等关键词。解析规则校验如果用户配置了 XPath 或 CSS 选择器probe 会在已拉取的 HTML 上执行这些选择器确认能匹配到元素。匹配不到就直接报错。内容编码检测读取响应头中的 charset并用实际内容做编码嗅探避免后续解析出现乱码。响应时间记录记录 DNS 解析、TCP 连接、首字节耗时方便判断站点是否因为限流或性能问题导致响应缓慢。3.2 伪代码示意下面这一段伪代码可以直观表达探测流程。注意这是通用逻辑具体实现以实际项目为准。def probe_site(site: dict) - dict: result {site: site[name], status: unknown, checks: {}} # 1. 检查 robots.txt robots_allowed check_robots_txt(site[url], site.get(user_agent)) result[checks][robots] robots_allowed if not robots_allowed[allowed]: result[status] blocked_by_robots return result # 2. 发送探测请求 try: resp requests.get( site[url], headers{User-Agent: site.get(user_agent, ProbeScraper/0.1)}, timeoutsite.get(timeout, 15) ) except Exception as e: result[status] request_failed result[error] str(e) return result result[checks][http_status] resp.status_code if resp.status_code ! 200: result[status] http_error return result # 3. 检测反爬验证页 if is_verification_page(resp.text): result[status] captcha_or_banned return result # 4. 校验解析选择器 if site.get(selectors): matched validate_selectors(resp.text, site[selectors]) result[checks][selectors] matched if not matched[ok]: result[status] selector_mismatch return result result[status] ready return result判断成功的标准就是 result[status] ready。一旦走到这一步工具才会进入真正的抓取流程。3.3 为什么先探测能减少无效请求从工程成本看一个批量任务如果包含 100 个站点直接抓取时可能中途挂了 50 个你需要排查日志、定位失败原因、调整规则、重新跑任务。而先探测后抓取的流程是100 个站点先全部进入 probe 队列。probe 输出 80 个“ready”、10 个“selector_mismatch”、5 个“blocked_by_robots”、5 个“request_failed”。你只需要处理失败的 20 个或者直接跳过它们。这里的核心收益是失败被提前隔离而不是等真正抓数据时再放大。探测请求和数据抓取请求的代价完全不一样探测阶段可以只拉一次页面就完成判断而错误的数据抓取可能要反复重试、多次请求加重目标站点负担。4. 环境准备与前置条件4.1 系统环境从项目类型看ProbeScraper 适合在 Linux 服务器或本地开发机上运行。如果是 Windows建议使用 WSL2 或 PowerShell 配合 Python 虚拟环境。macOS 直接跑 Python 3 即可。建议环境Python 3.9 或更高版本。pip 已配置可用源。联网正常DNS 解析无异常。4.2 安装基础依赖不要直接在全局 Python 环境里装依赖先隔离再安装。python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install --upgrade pip pip install requests beautifulsoup4 lxml pytest如果项目自带 requirements.txt直接使用pip install -r requirements.txt4.3 确认 Python 路径与 site 配置如果你需要排查依赖安装位置、确认 site-packages 路径可以用 Python 的 site 模块python -m site这个命令会输出 Python 的 site-packages 目录、USER_BASE、USER_SITE 等信息。在排查“依赖到底装到了哪里”时很实用特别是当你同时存在多套 Python 环境时。4.4 准备站点配置文件ProbeScraper 的常见用法是维护一个站点清单每个站点包含名称、入口 URL、请求头、解析选择器、超时时间、是否允许跟随重定向。一份 YAML 配置示例sites: - name: example_blog url: https://example.com/posts method: GET headers: User-Agent: Mozilla/5.0 (compatible; ProbeScraper/0.1) selectors: title: h1.post-title body: div.post-content list: ul.post-list li timeout: 15 follow_redirects: true - name: example_news url: https://news.example.org method: GET headers: User-Agent: ProbeScraper/0.1 selectors: headline: h2.headline timeout: 10 follow_redirects: false5. 安装部署与启动方式5.1 CLI 启动假设项目入口文件是main.py命令行启动可以设计成两种模式probe和scrape。# 只做探测 python main.py probe --config sites.yaml # 探测通过后直接抓取 python main.py scrape --config sites.yaml --output result.jsonlprobe模式只输出探测结果不会产生实际抓取。scrape模式内部会先调用 probe再对标记为 ready 的站点执行抓取。如果要指定单个站点python main.py probe --config sites.yaml --site example_blog5.2 API 服务启动支持 API 是这个项目的加分项。API 服务可以让前端页面、定时任务、其他服务统一调用。假设入口是api.pypython api.py --host 127.0.0.1 --port 8765启动成功后访问http://127.0.0.1:8765/docs可以查看接口文档。访问http://127.0.0.1:8765/health可以确认服务状态。调用POST /api/probe提交站点探测请求。5.3 Docker 启动如果你的采集环境统一用 Docker 管理可以构建一个镜像。下面是一个通用 Dockerfile 示例路径和入口需要按实际项目调整。FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8765 CMD [python, api.py, --host, 0.0.0.0, --port, 8765]构建并启动docker build -t probe-scraper . docker run -d --name probe-scraper -p 8765:8765 probe-scraper6. 功能测试与效果验证部署完成之后不要急着跑全量任务。先用一组小样本测试把 probe 阶段的行为摸清楚。6.1 准备测试站点建议准备四类测试站点类型预期行为可正常抓取的公开博客页面probe 返回 ready返回 404 或首页改版后的旧 URLprobe 返回 http_error 或 selector_mismatch返回 403 或有验证码页面的站点probe 返回 captcha_or_banned本地起一个 HTTP 服务做断网/慢响应测试probe 返回 request_failed第四类可以用 Python 本地起一个临时服务来模拟例如mkdir -p /tmp/test_html echo htmlbodyh1 classtitleHello/h1/body/html /tmp/test_html/index.html python -m http.server 8000 --directory /tmp/test_html然后配置一个站点指向http://127.0.0.1:8000/选择器写title: h1.title预期 probe 返回 ready。6.2 探测通过的标准执行探测后读输出结果。判断字段如下status ready站点可以抓取。status blocked_by_robotsrobots.txt 禁止跳过。status request_failed网络、DNS、TLS 等问题。status http_error状态码非 200需要检查 URL 是否正确。status captcha_or_banned可能被反爬策略拦截。status selector_mismatch页面能打开但解析规则已失效。6.3 测试解析规则校验假设配置了选择器title: h1.post-title但页面实际结构是div.article header h1。probe 阶段应该返回selector_mismatch并报告具体哪个选择器没有匹配到元素。预期输出示例{ site: example_blog, status: selector_mismatch, checks: { robots: {allowed: true}, http_status: 200, selectors: { ok: false, failed: [title], message: Selector h1.post-title did not match any element } } }这个功能非常实用。它相当于给每个规则增加了一个“自检”避免改版后静默产出空数据。6.4 验证是否进入抓取流程探测成功后执行 scrape 模式观察输出文件是否包含结构化的条目。字段是否与配置的选择器一一对应。抓取过程中是否出现重复请求、超时、断连。日志中是否记录了每个站点的开始时间、结束时间、抓取条目数。如果一切正常说明从 probe 到 scrape 的主链路已经打通。7. 接口 API 调用与批量任务7.1 提交单个探测任务API 模式下第三方工具可以统一调用。下面是一个 Python 客户端示例import requests import json api_url http://127.0.0.1:8765 # 先探测 probe_payload { site: { name: example_blog, url: https://example.com/posts, user_agent: Mozilla/5.0 (compatible; ProbeScraper/0.1), timeout: 15, selectors: { title: h1.post-title } } } resp requests.post(f{api_url}/api/probe, jsonprobe_payload, timeout30) print(resp.status_code) print(json.dumps(resp.json(), ensure_asciiFalse, indent2))如果探测返回ready再提交抓取任务。7.2 提交批量任务批量任务不能只依赖单个请求需要走队列或清单。一个简单的批量任务目录结构jobs/ ├── sites/ │ ├── blog.yml │ ├── news.yml │ └── docs.yml ├── output/ │ └── 2025-01-01/批量提交流程遍历sites/下的配置文件逐一向 API 提交探测任务拿到结果后汇总。import glob import yaml import requests import json api_url http://127.0.0.1:8765 for config_path in glob.glob(jobs/sites/*.yml): with open(config_path, r, encodingutf-8) as f: site yaml.safe_load(f) probe_resp requests.post(f{api_url}/api/probe, json{site: site}, timeout30) probe_result probe_resp.json() if probe_result.get(status) ready: scrape_resp requests.post( f{api_url}/api/scrape, json{site: site}, timeout120 ) print(site[name], scraped, items:, len(scrape_resp.json().get(items, []))) else: print(site[name], skipped, reason:, probe_result.get(status))7.3 任务结果与重试批量任务要考虑失败重试。建议对以下两类错误设置不同的重试策略request_failed、http_error可能是临时网络问题或目标站抖动适合退避重试比如 3 次指数退避。blocked_by_robots、captcha_or_banned、selector_mismatch重试意义不大应该直接落库并标记为“需要人工确认”。重试示例import time def run_with_retry(func, max_retries3): for attempt in range(max_retries): try: return func() except requests.RequestException as e: if attempt max_retries - 1: raise time.sleep(2 ** attempt) return None7.4 API 返回格式建议为了让前端和其他服务好对接API 统一返回一种格式会方便很多{ success: true, data: { task_id: task_20250101_001, status: ready, message: OK }, error: null }这样调用方不用解析复杂嵌套结构直接看success和data.status就行。8. 资源占用与性能观察8.1 资源占用特点ProbeScraper 是纯 CPU 和网络 I/O 工具不依赖 GPU所以资源占用主要体现在网络请求带来的等待时间。Python 进程本身的内存占用通常在几十 MB 到几百 MB取决于并发数和页面大小。大批量任务时日志和输出文件会持续增长磁盘空间需要考虑。8.2 观察指标运行任务时建议观察以下几个指标CPU 占用一般不会持续满载只有解析大 HTML 时会短暂升高。内存占用如果并发过高或者单页面返回几十 MB HTML内存会显著上升。网络连接数大量并发请求时可能会触发目标站限流。任务耗时分布probe 阶段很快scrape 阶段慢这是正常现象。8.3 控制并发与限速不要以最高速度跑批量任务。合理做法是单站点并发设为 1 到 2。跨站点并发设为 5 到 10。每次请求之间增加随机延迟例如 1 到 3 秒。import random import time def polite_sleep(min_seconds1, max_seconds3): time.sleep(random.uniform(min_seconds, max_seconds))8.4 显存占用说明这类工具不涉及模型推理不需要显卡不存在显存占用问题。如果你的采集任务后续接入本地 NLP 模型做内容抽取那是另外一回事需要单独评估模型显存需求。9. 常见问题与排查方法问题现象可能原因排查方式解决方案probe 提示 request_failedDNS 解析失败、目标站不可达、TLS 校验失败检查 ping/curl 访问情况更换 DNS关闭非必要证书校验确认网络出口返回 403 或验证页被反爬拦截User-Agent 异常IP 被限流打开页面手动查看是否出现验证码调整 User-Agent降低频率配置代理出口robots.txt 直接禁止抓取目标站点明确声明不允许查看响应里的 robots 字段停止抓取该站点遵守规则selector_mismatch 频繁出现目标网站改版、选择器写错抓取 HTML 样本手动验证选择器更新选择器建立站点巡检任务页面内容乱码编码检测失败charset 与真实编码不一致查看响应头和页面 meta charset在配置中显式指定 encodingAPI 服务启动后访问不到端口被占用监听地址错误防火墙查看启动日志检查 netstat更换端口监听 0.0.0.0放行防火墙批量任务中途卡住某个站点响应超时没有设置 timeout查看日志定位卡住站点增加全局超时和单请求超时输出文件为空探测阶段实际失败但任务未跳过查看 probe 结果修正站点配置或强制跳过不可抓取站点排查顺序建议先看日志再对比 probe 输出最后手动用 curl 验证目标站。不要一上来就改代码。10. 最佳实践与使用建议10.1 第一次先小批量探测不要一上来就提交 100 个站点。先取 3 到 5 个不同结构的站点跑一遍确认配置解析正确。probe 阶段能区分不同失败类型。scrape 输出内容符合预期。10.2 维护一套最小站点配置把测试站点、样例站点单独放在一个examples/目录作为回归测试集。以后改动了解析逻辑、探测逻辑先跑这个目录能快速发现功能退化。10.3 规范目录管理建议固定目录结构probe-scraper/ ├── configs/ # 正式站点配置 ├── examples/ # 样例测试配置 ├── jobs/ # 批量任务输入 ├── output/ # 抓取结果 ├── logs/ # 运行日志 └── scripts/ # 辅助脚本输入、输出、日志分开后续写定时任务和故障排查都会轻松很多。10.4 批量任务加日志和重试批量任务必须加日志。至少记录每个站点的 start_time、end_time。probe 状态。抓取条目数。失败原因和重试次数。没有日志的批量任务一旦失败排查成本会非常高。10.5 接口服务限制访问范围如果 API 服务部署在公网必须限制访问。至少做到绑定非公网地址必要时用内网访问。增加 API Token 或简单鉴权。对单 IP 限制调用频率。日志记录请求来源。10.6 合规与版权任何采集任务在你动手之前都要确认目标站点是否允许爬虫。数据是否涉及个人隐私。内容是否受版权保护。你的使用方式是否在授权范围内。ProbeScraper 的价值恰恰在于它把“能不能抓”这个判断放到任务最前面让你在启动抓取之前就先遵守规则而不是等被抓取后再考虑合规问题。10.7 对站点结构变化保持敏感网站改版后解析规则失效是常态。建议定期对已配置站点执行一次 probe-only 巡检把 selector_mismatch 的任务列为“需要更新配置”而不要等到用户反馈后才处理。11. 总结与下一步这个项目最值得尝试的点是它把“站点是否可抓取”变成了一次显式的、可观测的 probe 步骤而不是藏在错误日志里。读完这篇文章你最先应该验证的是拿一个已知能正常抓取的博客页面和一个已经失效的旧 URL 分别跑一次 probe观察输出结果是否能区分ready、http_error和selector_mismatch。最容易踩的坑有两个一是给 probe 阶段设置的超时过短导致正常站点被误判二是把 probe 结果等同于抓取成功忽略了后续页面深度、内容格式等问题。建议把 probe 当作“入口检查”把 scrape 后的数据校验当成另一个独立检查环节。后续可以扩展的方向包括把探测结果写入时序数据库做站点健康看板接入 Playwright 处理 JS 渲染页面给 API 服务增加任务队列让批量任务通过消息中间件异步执行以及在 scrape 阶段增加数据质量校验比如字段缺失率、重复率、内容相似度。如果你正在维护一组容易“悄悄失效”的采集任务不妨先给它们加一层 probe 前置检查。这可能是投入产出比最高的一次小改动。
爬虫先探测再抓取：ProbeScraper工具解析与实战
最近在 Hacker News 上看到一个很有意思的项目Show HN: Scraper that probes a site before promising it works。一句话概括设计思路在承诺“我能抓这个站”之前先对目标站点做一次探测。这个思路看起来简单但对做爬虫工程的人来说几乎打中了日常最大痛点——配置了一整套规则真正跑起来才发现网站早就改版、加了登录墙、换了反爬策略或者 robots.txt 已经明确禁止抓取。与其等到批量任务跑完再收拾一堆无效数据不如在任务开始前就用一个 probe 阶段把所有潜在问题暴露出来。为了便于叙述下文用 ProbeScraper 作为这个项目的代称。这篇文章会围绕它的核心能力、适用边界、部署方式、探测流程、API 调用和批量任务展开重点说明为什么“先探测、再抓取”能节约开发时间、减少无效请求以及如何把它接到自己的数据采集链路里。在往下读之前先想三个问题你现在的爬虫任务有没有一上来就盲目请求目标网站直到反爬响应或结构变化后才发现问题你的站点解析规则有没有因为目标网站改版而突然失效你的批量采集任务有多少是跑了很久才发现整体失败如果对这三个问题有共鸣这篇文章建议收藏。先看核心能力速览。1. ProbeScraper 核心能力速览能力项说明项目类型站点探测 网页爬虫工具核心卖点抓取前先 probe 目标站点确认可抓取后再执行采集探测对象robots.txt、HTTP 状态码、页面结构、反爬验证页、编码主要功能站点可用性检查、解析规则校验、批量任务、API 服务运行平台Windows / Linux / macOS硬件要求极低CPU 即可无 GPU 依赖推荐环境Python 3.9依赖 requests、lxml、BeautifulSoup4启动方式CLI 命令、API 服务、Docker 容器是否支持 API支持可提供 JSON 接口是否支持批量任务支持按站点清单批量探测和抓取适合场景数据采集工程、爬虫巡检、网站结构监控、自动化测试从材料看这个项目并不依赖特定显卡或深度学习框架本质上是工程型工具。它不适合用来处理验证码绕过、JS 渲染破解等高对抗场景核心价值是“把能爬的站快速爬好把不能爬的站提前识别出来”。2. 适用场景与使用边界2.1 这个工具适合谁先说适合的人爬虫脚本经常跑挂的开发者。如果你维护过几十个站点采集任务一定遇到过“某天某个站突然返回 403但脚本还在跑最后全量失败”的情况。ProbeScraper 的设计就是让这类问题在任务启动前暴露。做数据采集平台或采集服务的团队。在用户提交一个采集任务时先执行 probe如果探测不过直接返回“该站点暂不支持采集”或“需要人工确认”比任务跑到一半再失败要友好得多。做网站结构监控的人。网站改版后解析规则会失效。ProbeScraper 的“选择器校验”功能可以在规则失效时及时告警。自动化测试工程师。把 probe 当成一个只读的 URL 健康检查工具检查站点首页是否 200、robots.txt 是否限制、是否出现反爬验证页面。2.2 什么场景不适合高并发高强度抓取。这类工具的定位是先探测、再小批量验证不适合直接用几十个线程冲某个站点。需要登录才能访问的内容。如果目标页面在登录墙后面probe 只能验证登录页是否能访问无法真实评估登录后的数据解析情况。需要渲染 JS 的动态页面。如果目标依赖浏览器渲染probe 阶段需要额外接入 Playwright 或 Selenium否则只能探测到空壳 HTML。以绕过访问控制为目的的行为。这不是工具该干的事也不应该在工程里出现。2.3 合规边界任何爬虫工具都要强调合规。使用 ProbeScraper 时至少做到遵守目标网站的 robots.txt 和使用条款。控制请求频率设置 User-Agent 并确保可识别。只抓取公开、合法授权的数据。不以任何方式绕过登录、验证码或访问控制。涉及个人信息、版权内容时先确认授权范围再决定是否采集。探测阶段本身就应该把“网站不允许抓取”当成一个正常结果返回而不是把它当成要解决的问题。3. 工作原理从 probe 到 scraperProbeScraper 的核心设计可以拆成两个阶段probe 阶段和 scrape 阶段。probe 阶段只做轻量检查和确认scrape 阶段才真正执行数据抽取。3.1 probe 阶段检查什么一次典型的 probe 会按顺序执行以下检查robots.txt 检查拉取目标站点的 robots.txt判断请求路径是否在 Disallow 列表中。如果明确禁止直接返回不可抓取。HTTP 状态检查发起一个带预设 User-Agent 的 GET 或 HEAD 请求看返回状态码。200 正常403/401 可能被拦截404 可能是路径失效301/302 需要确认重定向目标。响应内容检查拉取目标页面 HTML检查是否存在反爬验证特征比如“captcha”“verify you are human”“安全验证”“刷新页面”等关键词。解析规则校验如果用户配置了 XPath 或 CSS 选择器probe 会在已拉取的 HTML 上执行这些选择器确认能匹配到元素。匹配不到就直接报错。内容编码检测读取响应头中的 charset并用实际内容做编码嗅探避免后续解析出现乱码。响应时间记录记录 DNS 解析、TCP 连接、首字节耗时方便判断站点是否因为限流或性能问题导致响应缓慢。3.2 伪代码示意下面这一段伪代码可以直观表达探测流程。注意这是通用逻辑具体实现以实际项目为准。def probe_site(site: dict) - dict: result {site: site[name], status: unknown, checks: {}} # 1. 检查 robots.txt robots_allowed check_robots_txt(site[url], site.get(user_agent)) result[checks][robots] robots_allowed if not robots_allowed[allowed]: result[status] blocked_by_robots return result # 2. 发送探测请求 try: resp requests.get( site[url], headers{User-Agent: site.get(user_agent, ProbeScraper/0.1)}, timeoutsite.get(timeout, 15) ) except Exception as e: result[status] request_failed result[error] str(e) return result result[checks][http_status] resp.status_code if resp.status_code ! 200: result[status] http_error return result # 3. 检测反爬验证页 if is_verification_page(resp.text): result[status] captcha_or_banned return result # 4. 校验解析选择器 if site.get(selectors): matched validate_selectors(resp.text, site[selectors]) result[checks][selectors] matched if not matched[ok]: result[status] selector_mismatch return result result[status] ready return result判断成功的标准就是 result[status] ready。一旦走到这一步工具才会进入真正的抓取流程。3.3 为什么先探测能减少无效请求从工程成本看一个批量任务如果包含 100 个站点直接抓取时可能中途挂了 50 个你需要排查日志、定位失败原因、调整规则、重新跑任务。而先探测后抓取的流程是100 个站点先全部进入 probe 队列。probe 输出 80 个“ready”、10 个“selector_mismatch”、5 个“blocked_by_robots”、5 个“request_failed”。你只需要处理失败的 20 个或者直接跳过它们。这里的核心收益是失败被提前隔离而不是等真正抓数据时再放大。探测请求和数据抓取请求的代价完全不一样探测阶段可以只拉一次页面就完成判断而错误的数据抓取可能要反复重试、多次请求加重目标站点负担。4. 环境准备与前置条件4.1 系统环境从项目类型看ProbeScraper 适合在 Linux 服务器或本地开发机上运行。如果是 Windows建议使用 WSL2 或 PowerShell 配合 Python 虚拟环境。macOS 直接跑 Python 3 即可。建议环境Python 3.9 或更高版本。pip 已配置可用源。联网正常DNS 解析无异常。4.2 安装基础依赖不要直接在全局 Python 环境里装依赖先隔离再安装。python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install --upgrade pip pip install requests beautifulsoup4 lxml pytest如果项目自带 requirements.txt直接使用pip install -r requirements.txt4.3 确认 Python 路径与 site 配置如果你需要排查依赖安装位置、确认 site-packages 路径可以用 Python 的 site 模块python -m site这个命令会输出 Python 的 site-packages 目录、USER_BASE、USER_SITE 等信息。在排查“依赖到底装到了哪里”时很实用特别是当你同时存在多套 Python 环境时。4.4 准备站点配置文件ProbeScraper 的常见用法是维护一个站点清单每个站点包含名称、入口 URL、请求头、解析选择器、超时时间、是否允许跟随重定向。一份 YAML 配置示例sites: - name: example_blog url: https://example.com/posts method: GET headers: User-Agent: Mozilla/5.0 (compatible; ProbeScraper/0.1) selectors: title: h1.post-title body: div.post-content list: ul.post-list li timeout: 15 follow_redirects: true - name: example_news url: https://news.example.org method: GET headers: User-Agent: ProbeScraper/0.1 selectors: headline: h2.headline timeout: 10 follow_redirects: false5. 安装部署与启动方式5.1 CLI 启动假设项目入口文件是main.py命令行启动可以设计成两种模式probe和scrape。# 只做探测 python main.py probe --config sites.yaml # 探测通过后直接抓取 python main.py scrape --config sites.yaml --output result.jsonlprobe模式只输出探测结果不会产生实际抓取。scrape模式内部会先调用 probe再对标记为 ready 的站点执行抓取。如果要指定单个站点python main.py probe --config sites.yaml --site example_blog5.2 API 服务启动支持 API 是这个项目的加分项。API 服务可以让前端页面、定时任务、其他服务统一调用。假设入口是api.pypython api.py --host 127.0.0.1 --port 8765启动成功后访问http://127.0.0.1:8765/docs可以查看接口文档。访问http://127.0.0.1:8765/health可以确认服务状态。调用POST /api/probe提交站点探测请求。5.3 Docker 启动如果你的采集环境统一用 Docker 管理可以构建一个镜像。下面是一个通用 Dockerfile 示例路径和入口需要按实际项目调整。FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8765 CMD [python, api.py, --host, 0.0.0.0, --port, 8765]构建并启动docker build -t probe-scraper . docker run -d --name probe-scraper -p 8765:8765 probe-scraper6. 功能测试与效果验证部署完成之后不要急着跑全量任务。先用一组小样本测试把 probe 阶段的行为摸清楚。6.1 准备测试站点建议准备四类测试站点类型预期行为可正常抓取的公开博客页面probe 返回 ready返回 404 或首页改版后的旧 URLprobe 返回 http_error 或 selector_mismatch返回 403 或有验证码页面的站点probe 返回 captcha_or_banned本地起一个 HTTP 服务做断网/慢响应测试probe 返回 request_failed第四类可以用 Python 本地起一个临时服务来模拟例如mkdir -p /tmp/test_html echo htmlbodyh1 classtitleHello/h1/body/html /tmp/test_html/index.html python -m http.server 8000 --directory /tmp/test_html然后配置一个站点指向http://127.0.0.1:8000/选择器写title: h1.title预期 probe 返回 ready。6.2 探测通过的标准执行探测后读输出结果。判断字段如下status ready站点可以抓取。status blocked_by_robotsrobots.txt 禁止跳过。status request_failed网络、DNS、TLS 等问题。status http_error状态码非 200需要检查 URL 是否正确。status captcha_or_banned可能被反爬策略拦截。status selector_mismatch页面能打开但解析规则已失效。6.3 测试解析规则校验假设配置了选择器title: h1.post-title但页面实际结构是div.article header h1。probe 阶段应该返回selector_mismatch并报告具体哪个选择器没有匹配到元素。预期输出示例{ site: example_blog, status: selector_mismatch, checks: { robots: {allowed: true}, http_status: 200, selectors: { ok: false, failed: [title], message: Selector h1.post-title did not match any element } } }这个功能非常实用。它相当于给每个规则增加了一个“自检”避免改版后静默产出空数据。6.4 验证是否进入抓取流程探测成功后执行 scrape 模式观察输出文件是否包含结构化的条目。字段是否与配置的选择器一一对应。抓取过程中是否出现重复请求、超时、断连。日志中是否记录了每个站点的开始时间、结束时间、抓取条目数。如果一切正常说明从 probe 到 scrape 的主链路已经打通。7. 接口 API 调用与批量任务7.1 提交单个探测任务API 模式下第三方工具可以统一调用。下面是一个 Python 客户端示例import requests import json api_url http://127.0.0.1:8765 # 先探测 probe_payload { site: { name: example_blog, url: https://example.com/posts, user_agent: Mozilla/5.0 (compatible; ProbeScraper/0.1), timeout: 15, selectors: { title: h1.post-title } } } resp requests.post(f{api_url}/api/probe, jsonprobe_payload, timeout30) print(resp.status_code) print(json.dumps(resp.json(), ensure_asciiFalse, indent2))如果探测返回ready再提交抓取任务。7.2 提交批量任务批量任务不能只依赖单个请求需要走队列或清单。一个简单的批量任务目录结构jobs/ ├── sites/ │ ├── blog.yml │ ├── news.yml │ └── docs.yml ├── output/ │ └── 2025-01-01/批量提交流程遍历sites/下的配置文件逐一向 API 提交探测任务拿到结果后汇总。import glob import yaml import requests import json api_url http://127.0.0.1:8765 for config_path in glob.glob(jobs/sites/*.yml): with open(config_path, r, encodingutf-8) as f: site yaml.safe_load(f) probe_resp requests.post(f{api_url}/api/probe, json{site: site}, timeout30) probe_result probe_resp.json() if probe_result.get(status) ready: scrape_resp requests.post( f{api_url}/api/scrape, json{site: site}, timeout120 ) print(site[name], scraped, items:, len(scrape_resp.json().get(items, []))) else: print(site[name], skipped, reason:, probe_result.get(status))7.3 任务结果与重试批量任务要考虑失败重试。建议对以下两类错误设置不同的重试策略request_failed、http_error可能是临时网络问题或目标站抖动适合退避重试比如 3 次指数退避。blocked_by_robots、captcha_or_banned、selector_mismatch重试意义不大应该直接落库并标记为“需要人工确认”。重试示例import time def run_with_retry(func, max_retries3): for attempt in range(max_retries): try: return func() except requests.RequestException as e: if attempt max_retries - 1: raise time.sleep(2 ** attempt) return None7.4 API 返回格式建议为了让前端和其他服务好对接API 统一返回一种格式会方便很多{ success: true, data: { task_id: task_20250101_001, status: ready, message: OK }, error: null }这样调用方不用解析复杂嵌套结构直接看success和data.status就行。8. 资源占用与性能观察8.1 资源占用特点ProbeScraper 是纯 CPU 和网络 I/O 工具不依赖 GPU所以资源占用主要体现在网络请求带来的等待时间。Python 进程本身的内存占用通常在几十 MB 到几百 MB取决于并发数和页面大小。大批量任务时日志和输出文件会持续增长磁盘空间需要考虑。8.2 观察指标运行任务时建议观察以下几个指标CPU 占用一般不会持续满载只有解析大 HTML 时会短暂升高。内存占用如果并发过高或者单页面返回几十 MB HTML内存会显著上升。网络连接数大量并发请求时可能会触发目标站限流。任务耗时分布probe 阶段很快scrape 阶段慢这是正常现象。8.3 控制并发与限速不要以最高速度跑批量任务。合理做法是单站点并发设为 1 到 2。跨站点并发设为 5 到 10。每次请求之间增加随机延迟例如 1 到 3 秒。import random import time def polite_sleep(min_seconds1, max_seconds3): time.sleep(random.uniform(min_seconds, max_seconds))8.4 显存占用说明这类工具不涉及模型推理不需要显卡不存在显存占用问题。如果你的采集任务后续接入本地 NLP 模型做内容抽取那是另外一回事需要单独评估模型显存需求。9. 常见问题与排查方法问题现象可能原因排查方式解决方案probe 提示 request_failedDNS 解析失败、目标站不可达、TLS 校验失败检查 ping/curl 访问情况更换 DNS关闭非必要证书校验确认网络出口返回 403 或验证页被反爬拦截User-Agent 异常IP 被限流打开页面手动查看是否出现验证码调整 User-Agent降低频率配置代理出口robots.txt 直接禁止抓取目标站点明确声明不允许查看响应里的 robots 字段停止抓取该站点遵守规则selector_mismatch 频繁出现目标网站改版、选择器写错抓取 HTML 样本手动验证选择器更新选择器建立站点巡检任务页面内容乱码编码检测失败charset 与真实编码不一致查看响应头和页面 meta charset在配置中显式指定 encodingAPI 服务启动后访问不到端口被占用监听地址错误防火墙查看启动日志检查 netstat更换端口监听 0.0.0.0放行防火墙批量任务中途卡住某个站点响应超时没有设置 timeout查看日志定位卡住站点增加全局超时和单请求超时输出文件为空探测阶段实际失败但任务未跳过查看 probe 结果修正站点配置或强制跳过不可抓取站点排查顺序建议先看日志再对比 probe 输出最后手动用 curl 验证目标站。不要一上来就改代码。10. 最佳实践与使用建议10.1 第一次先小批量探测不要一上来就提交 100 个站点。先取 3 到 5 个不同结构的站点跑一遍确认配置解析正确。probe 阶段能区分不同失败类型。scrape 输出内容符合预期。10.2 维护一套最小站点配置把测试站点、样例站点单独放在一个examples/目录作为回归测试集。以后改动了解析逻辑、探测逻辑先跑这个目录能快速发现功能退化。10.3 规范目录管理建议固定目录结构probe-scraper/ ├── configs/ # 正式站点配置 ├── examples/ # 样例测试配置 ├── jobs/ # 批量任务输入 ├── output/ # 抓取结果 ├── logs/ # 运行日志 └── scripts/ # 辅助脚本输入、输出、日志分开后续写定时任务和故障排查都会轻松很多。10.4 批量任务加日志和重试批量任务必须加日志。至少记录每个站点的 start_time、end_time。probe 状态。抓取条目数。失败原因和重试次数。没有日志的批量任务一旦失败排查成本会非常高。10.5 接口服务限制访问范围如果 API 服务部署在公网必须限制访问。至少做到绑定非公网地址必要时用内网访问。增加 API Token 或简单鉴权。对单 IP 限制调用频率。日志记录请求来源。10.6 合规与版权任何采集任务在你动手之前都要确认目标站点是否允许爬虫。数据是否涉及个人隐私。内容是否受版权保护。你的使用方式是否在授权范围内。ProbeScraper 的价值恰恰在于它把“能不能抓”这个判断放到任务最前面让你在启动抓取之前就先遵守规则而不是等被抓取后再考虑合规问题。10.7 对站点结构变化保持敏感网站改版后解析规则失效是常态。建议定期对已配置站点执行一次 probe-only 巡检把 selector_mismatch 的任务列为“需要更新配置”而不要等到用户反馈后才处理。11. 总结与下一步这个项目最值得尝试的点是它把“站点是否可抓取”变成了一次显式的、可观测的 probe 步骤而不是藏在错误日志里。读完这篇文章你最先应该验证的是拿一个已知能正常抓取的博客页面和一个已经失效的旧 URL 分别跑一次 probe观察输出结果是否能区分ready、http_error和selector_mismatch。最容易踩的坑有两个一是给 probe 阶段设置的超时过短导致正常站点被误判二是把 probe 结果等同于抓取成功忽略了后续页面深度、内容格式等问题。建议把 probe 当作“入口检查”把 scrape 后的数据校验当成另一个独立检查环节。后续可以扩展的方向包括把探测结果写入时序数据库做站点健康看板接入 Playwright 处理 JS 渲染页面给 API 服务增加任务队列让批量任务通过消息中间件异步执行以及在 scrape 阶段增加数据质量校验比如字段缺失率、重复率、内容相似度。如果你正在维护一组容易“悄悄失效”的采集任务不妨先给它们加一层 probe 前置检查。这可能是投入产出比最高的一次小改动。
