采购网爬虫实战：从请求策略到增量采集的完整方案-育师

简介：这是一套用于采购公开数据采集的爬虫项目源码，面向需要招投标数据、标讯监控或市场调研的开发者，适合有一定Python基础并希望了解反爬与自动化流程的读者。资源包共9个文件，压缩包仅24KB，包含3个Python源文件、2个编译后的pyc文件、1个Excel样例数据文件，以及txt、inscode、md等配置说明和文档辅助文件。目前已有35人学习/下载。程序通过随机HTTP请求头规避反爬，支持分页爬取和动态详情链接提取，数据模块自动过滤重复记录，邮件通知模块生成HTML内容并发送，主程序将采集、清洗、保存到通知的流程整合为完整自动化方案，模块划分清晰，便于维护。附带配置文件、依赖清单与使用注意事项，可直接运行或按需修改，覆盖请求伪装、页面解析、数据去重、邮件通知等关键环节，适合作为招投标数据采集项目的起步模板。

1. 采购网爬虫到底在爬什么：先想清楚这是不是一个值得投入的工程

采购网爬虫这个名字听起来像是一个入门练手项目，但真正落过地的人知道，它是个典型的“看着简单、做起来全是细节”的场景。任何一个采购平台，从政府级公告站点到企业电子采购系统，页面结构、反爬策略、数据字段规范都不一样，有的甚至同时存在服务端渲染和前端动态渲染两套页面体系。你写的不是“一个爬虫”，而是一套能应对多个站点差异、稳定运行、能断点续爬、能把脏数据清洗入库的采集系统。

这个方向解决的核心问题很直接：某公司需要持续监控某采购平台的招标公告与中标结果，手动刷网页完全不可行，人工录入还会漏掉关键字段。用采购网爬虫把页面数据转成结构化的公告记录，沉淀成自己的数据资产，这是做供应商分析、价格趋势研究、同类项目投标策略的基础。适合谁做？运维工程师、数据分析师、接单开发的个人开发者，以及需要采购行为数据做研究的团队。

2. 采购网爬虫的请求层：先摸清目标站点，再决定请求策略

采购网爬虫与普通内容站爬虫最大的不同在于：采购公告页面的数据密度低、站点跳转深，而且很多平台对访问频率异常敏感。我在做这类项目时，第一个动手步骤不是写代码，而是花几个小时打开目标站点，按 F12 观察它的请求序列，记录哪些接口返回完整 JSON，哪些页面是纯服务端渲染。这个动作决定了后面 80% 的编码工作量。

2.1 目标结构分析：先确认数据到底在 HTML 里还是在接口里

任何一个采购网站在浏览器里呈现的内容，其来源只有三种：直接写在 HTML 源码里、由 JavaScript 异步加载后填充到页面、藏在 iframe 子页面里。打开目标公告列表页，用浏览器的“查看网页源代码”功能搜索一条公告标题。如果能在 HTML 里搜到，那就走 requests + BeautifulSoup 的传统路线；如果搜不到，说明页面经过 front-end 渲染，需要找到真正的异步数据接口；更隐蔽的情况是公告正文放在 iframe 里，列表页只是一个壳，此时要找到 iframe 的 src 属性，把采集目标切换到那个子页面地址。

import requests from bs4 import BeautifulSoup headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://example.com/", "Accept": "text/html,application/xhtml+xml", } resp = requests.get("https://example.com/notices/list", headers=headers, timeout=10) soup = BeautifulSoup(resp.text, "html.parser") # 检查标题是否在原始 HTML 中 first_title = soup.select_one(".notice-title a") if first_title: print("服务端渲染，可直接解析列表页") else: print("动态渲染，需要定位异步接口")

逻辑说明：先用普通 GET 请求拉回列表页源码，再用一个典型的选择器去探测页面里是否存在列表项标题。这个探测动作虽然简单，却是后续所有策略的分水岭。如果服务端渲染，直接解析即可；如果动态渲染，就要切到接口层去挖掘 JSON 数据。

