Python爬虫递归抓取技巧详解

深度爬取的核心挑战从来不是写递归函数本身，而是如何在多层遍历中严防死循环、内存爆炸与无效请求——必须用标准化的set去重（统一协议、去参、补斜杠）、硬性限制递归深度、结合内容校验替代单纯的状态码判断；Scrapy因内置去重、深度追踪和并发调度而更稳健，但需注意其Rule对JS动态链接的盲区；asyncio下务必弃用递归调用，改用队列驱动并限制积压规模；而urljoin()出错往往源于base URL未以/结尾或忽略协议相对链接，这些细节共同决定了爬虫能否真正稳定穿透多层结构。

递归爬取时如何避免无限循环

深度爬取最常崩在死循环里，不是代码写错了，而是没控制好 URL 去重和层级边界。requests.get() 拿到新链接后直接扔进递归，等于把整个网站当成了图的任意遍历——没有 visited 集合、没有 depth 限制，爬虫几分钟就卡死或触发反爬。

• 必须用 set 记录已访问的 url（注意标准化：去掉参数、统一协议和末尾斜杠）
• 递归函数必须带 depth 参数，且每次调用前检查是否超过预设阈值（比如 max_depth=3）
• 别只靠 response.status_code == 200 就继续递归——有些页面返回 200 但内容是“暂无数据”或跳转页，得结合 BeautifulSoup 或 lxml 判断实际是否有子链接

用 scrapy 实现深度抓取比手写递归更稳吗

稳，但不是因为“自动递归”，而是它把深度控制、去重、并发、中间件这些容易出错的环节都封装好了。你写 CrawlSpider 时定义 Rule，本质上是在声明“从哪类 URL 提取下一页”，而不是手动 call 自己。

• CrawlSpider 默认开启 RFPDupeFilter，URL 去重开箱即用；手写递归容易漏掉 fragment 或 query 参数导致重复请求
• 深度由 Request.meta['depth'] 控制，Scrapy 自动累加，你只需在 parse 中判断 response.meta.get('depth', 0) < 3
• 注意：Rule 的 follow=True 只对 a 标签有效，如果目标链接藏在 onclick 或 JS 里，它压根不会提取——这时候还是得切回 Selector 手动解析

asyncio + aiohttp 递归爬多层会爆内存吗

会，而且很隐蔽。问题不在并发数，而在递归调用栈 + 未 await 的 pending task 积压。每个 async def crawl(url, depth) 调用都会生成一个协程对象，如果 depth=5、每层平均 10 个链接，理论协程数就超 10⁵——Python 的 event loop 不会帮你 GC 掉还没执行完的协程。

• 改用队列驱动：用 asyncio.Queue 替代递归调用，生产者推入 (url, depth)，消费者 pop 后检查 depth 再发请求
• 限制队列长度（如 maxsize=1000），避免内存被未处理的 URL 占满
• 别在循环里直接 await crawl(next_url, depth+1) ——这仍是同步式递归，只是换了个语法糖

为什么用 urllib.parse.urljoin() 解析子链接总出错

因为 HTML 里的 href 是相对路径，而你传给 urljoin() 的 base URL 如果没带 trailing slash，结果就错位了。比如 base 是 https://example.com/blog，子链接是 page2，urljoin() 会拼成 https://example.com/page2（丢掉了 /blog/）。

• base URL 必须以 / 结尾：用 url.rstrip('/') + '/' 预处理
• 优先用 response.url（Requests 返回的响应对象自带解析后的绝对 URL）作 base，而不是原始请求 URL
• 遇到 href="//cdn.example.com/js.js" 这种协议相对链接，urljoin() 无法处理，得手动补 https:

今天关于《Python爬虫递归抓取技巧详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！