从XPath解析到MongoDB落库：Python爬虫完整数据链路-北京尧图网络

简介面向Python初学者与Web数据采集实践者的技术文档围绕requests发送请求、lxml与正则提取网页信息、pymongo写入MongoDB这条完整链路展开解决抓取到的网页数据如何以文档型结构长期保存并便于检索的问题。资源为单个docx文档压缩包约608KB篇幅集中便于随身查阅与打印标注。文档先梳理MongoDB中文档、集合、数据库三层概念及键命名规范再以深圳市规划和自然资源局公示页面为例给出连接localhost:27017、建库建集合、插入公示标题与正文等字段的示例代码并涉及请求头定制、分页链接获取、进程池等常见环节。已有11258人学习下载适合希望把爬虫脚本从「抓下来」推进到「存得住、查得快」的读者对照练手也可作为课程实验与小型采集项目的参考资料。1. 结论先行爬虫真正的瓶颈不在下载而在数据落地的那一步写 Python 爬虫的人八成时间耗在两件事上请求发不发得出去XPath 取不取得到。等脚本能跑通、能打印出一屏结果很多人就收工了。可真正决定这套东西能不能长期用下去的恰恰是收工之后那一步——数据以什么形状落进库里。网页会改版栏目会迁移class 名会从xxym变成xxym-v2。改版那天你唯一还能救自己的东西是库里那份带着原始 URL、抓取时间和完整正文的快照。文档型存储的价值就在这里它允许你把「页面结构变了」这件事直接记录进数据本身而不用先停下来改表结构。这次要拆的这份资源做的就是「Python 抓取 → 解析 → 落进 MongoDB」这条完整链路下面沿着一次真实采集把每一层的机制掰开看。2. 抓取链路从一次 GET 到 XPath 命中中间隔着三层转换一个采集任务在代码里通常只有几十行但它实际跨了三层HTTP 协议层拿到字节流解析器把字节流变成 DOM 树XPath 在树上做路径匹配。任何一层判断错了后面全是白干。这三层里最容易出问题的不是 XPath 写错而是编码判断和链接补全这两件「看起来不用管」的事。2.1 请求头与编码apparent_encoding 到底在猜什么requests.get()返回的Response对象里同时存在两份数据res.content是原始字节res.text是解码后的字符串。解码用哪个字符集取决于res.encoding。它的取值顺序是这样的先看 HTTP 响应头Content-Type里的charset参数如果没有requests会退到 RFC 2616 给text/*定的历史默认值 ISO-8859-1。很多中文站点的响应头根本不带 charset于是你拿到的res.text就是一串乱码XPath 自然一个节点都匹配不上。res.apparent_encoding是另一条路它把原始字节丢给字符集探测库做统计推断看哪套编码能把字节序列解释成「最像人话」的字符分布。这对长文本准确率不错对短响应、纯英文页面、大量数字和符号的页面就容易猜偏比如把 GBK 内容猜成 windows-1252。所以工程上更稳的做法是显式指定源码注释里那句「也可以直接用 GB2312」就是这个意思。import requests from lxml import etree HEADERS { # 关键是别用 requests 的默认 UA很多站点会据此返回精简页或直接拦 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36 } def fetch(url: str) - requests.Response: # timeout 必须显式给否则对端不响应时进程会一直挂着 res requests.get(url, headersHEADERS, timeout10) # 先用探测结果兜底已知站点编码时直接写死更可靠 res.encoding res.apparent_encoding return restimeout10这一行经常被省掉。省掉的后果不是报错而是整个进程池卡死在一个不响应的连接上——requests默认没有超时TCP 层可能挂几分钟甚至更久进程池里的 4 个 worker 一个个被耗光主进程看起来「在跑」其实什么都没发生。2.2 XPath 定位lxml 把 HTML 变成了什么etree.HTML(res.text)做的事情比看上去多。真实网页的 HTML 大多不合法标签没闭合、属性没引号、p乱嵌套。libxml2 的 HTML 解析器带容错规则会补齐html、body把明显错位的标签按浏览器的习惯重新挂载最终产出一棵规整的元素树。这也是为什么//div[classxxym]这类路径在浏览器里能取到、在解析器里通常也能取到——两边用的是相近的容错策略。xpath()的返回值永远是列表哪怕只有一个匹配。text()取的是该节点下的直接文本节点返回的也是列表。所以源码里那串[0]不是装饰是在「断言结果非空」。页面结构一变列表长度变成 0IndexError就直接飞出来。还有一个细节值得单独说classxxym是精确匹配。如果页面上那个 div 的 class 变成xxym clearfix或者xxym active这个表达式立刻失效而用contains(class, xxym)就能容忍。精确匹配在结构稳定的政务公示页上能用但它把「页面只改了一点点」变成了「整条链路归零」。2.3 相对链接补全re.sub(^.) 这一行到底做了什么列表页里抓到的href大多是./201911/t20191114_489608.html这种相对路径。源码用一行正则把它补成绝对地址import re def absolutize(href: str, base: str http://example-gov.test/xxgk/gggs/) - str: # ^. 匹配字符串的第一个字符这里是 .整体替换成前缀 # ./201911/x.html - http://.../xxgk/gggs/201911/x.html return re.sub(^., base, str(href))这行的语义其实是「删掉首字符再接上前缀」。因为相对路径的第一个字符必定是.删掉它之后/201911/...正好和前缀拼成一个完整 URL。它在当前页面结构下是对的但它依赖了一个极强的隐含前提所有 href 都以.开头。标准的等价写法是urllib.parse.urljoin(base, href)它按 RFC 3986 的规则处理四种情况绝对 URL 保持原样、/开头的路径替换整个路径、../做路径回退、其余按相对路径拼接。下面这段就是在模拟真实场景下两者的差别from urllib.parse import urljoin base http://example-gov.test/xxgk/gggs/ cases [ ./201911/t20191114_489608.html, # 源码里遇到的那种 /xxgk/gggs/201912/t20191201_1.html, # 根路径相对 http://example-gov.test/a/b.html, # 已经是绝对地址 ../notice/2020/t1.html, # 上跳一级 ] for c in cases: print(c, -, urljoin(base, c))urljoin对第一种会给出和re.sub一样的结果对其余三种给出正确答案。而re.sub(^.)会把绝对 URL 的h换成前缀拼出一个根本不存在的地址这类错误不会抛异常它会安静地把一条垃圾链接塞进列表等到采集阶段才变成一个 404。这种「静默错误」是采集脚本里最难排查的一类。3. 进程池与节奏控制Pool.map 凭什么把采集吞吐拉起来单线程串行采集的瓶颈很清楚一次请求要等上百毫秒到几秒CPU 全程闲着。加速手段无非三条路——多线程、多进程、异步 IO。这份资源选了最直接的一条multiprocessing.Pool。选它有它的道理也有明显的代价。3.1 Pool.map 的分块与阻塞语义Pool(processes4)启动时会在后台创建 4 个工作进程主进程和它们之间通过管道通信。pool.map(func, iterable)不是「每个元素起一个进程」它先把iterable切成若干块chunksize 按len(iterable)与进程数的比例算元素多时一块里会有几十个任务再把块作为整体分派给空闲的 worker。from multiprocessing import Pool if __name__ __main__: links [http://example-gov.test/xxgk/gggs/201911/t1.html, http://example-gov.test/xxgk/gggs/201911/t2.html] pool Pool(processes4) # 常驻 4 个 worker try: # 阻塞等全部任务完成后才返回结果顺序与 links 一致 pool.map(page_scratch, links) finally: pool.close() # 不再接受新任务 pool.join() # 等 worker 退出回收资源这里有三个机制点值得记住。第一map是阻塞的主进程会一直等到所有块处理完如果你希望主进程继续干别的得用map_async加回调。第二参数和返回值都要经过序列化pickle穿过进程边界所以传给子进程的东西必须可序列化函数本身要能被 import 到。第三map会把子进程抛出的异常在主进程重新抛出一次IndexError就能让整批任务中断——这正是需要显式close/join的原因否则主进程退出时 worker 可能还挂着。源码里没有写close/join脚本能跑完是因为主进程结束后解释器会去清理。但在长驻服务或者被其他模块 import 的场景下缺这两行会留下僵尸进程和未关闭的管道。3.2 IO 密集型任务为什么选了进程而不是线程这是个值得停下来想的选择。抓取是典型的 IO 密集型任务等待网络的时间远大于计算时间从资源开销看线程池甚至异步协程都更合适线程共享内存创建成本低两个数量级协程更轻几万个并发都不成问题。选进程的代价是实打实的。每个子进程有独立的内存空间模块会被重新 import 一遍——包括模块顶层那些MongoClient的初始化代码于是每个 worker 都会建一套自己的数据库连接。进程创建本身也贵在 Windows 上用的是 spawn 而不是 fork新进程要重新加载解释器和模块启动开销比线程大一个数量级。那为什么还是选进程一是隔离性lxml解析畸形 HTML 时偶发的崩溃只影响单个 workerPool会补一个新的上来二是lxml的解析核心跑在 C 层对 GIL 的依赖比纯 Python 代码弱多进程能真正吃满多核三是实现成本Pool.map三行代码就能把一个串行for循环改成并发改造成本几乎为零。这是个典型的「先跑起来再优化」的取舍代价留在后面付。3.3 time.sleep(0.1) 的真实作用不是礼貌是错峰源码在page_scratch末尾放了一句time.sleep(0.1)。这句常被理解成「对站点礼貌一点」但它在进程池里的真实语义是错峰。如果这句 sleep 写在主进程的for循环里整个采集就变成串行的每个任务强制等 0.1 秒4 个 worker 全闲着。写进子进程的任务函数里效果完全不同——4 个 worker 各自在两次请求之间停 0.1 秒任意时刻仍有最多 4 个请求在飞理论上限约 40 QPS实际受响应时间限制会低很多。它的副作用也很明确每个进程的吞吐被 sleep 卡了上界。当目标站点响应很快比如 50ms时sleep 0.1 秒反而成了主要耗时4 进程跑出来的速度和单进程差不多。调这个值之前先测一次单请求的平均响应时间sleep 设成响应时间的 1 到 2 倍才既不打爆对方也不浪费自己的并发能力。4. 落库路径insert_one 背后一条公示是怎么变成 BSON 文档的数据抓下来只是原料能不能被查、被排、被复用取决于它落库时的形状。MongoDB 在这里的角色不是「一个能存 JSON 的地方」而是一套带类型系统的文档存储你塞进去的每个值都会被打上 BSON 类型标记这个标记决定了它以后能不能被范围查询、能不能走索引。4.1 文档、集合、数据库三层结构与惰性创建三层结构理解起来不难文档是基本单位多个文档组成集合多个集合组成数据库。有价值的是它和关系库的语义差异。关系库的「行」要求所有行共享同一套列定义加一列要改表结构MongoDB 的集合是无模式的同一个集合里的两个文档可以有完全不同的键。这不是「随便乱放」的许可证而是给你一个缓冲带目标站点今天多了一个「附件链接」字段直接往文档里加键就行历史文档保持原样查询时用{附件链接: {$exists: True}}就能把新的挑出来。另一条容易忽略的规则是惰性创建。client[webpages]和db[gov_publicity]拿到的只是客户端的句柄对象此时服务器上什么都没有。真正的建库建集合动作发生在第一次写入时。所以源码里list_database_names()那个检查在首次运行时会打印「不存在」但代码并没有走任何分支去创建——它只是打印然后继续往下跑靠insert_one顺带把库和集合建出来。import pymongo client pymongo.MongoClient(localhost, 27017) # 默认端口 27017 db client[webpages] # 句柄此时服务器上还没有这个库 col db[gov_publicity] # 句柄此时也还没有这个集合 print(before:, client.list_database_names()) # 第一次写入才会真正创建库和集合 col.insert_one({标题: 示例, 来源: 某市级政务公示平台}) print(after:, client.list_database_names()) # 这里才会看到 webpages理解这一点可以避免一类低级错误以为create_collection没调用就没建表于是在启动脚本里反复尝试建库结果因为并发建库互相冲突。4.2 insert_one 与 _id一条记录的身份是怎么来的文档必须有一个_id键它是主键集合里唯一。如果你不指定PyMongo 会在客户端生成一个ObjectId再发过去。这个 12 字节的值有明确的结构前 4 字节是秒级时间戳中间 5 字节是进程级随机值最后 3 字节是自增计数器。早期的驱动版本是「时间戳机器名哈希进程号计数器」改成随机值是为了避免多机部署时的碰撞。这个结构带来一个实用性质_id大致按插入时间递增因此按_id排序约等于按写入顺序排序而且_id上的索引天然是聚簇友好的。insert_one返回一个InsertOneResult对象inserted_id属性就是这条记录的身份日志里打出来出问题时能直接定位到具体文档。还要知道写入确认的边界默认写关注是w1意思是主节点写到内存后就返回成功此刻数据还没刷盘。进程被 kill -9 时最近一批写入可能丢。对采集这种可重跑的离线任务w1够用如果这份数据要作为唯一副本长期保存就得考虑日志确认的写关注。from datetime import datetime doc { 标题: 关于某地块规划调整的公示, 来源: 某市级政务公示平台, 日期: datetime(2019, 11, 14), # 存 datetime不存字符串公示内容: 正文……, 附件链接: http://example-gov.test/files/a.pdf, url: http://example-gov.test/xxgk/gggs/201911/t20191114_489608.html, 抓取时间: datetime.now(), } result col.insert_one(doc) print(result.inserted_id) # ObjectId(...)可用于后续定位4.3 索引与去重让「再跑一次」变成安全操作采集脚本几乎一定会被跑第二遍第一次跑挂了要补页面更新了要增量。如果每次都用insert_one第二遍跑完库里就多了一整套重复文档。更麻烦的是重复不是整齐的重复——两次抓取的正文可能因为页面更新而不同你很难靠人工判断该留哪条。正确的做法是把「唯一性」交给数据库而不是靠代码里的 if 判断# 用页面 URL 作为业务主键唯一索引是并发下的原子兜底 col.create_index([(url, 1)], uniqueTrue) col.update_one( {url: doc[url]}, # 查询条件这条 URL 是否已存在 {$set: doc}, # 存在则更新字段不存在则插入 upsertTrue )为什么不用「先find_one没有再insert_one」因为进程池里有 4 个 worker两个 worker 同时处理同一条链接分页重叠、列表页重复项都会导致这种重叠时两边都查不到、都插入重复照样产生。唯一索引把冲突判定下沉到存储引擎同一_id或同一唯一键的第二个写入会直接失败这是代码层加锁换不来的原子性。upsertTrue配合唯一索引还有一层细节并发 upsert 同一键时一方会撞上唯一索引报DuplicateKeyError。这在采集里不算故障捕获后重试一次即可——重试时记录已存在走的是 update 分支。至于日期字段存datetime还是存2019-11-14字符串差别在查询能力上。字符串在 ISO 格式下也能按字典序排但只要出现格式不一致有的带时分秒、有的不带排序和范围查询就会错乱datetime存的是 BSON 的 64 位毫秒时间戳{日期: {$gte: datetime(2019,1,1)}}这种查询能直接走索引。采集这种要长期积累、以后要按时间切片分析的数据类型一开始就该定对。5. 避坑与排查采集链路上最容易翻车的五处细节采集脚本的故障有个共同特征不报错或者报的错和真正的原因隔着好几层。下面五条是这条链路上最典型的翻车点每条都按「现象 → 原因 → 解决」拆。5.1 链接拼出来少一段现象采集阶段大量 404但把报错的 URL 复制到浏览器里手动改一改又能打开看起来「就差一个字符」。原因re.sub(^.)把 href 的首字符无条件替换成前缀。列表页里只要混进一个绝对 URL 或者/开头的根相对路径首字符就会被吃掉。比如/xxgk/gggs/201912/t1.html会变成http://.../xxgk/gggs/xxgk/gggs/201912/t1.html。解决换成urljoin并对结果做一次校验——只接受以目标站点域名开头的 URL不符合的记一条日志跳过。这个校验能拦住绝大多数拼接错误。5.2 某个字段偶尔取不到现象跑一百条九十条正常十条在某次[0]上抛IndexError或者「来源」字段时有时无。原因两类。一类是 XPath 结果为空还硬取下标xpath()返回空列表时[0]必然炸。另一类是正则依赖了文本里的换行符re.findall(来源(.*)\n, text)里的\n要求该文本节点确实带换行而 lxml 的text()在很多页面上返回的是不带换行的单行字符串匹配直接落空。解决所有xpath(...)[0]都改成先取列表再判空空值写None而不是抛异常——采集任务的价值在于「大部分成功」不该因为一条缺字段就整批中断。正则尽量不依赖\n、\t这类不可见字符改用re.search(r来源\s*(.), text)这种以行尾或非贪婪为边界的写法。5.3 正文只剩几句话现象标题、日期都对正文却只有开头一两段中间大段内容消失。原因//div[classTRS_Editor]/p/text()里的/p是直接子节点选择只取该 div 下第一层的p。真实正文经常有嵌套结构段落包在div里、表格里的文字、span包住的加粗片段这些都不在第一层全部被丢掉。解决用//取所有后代段落再对结果做清洗——\n.join(t.strip() for t in parts if t.strip())。如果正文里有表格单独用一条 XPath 把表格文本抽出来拼在后面。抽完做一次长度校验正文短于某个阈值就记一条警告人工抽查几条确认没漏。5.4 跑完一条都没入库日志只有一行 error现象终端上只打印了error不知道是哪条链接、哪个字段、什么异常。原因裸except:捕获了所有异常然后只打印一个固定字符串。它把异常类型、堆栈、出错的行号全部吞掉等于给自己造了个黑匣子。更麻烦的是Pool.map抛出的异常是在主进程重新抛的如果这段try/except包在pool.map外面子进程的堆栈信息根本传不出来。解决至少改成except Exception as e: print(repr(e))或者用traceback.print_exc()打出完整堆栈。更好的做法是在任务函数内部捕获异常把出错的 URL 和异常信息一起写进一个失败集合跑完统一重试。永远不要用裸except——它连KeyboardInterrupt都吃CtrlC 都停不下来。5.5 采集跑一会儿Mongo 连接数暴涨现象采集任务跑起来之后数据库端的连接数随着进程数成倍增长跑久了出现连接超限告警。原因MongoClient和集合句柄定义在模块顶层而multiprocessing在 Windows 上默认用 spawn 启动子进程子进程会重新 import 主模块于是模块顶层那段连接代码在每个 worker 里各执行一次。4 个 worker 就是 5 套连接池含主进程那套。如果进程池反复创建销毁泄漏会更明显。解决要么在任务函数内部按需建连接MongoClient本身是线程安全且带连接池的但每个进程一份是必要的要么在模块顶层加一个「是否已在子进程」的判断。同时给MongoClient显式设置maxPoolSize把单个进程的连接上界卡住别让默认值放任自流。6. 设计取舍XPath 的脆、文档模型的松与可复现的那道坎这套链路跑通之后最值得复盘的不是代码而是三个选择背后的代价。第一个是 XPath 与正则的取舍。XPath 表达能力强、可读性好但它和目标页面的 DOM 结构强绑定class 名一改就全盘失效正则对结构变化更宽容但它对文本格式敏感换行、空格、全半角都能让它失效。这条链路实际上两种都用了结构化的标题日期走 XPath嵌在长文本里的「来源」走正则。这个分工是对的——结构固定的东西用结构化的方式取结构不固定的东西用文本模式匹配。真正的坑在于没人给这两种方式加上「失败可见性」XPath 取空要能被统计到正则不匹配要能被记录否则失效了也没人知道。第二个是文档模型与关系模型的取舍。网页数据是半结构化的字段数量随栏目变化今天多一个「附件链接」明天多一个「联系人」。关系库要么开一堆可空列要么加成对的「字段名-字段值」表两种都别扭。文档模型让你把这些变化吸收进数据本身代价是约束变弱——拼错的键名、类型不一致的日期、重复的文档数据库都不会拦你。所以那份唯一索引和日期类型不是可选项是把「松」换回来的必要代价。第三个是多进程与限速的取舍这也是我最想强调的一点。进程池把吞吐拉起来了但它把「节奏」这件事从主进程推到了每个 worker 内部调参的判断依据从「我发了多少请求」变成「每个进程发了多少请求」后者乘上进程数才是对站点的真实压力。这个换算做错要么打爆对方要么白白浪费并发。下面这张表是我自己在采不同类型站点时的默认取值可以当起点场景进程数进程内 sleep关键理由静态公示列表几百条40.1s总量小温和即可分页上千条站点响应快4~80.2s提速靠进程限速靠 sleep 上界目标站点响应慢1s40sleep 无意义等待本身就是限速有频率检测的站点1~21s并行度越低越安全验证这套东西有没有做对有两个可复现的动作。一是空跑校验把insert_one换成打印跑完统计「链接总数 / 解析成功数 / 字段缺失数」三个数字对不上就说明解析层有问题。二是重跑校验把同一个任务连跑两遍对比集合的文档总数数字不变才说明幂等做对了。还有一个被低估的点源数据里写着「导出为 Word 文档」但落库的字段设计决定了这份 Word 能不能生成得干净。正文如果是用\n拼起来的纯文本导出 Word 时只能得到一堆无格式段落如果当初按段存成数组、保留小标题和附件链接的结构导出时就能映射成标题样式和超链接。数据结构在抓取那一刻就定型了后面再想补只能重抓。我踩过最疼的一次是给一个跑了三个月的采集任务改字段名。改完重跑新文档用的是新键老文档还是老键查询时得写两套条件导出脚本也跟着分叉。从那以后我每次新建采集任务都强制走一遍「先定 schema 再写解析」把要落的字段、类型、哪个字段做唯一键先写进一个配置文件代码从配置里读改字段就是改配置加一次迁移而不是满地找字符串。希望帮到你。本文还有配套的精品资源点击获取

从XPath解析到MongoDB落库：Python爬虫完整数据链路

相关推荐

ponytail插件实战：可插拔架构设计与避坑指南

Python爬虫抓取解析与MongoDB文档落库及Word导出

零售平台对比：五类渠道全成本、获客与现金流选型指南

更多资讯

DOM操作核心：appendChild方法详解与性能优化

如何处理遗留系统中的版本检查代码与技术债

水下图像增强：波长补偿与去雾协同算法详解

JavaScript appendChild方法详解与性能优化

n8n项目结构解析与高阶配置指南

如何系统化提升个人技能：从盘点、分类到执行的完整方法

今日更新

学生选课系统DFD图绘制指南：边界划分与分层校验实战

JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南

SEMI S8人机工程验收实战：从条款拆解到现场实测的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？