参数说明：timeout 设置 10 秒是采购网这类政务站点的常见保守值，站点响应经常偏慢，设为 5 秒容易误报超时；Referer 用站点首页，很多平台在请求头校验时会检查这个字段是否来自站内，直接留空或写错域名会被 WAF 拦截。

2.2 请求头伪装与频率控制：最小可用配置与翻车界限

很多初学者做采购网爬虫时一大误区是疯狂堆请求头，把几十个字段全部伪造一遍。实际跑下来会发现采购平台的反爬核心校验只有三样：User-Agent 是否真实、Referer 是否站内、单 IP 请求频率是否超过人类行为阈值。保持一个完整的浏览器系 User-Agent，带上 Referer，再加一个随机延时，成功率远比堆砌所有请求头要高。

import time import random import requests from requests.adapters import HTTPAdapter session = requests.Session() session.mount("https://", HTTPAdapter(max_retries=3)) def fetch_page(session, url): ua_list = [ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36", ] headers = { "User-Agent": random.choice(ua_list), "Referer": "https://example.com/", } resp = session.get(url, headers=headers, timeout=10) # 非 200 状态码视为本次请求失败 resp.raise_for_status() return resp # 主循环中每次请求后随机睡眠 for page_no in range(1, 6): url = f"https://example.com/notices/list?page={page_no}" resp = fetch_page(session, url) print(f"page {page_no} status: {resp.status_code}") time.sleep(random.uniform(3, 8))

逻辑说明：用 requests.Session 复用连接池，避免频繁建立 TCP 连接导致 IP 行为异常；User-Agent 池里只放两三个真实浏览器版本，每次随机选中一个。random.uniform(3, 8) 让相邻两次请求间隔在 3 到 8 秒之间抖动，这是一个经过多个采购站点验证过的安全区间。

参数说明：max_retries=3 解决的是瞬态网络波动，不是反爬绕过；如果连续 3 次失败还拿不到内容，说明问题出在 IP 被限制或账号登录态失效，重试已经没意义。这里的 session 必须是全局复用的对象，不能每次请求新建，否则 cookie、连接池都无法维持，行为特征会非常机器人化。

除了频率控制，我一般还会给每个公告详情页的请求之前加一个 and 条件：如果列表解析结果为空，直接停止当前批次采集，进入检查逻辑。这个习惯是从翻车经历里学到的——某个采购平台某天改版，页码参数全部失效，爬虫抓回一堆重复的首页数据还浑然不觉，等到入库时才发现全库都被污染了。

3. 采购网爬虫的解析实战：从列表页到详情页的字段提取方案

请求层解决的是“能不能拿到页面”的问题，解析层解决的是“拿到的页面里能不能准确抽出字段”的问题。采购网爬虫的数据价值集中在少数关键字段上：公告标题、发布时间、采购人、预算金额、中标供应商、中标金额，以及公告正文全文。这些字段的位置在页面里的表现形式千差万别，有的在表格里，有的在段落里，有的混在正文 HTML 字符串里。

3.1 列表页解析：拿到公告链接和基础元信息

列表页的解析目标只有一个：拿到该页所有公告的详情页 URL 和发布机构。不要试图在列表页把所有字段都解析完，列表页通常只展示标题、时间和来源部门，金额和供应商信息都在详情页里。把列表页解析职责收敛到最小，可以减少后续因字段缺失导致的混乱。

def parse_list(html: str): soup = BeautifulSoup(html, "html.parser") items = [] for li in soup.select("#list li a"): title = li.get_text(strip=True) href = li.get("href") if not href: continue if not href.startswith("http"): href = "https://example.com" + href items.append({"title": title, "url": href}) return items

逻辑说明：选择器 #list li a 是大多数采购网公告列表页的典型 DOM 结构，实际站点要根据源码微调。这里最关键的是链接拼接逻辑，很多站点的 href 是相对路径，不补全域名会导致后续请求直接失败。

参数说明：get_text(strip=True) 会去掉标题里的换行和多余空格，采购公告标题常常带全角空格，这个参数能省去一次后续清洗。continue 跳过空 href 的链接，是因为部分列表页会在底部插入不必要的“更多”链接，href 为空时直接忽略。

3.2 详情页正文提取：容器选择器优先，正则兜底

详情页解析是采购网爬虫翻车最多的地方。同一个站点的详情页在不同历史阶段可能用过不同的正文容器类名，有的用 “content”，有的用 “article-content”，有的干脆没有类名，只有一个 div。我的做法是维护一个候选容器选择器列表，依次尝试，哪个容器命中的文本长度最长，就用哪个作为正文容器。

import re def extract_article(soup): # 候选容器选择器，按优先级排列 candidates = [ "div.article-content", "div#content", "div.TRS_Editor", "div.custom-txt", ] best_content = "" for selector in candidates: node = soup.select_one(selector) if not node: continue text = node.get_text("\n", strip=True) if len(text) > len(best_content): best_content = text if best_content: return best_content # 兜底：直接从 script 变量里提取 JSON 字符串中的正文 script_text = soup.find("script", text=re.compile(r"content")) m = re.search(r'"content":"(.*?)","pubDate"', script_text, re.S) if m: return m.group(1).encode("utf-8").decode("unicode_escape") return ""

逻辑说明：先匹配若干个常见正文容器类名，取文本最长的那个，这个逻辑自然兼容了不同历史版本的页面结构。兜底方案针对的是以 JSON 字符串形式内嵌在 script 标签里的公告内容，这种格式在采购平台里出现频率很高，用正则提取时要注意字符串被转义，所以最后要做一次 unicode_escape 解码。

参数说明：get_text("\n", strip=True) 里的换行符参数很关键，把段落之间的边界保留下来，避免正文所有段落糊成一大团；正则里的 “pubDate” 是从实际经验中归纳出的锚点字段，写在公告 JSON 里紧随正文之后，如果没有这个锚点，提取会越过正文边界。

3.3 结构化字段的清洗与归一化：金额、日期、供应商名称

从正文或表格里提取出的原始字符串几乎都不是干净的。预算金额可能是“预算金额：12.5万元人民币”，中标供应商可能是“第一名：某建设有限公司”，日期可能是“二〇二三年七月六日”。这些字段不处理，入库之后完全无法做聚合分析。

def clean_money(raw: str): if not raw: return None text = raw.replace(",", "").replace("，", "") m = re.search(r"(\d+(?:\.\d+)?)\s*万元", text) if m: return round(float(m.group(1)) * 10000, 2) m = re.search(r"(\d+(?:\.\d+)?)\s*元", text) if m: return round(float(m.group(1)), 2) return None def clean_date(raw: str): m = re.search(r"(\d{4})[年\-/.](\d{1,2})[月\-/.](\d{1,2})", raw) if m: return f"{int(m.group(1)):04d}-{int(m.group(2)):02d}-{int(m.group(3)):02d}" return ""

逻辑说明：金额清洗的核心是先统一千分位格式，再用正则匹配“万元”或“元”前的数字并统一转成以元为单位的浮点数。日期清洗把中文和分隔符格式统一成 YYYY-MM-DD 字符串，方便数据库排序和后续时间范围过滤。

参数说明：clean_money 返回值统一为元，这样全库金额单位一致，做均值、汇总才不会出现数量级的错误。clean_date 里 int 后再格式化，是为了把“2023/7/6”这种不规范格式修正为“2023-07-06”，字符串对齐规则保证日期可以直接按字典序比较。

解析层的代码在一个真实项目里会被反复调整，因为采购站点的页面改版频率远超预期。我的经验是：不要追求一套解析代码跑通无数个站点，而是为每个站点维护一个独立的解析配置模块，包含容器选择器、日期格式、金额单位、翻页参数这些差异点，这样某个站点改版时只需改配置，不用动主流程。

4. 采购网爬虫的数据落库设计：SQLite 起步，字段主键与增量去重

数据落库环节最容易被低估。写一个爬虫脚本很简单，但让爬虫反复运行而不产生脏数据、不重复入库、不丢失异常记录，这才是采购网爬虫项目里真正拉开差距的地方。单机场景我用 SQLite，但要按生产级表的规范来建，不能拿它当临时缓存用。

4.1 建表与索引：一张公告主表，一张抓取日志表

字段设计直接影响后续查询能不能高效进行。公告标题用于展示，发布机构用于筛选，预算金额和中标金额用于分析，正文用于全文检索。为了让增量爬虫能判断一个公告是否已存在，还需要 url_hash 和 content_hash 两个技术字段。

CREATE TABLE notices ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, publish_time TEXT DEFAULT '', procurement_unit TEXT DEFAULT '', budget_amount REAL DEFAULT 0, winner_unit TEXT DEFAULT '', winner_amount REAL DEFAULT 0, content TEXT DEFAULT '', url TEXT NOT NULL, url_hash TEXT NOT NULL UNIQUE, content_hash TEXT DEFAULT '', created_at TEXT DEFAULT (datetime('now', 'localtime')), updated_at TEXT DEFAULT (datetime('now', 'localtime')) ); CREATE INDEX idx_notices_publish_time ON notices(publish_time); CREATE INDEX idx_notices_procurement_unit ON notices(procurement_unit);

逻辑说明：url_hash 设置为 UNIQUE 是去重的第一道屏障，同一个采购公告的 URL 通常包含公告 ID，具有唯一性。content_hash 用于应对 URL 变化但内容相同的情况，某些站点公告重新发布后会生成新的 URL，此时只能用内容哈希判断是否已入库。

参数说明：budget_amount 和 winner_amount 用 REAL 类型，单位统一为元，便于做 SUM、AVG 聚合；publish_time 和 procurement_unit 建索引是因为最常见的查询场景是按照发布时间段筛选、按采购人分组统计。created_at 和 updated_at 用本地时间字符串，记录首次入库时间和最近一次被爬虫注意到的时刻。

4.2 插入与去重：先查再插还是要靠 UNIQUE 约束

很多入门者会在代码里先 SELECT 判断再 INSERT，这个做法在单机 SQLite 下可行，但存在竞争条件和效率损耗。更稳妥的方案是直接执行 INSERT，捕获唯一约束冲突异常，冲突时再决定是更新还是跳过。

import sqlite3 import hashlib def save_notice(db_path: str, notice: dict): url_hash = hashlib.sha256(notice["url"].encode()).hexdigest() content_hash = hashlib.sha256(notice["content"].encode()).hexdigest() conn = sqlite3.connect(db_path) try: conn.execute( """ INSERT INTO notices (title, publish_time, procurement_unit, budget_amount, winner_unit, winner_amount, content, url, url_hash, content_hash) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?) """, ( notice["title"], notice["publish_time"], notice["procurement_unit"], notice["budget_amount"], notice["winner_unit"], notice["winner_amount"], notice["content"], notice["url"], url_hash, content_hash ) ) conn.commit() return "inserted" except sqlite3.IntegrityError: # url_hash 冲突：判断是否需要更新 old = conn.execute( "SELECT content_hash FROM notices WHERE url_hash = ?", (url_hash,) ).fetchone() if old and old[0] != content_hash: conn.execute( """ UPDATE notices SET content_hash = ?, updated_at = datetime('now', 'localtime') WHERE url_hash = ? """, (content_hash, url_hash) ) conn.commit() return "updated" return "skipped" finally: conn.close()

逻辑说明：先哈希 URL，再哈希正文内容。INSERT 时直接交给 UNIQUE 约束兜底，遇到 IntegrityError 时再去查旧记录的内容哈希，只有内容变化时才更新 updated_at，表示这个公告被重新抓取到且状态已更新。

参数说明：sha256 用于生成固定长度的哈希值，相比直接存 URL 原文，在 URL 很长时能显著节省索引空间。finally 里关闭连接是保证不泄漏文件句柄，SQLite 在高频写入下如果连接不释放，迟早触发 database is locked 错误。

4.3 断点续爬：记录游标而不是重新扫描全表

采购网爬虫一旦部署上线，跑个十天半个月是常态。中途崩溃、服务器重启、网络中断都可能导致爬虫停摆。如果没有断点续爬机制，重启后要重新爬全量数据，既浪费时间又增加被反爬限制的风险。我习惯在抓取日志表里维护一个状态字段。

CREATE TABLE crawl_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, batch_id TEXT NOT NULL, page_no INTEGER DEFAULT 0, status TEXT DEFAULT 'running', updated_at TEXT DEFAULT (datetime('now', 'localtime')) );

在爬虫启动时，先查这张表里是否存在 status 为 running 而 batch_id 未结束的记录。如果有，说明上次任务中断了，直接从上一次记录的 page_no 继续爬；如果没有，开启一个新批次。这个设计的核心价值在于把“从哪里继续”这个状态从内存挪到了磁盘上，崩溃丢全部内存数据也不怕。

批量插入时我还会对 SQLite 做一次手动事务控制，每满 50 条才 commit 一次，而不是每插入一条 commit。原因是 SQLite 的默认 autocommit 模式对磁盘同步的开销极大，高频写入时事务分组能让全流程提速数倍，同时降低 WAL 日志膨胀的概率。

5. 采购网爬虫的 5 个高频翻车点：现象、原因、解决方案

采购网爬虫做了几个项目之后，我总结出一些高频踩坑点，写下来给后来人省点血泪时间。每一条都是真实遇到过、定位到根因、再修改方案才解决的。

5.1 详情页正文抓回来是空的：iframe 嵌套与重定向

现象：列表页解析成功，详情页 HTTP 状态码也是 200，但正文解析结果为空字符串。原因：部分采购平台的公告正文放在独立子域名下的 iframe 中，详情页本体只是一个空壳框架。解决：进入详情页后先查找 iframe 标签，如果有 src 属性，把采集请求的目标 URL 替换为该 src 地址，再请求一次。还有少数情况是详情页通过 JS 跳转到另一个带 token 的地址，此时要在页面源码里搜索 location.href 或 location.replace。

def resolve_detail_url(session, detail_url): resp = fetch_page(session, detail_url) soup = BeautifulSoup(resp.text, "html.parser") iframe = soup.find("iframe") if iframe and iframe.get("src"): return iframe["src"] m = re.search(r"location\.(?:href|replace)\s*=\s*['\"](.*?)['\"]", resp.text) if m: return m.group(1).lstrip("/") return detail_url

逻辑说明：先正常请求详情页，再用两个条件分别判断 iframe 嵌套和 JS 重定向。一旦命中，就返回真正承载正文的 URL。这个解析函数要放在正文提取之前调用。

参数说明：lstrip("/") 的作用是处理以斜杠开头的相对重定向路径，某些站点会返回 “/redirectPage?url=xxx” 这类格式，直接拼接会产生双斜杠导致请求失败。

5.2 同一公告重复入库：URL 变化而内容不变

现象：运行增量爬虫一周后，数据库里出现大量标题相似、url_hash 完全不同的记录，但正文内容一致。原因：采购平台有定时刷新机制，公告重新推送后生成新的 URL 参数（常见的如 timestamp 或 random 后缀）。解决：依赖 url_hash 不可靠，必须在插入前额外做 content_hash 碰撞检查。在插入逻辑里增加一个分支，查出所有 content_hash 相同的旧记录，有匹配则跳过。

5.3 状态码 200 但内容是登录提示页

现象：爬虫运行到某个分页时，详情页返回内容是一段“请先登录”提示，解析所有字段全部为空。原因：平台的访问控制对某些路径和 IP 策略不一致，部分公告要求登录才能查看全文。解决：对登录类站点，用 Playwright 维护一个浏览器上下文，首次手动登录后把 cookie 导出到一个文件，爬虫请求时带上这些 cookie。注意 cookie 有有效期，过期后程序要能识别并重新登录，不能死磕同一套 cookie。

5.4 正文里混入了“相关公告”推荐列表

现象：正文提取出的文本末尾附带了大量不相关的公告标题和链接。原因：详情页底部有推荐位区块，容器选择和正文同属一个大 div。解决：在正文提取前先移除推荐区块节点，常见的 class 名有 relate、recommend、xg_list，把这些区块先 locate 再 decompose 掉。

5.5 频率控制踩线被判封 IP

现象：爬虫运行 20 分钟后突然所有请求返回 403。原因：请求间隔虽然是 3-8 秒随机，但同一时间段的爬取节奏仍然呈现规律性，和人类行为差异仍然明显。解决：在请求间隔之外，再引入每日总请求量上限和高峰期暂停机制。比如每天只抓取 300 个详情页，超过这个数字就等待到次日。另一个有效策略是把列表页和详情页的请求时间错开，不要先连续抓 10 个列表页再连续抓 50 个详情页，而是每抓一个列表页后随机放入详情页请求队列，在队列层面做随机调度。

6. 增量采集的落地技巧：从手动运行到无人值守的正确姿势

当爬虫跑通之后，你会面临一个更现实的问题：它需要持续运行，而不是跑一次就结束。采购公告每天都发布，第二天必须增量采集，否则前一天新增的数据就漏了。增量爬虫和全量爬虫在实现上有本质区别——不仅要负责抓取，还要负责判断哪些是新的，哪些已经入库了。

6.1 增量更新策略：以发布时间为阈值，而不是全量扫描

我用的是“双阈值增量法”。第一次全量爬完时记录当前最大发布时间 max_publish_time。之后每次运行，只抓取列表页发布的公告中发布时间晚于 max_publish_time 的条目，抓取到一条发布时间早于该阈值且不满足模糊匹配的记录后停止该分页的继续翻页。阈值在每次运行结束后更新。

def get_recent_notices(conn): row = conn.execute( "SELECT MAX(publish_time) FROM notices WHERE publish_time != ''" ).fetchone() return row[0] if row and row[0] else "2000-01-01"

逻辑说明：从公告主表读出最大发布时间作为增量阈值。日期统一为 YYYY-MM-DD 格式后，MAX() 函数天然按字典序取最大。这个阈值不需要额外存储，直接从数据里算出来即可，简单且永不丢失。

参数说明：取 MAX 而不是取 “当前日期减一天”，是为了应对项目断跑后再启动的场景。比如爬虫停了一个月，阈值停留在一个月前，重启后能自动补抓这一个月内发布的全部公告。如果直接用系统日期当天做阈值，漏掉的数据将永远补不回来。

6.2 内容校验与断更报警：用最少字段完整度做健康检查

无人值守带来的另一问题是：站点改版了，解析代码失效了，但任务照样运行，每天返回空数据，你还以为一切正常。我的习惯是在每批次爬取结束后统计“有效记录”和“字段完整度”，完整度低于设定线就触发告警。

def validate_batch(conn, batch_id): row = conn.execute( """ SELECT COUNT(*) AS total, SUM(CASE WHEN title != '' AND publish_time != '' THEN 1 ELSE 0 END) AS valid FROM notices WHERE batch_id = ? """, (batch_id,) ).fetchone() total = row[0] or 0 valid = row[1] or 0 if total > 0 and valid / total < 0.9: print(f"batch {batch_id} 完整度异常: {valid}/{total}")

逻辑说明：标题和发布时间同时非空才算有效记录。当有效比例低于 90% 时输出告警，这个阈值可以根据站点页面结构的稳定性自行调整，有的站点字段规范，可以提高到 98%，有的站点常常出现个别公告没有发布时间，就得放宽到 75%。完整的实现可以接企业微信机器人或者邮件通知，但核心是“自动发现异常”而不是“事后翻日志”。