简介本资源是面向Python初学者与爬虫入门者的系统性学习套件聚焦Requests与BeautifulSoup两大核心库的实战应用解决从网页请求、HTML解析到数据提取与存储的一整套技术闭环问题。压缩包共208个文件含94个Python源码覆盖基础爬取、反爬应对、动态页面处理等、50个XML配置或测试用例、14个说明类TXT文档、13个PPTX教学幻灯片及Dockerfile、chromedriver、CSV结果样例等关键支撑文件整体87.17MB结构清晰模块化程度高。目前已有143人下载学习。读者可直接运行SourceCodeOfBook-master中全部项目代码结合附赠的.docx拓展资料与.txt部署指南掌握网站结构分析、请求模拟、数据清洗、异常处理及合规爬取要点内容预览显示含Scrapy配置模板、贴吧爬取CSV、Docker容器化部署支持兼顾进阶延伸能力培养。 拿到这套“Python爬虫开发从入门到实战”的配套源代码时大部分人的第一反应都是先跑起来看看效果。我的建议是先别急着运行花点时间把目录结构和代码组织方式捋清楚。这套代码包的价值不只是能跑通几个示例而是把Requests、BeautifulSoup、Scrapy这三座爬虫学习路上的大山按照合理的学习曲线串了起来。你既可以把它当成入门教程一步步跟练也可以把它当成实战手册遇到具体需求时直接翻到对应案例来参考。对于刚接触爬虫的初学者它是一份能让你少走很多弯路的导航图对于已经写过几个零散脚本、想进阶到工程化爬虫的开发者里面的Scrapy项目结构和反爬处理思路同样值得细看。我在整理和扩展这套代码的过程中把大量实战中踩过的坑也一并补充了进去所以下面这篇文章不仅讲源码本身还会把“为什么这么做”“遇到问题怎么排查”这些文档里不写的东西一起讲清楚。1. 拿到这份爬虫源码包先别急着跑先看清整体设计1.1 源码包里有什么基础教程与实战案例的两条主线这套源代码大体上可以分为两条主线。第一条是基础教程线围绕Requests、BeautifulSoup、Scrapy三个核心库展开每一章都配有可直接运行的示例代码。第二条是实战案例线把批量型爬虫、增量型爬虫、垂直型爬虫这些不同业务场景拆成了独立项目并且覆盖了从URL管理、请求发送、数据解析到存储落地的完整流程。从目录结构上看基础部分通常会按“请求-解析-框架”的顺序组织。Requests部分会教你如何发送GET/POST请求、处理请求头、管理SessionBeautifulSoup部分侧重于HTML解析、选择器使用、数据提取Scrapy部分则从项目创建开始讲Spider、Item、Pipeline、Middleware这些核心组件。实战部分则更像一个工具箱比如天气数据抓取、企业信息查询、新闻网站采集等案例每个案例都对应一类典型需求。我建议你把源码包当成一个“素材库”而不是“答案库”。看代码时多问问自己为什么这里要用Session而不是直接get为什么这个页面要用requests而不是Scrapy带着这些问题去读代码收获会大得多。1.2 学习顺序怎么排最合理很多人学爬虫容易犯一个错误一开始就上Scrapy结果被框架的各种概念绕晕。其实最合理的学习路径是先用Requests写单线程脚本理解HTTP请求的本质再用BeautifulSoup学解析理解HTML结构最后才能体会到Scrapy框架到底帮你解决了什么问题。我给出的顺序是“Requests入门 - BeautifulSoup解析 - Scrapy框架进阶”。先靠Requests写最原始的爬虫你能直观感受到“发送请求、拿到响应、解析数据、保存结果”这个过程。这个过程跑通之后再引入BeautifulSoup把解析从正则表达式的痛苦中解放出来。等这两步都熟练了你自然会遇到“脚本越写越乱、维护成本越来越高”的问题这时候再学Scrapy才会明白框架存在的意义。这套源码包里也是这么安排的。如果你顺着目录顺序学每个阶段的知识都有前面的铺垫不会出现“突然跳到高级话题”的割裂感。我自己带新人的时候也始终坚持这个顺序实践证明这是最不容易放弃的路线。1.3 爬虫开发的核心流程拆解不管爬虫项目简单还是复杂核心流程都离不开五步URL管理、请求发送、响应解析、数据清洗、存储落地。这个流程听起来简单但每一步都有不少细节。URL管理要考虑起始URL怎么定义、翻页怎么构造、去重怎么做。请求发送要考虑请求头、超时时间、重试机制、代理配置。响应解析则要根据页面类型选择方案静态页面用BeautifulSoup或XPath动态渲染页面可能还要引入Playwright。数据清洗是对提取结果做去空格、类型转换、去重合并这些处理。存储落地则是在文件、CSV、数据库之间做选择。源码包里的每个实战案例基本上都是围绕这条流程展开的。我见过不少初学者拿到代码后只盯着“解析”部分看觉得能提取到数据就算成功结果在请求稳定性和存储逻辑上频频翻车。所以建议你学习的时候把注意力平均分配到每个环节尤其是异常处理和请求重试这往往是实战中花费时间最多的部分。2. Requests、BeautifulSoup、Scrapy三个核心库的实战要点2.1 Requests不只是 get() 和 post()Requests是Python爬虫的敲门砖。源码包里的Requests示例通常会涉及发请求、带参数、设置Headers、处理JSON响应这些基础操作。但如果你只停留在requests.get(url)这种用法很快就发现很多网站根本爬不动原因多半是缺少请求头、没有处理Cookie、没有设置超时。我在实际开发中最常用的几个Requests配置如下import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }) retry Retry( total3, read3, connect3, backoff_factor0.5, status_forcelist(500, 502, 504), ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter) resp session.get(url, timeout(3, 10))这套配置解决的是两个问题Session保持Cookie和连接复用Retry机制处理临时性网络故障。其中timeout很关键如果不设置请求可能因为某个响应极慢的接口导致整个爬虫卡死。timeout(3, 10)表示连接超时3秒、读取超时10秒实战中这个配置比较稳妥。另外一个容易被忽略的点是verifyFalse和urllib3.disable_warnings()。有些网站HTTPS证书并不是标准证书requests默认会验证证书并抛出异常这时候你需要在请求时关闭验证。关闭验证会有一个InsecureRequestWarning警告可以通过以下方式压制import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) resp session.get(url, verifyFalse, timeout(3, 10))注意verifyFalse只建议在可控环境下使用不能作为默认习惯。2.2 BeautifulSoup解析慢页面时的高效姿势Requests负责把网页内容拿回来BeautifulSoup负责从HTML里提取你想要的数据。源码包里对BeautifulSoup的讲解通常会覆盖find()、find_all()、select()这几个方法以及get_text()、get(href)这些提取细节。这里我要专门强调两个容易踩坑的地方。第一个是解析器选择。BeautifulSoup支持html.parser、lxml、html5lib三种解析器。默认的html.parser虽然不需要额外安装依赖但解析大型页面时速度较慢。lxml解析速度快对畸形HTML容忍度高是实战中的首选。安装方式pip install lxml使用时明确指定解析器from bs4 import BeautifulSoup soup BeautifulSoup(html_content, lxml)第二个是通过select()配合CSS选择器来快速定位。find_all()需要写多级嵌套而select()可以直接一行搞定。比如想提取所有classnews-item的div里面的标题链接可以这样写items soup.select(div.news-item h2 a) for item in items: title item.get_text(stripTrue) href item.get(href)get_text(stripTrue)可以顺带去首尾空白避免拿到带换行符和多余空格的脏数据。这个细节在实际清洗数据时非常实用源码包里的案例基本也都是这么处理的。还有一个常见的解析问题网页内容乱码。通常是因为服务端返回的编码和requests库自动猜测的编码不一致。解决办法是直接从响应头里拿编码或者根据页面meta标签指定resp.encoding resp.apparent_encodingapparent_encoding是requests基于内容自动检测出的编码大部分页面都能处理但对一些特殊页面可能会有误判。更稳妥的做法是先解析HTML中的meta charset...再手动设置编码。比如import requests from bs4 import BeautifulSoup resp requests.get(url, timeout(3, 10)) soup BeautifulSoup(resp.text, lxml) meta soup.find(meta, charsetTrue) if meta and meta.get(charset): resp.encoding meta[charset]2.3 Scrapy框架化爬虫的工程思维从Requests脚本进阶到Scrapy本质上是从“能跑”走向“能维护、能扩展”的过程。源码包里的Scrapy部分通常包含一个完整的项目有items.py定义数据结构spiders/目录放爬虫逻辑pipelines.py做数据清洗和存储middlewares.py处理请求和响应。用Scrapy写爬虫你不再是“一个脚本从头写到尾”而是要把任务拆分成组件。比如在Spider中只负责解析页面并生成Item存储逻辑交给Pipeline请求头的动态修改交给Downloader Middleware这么做的好处是后续改了存储方式不用动解析代码改了代理逻辑不用动Spider。写一个最简单的Scrapy爬虫很容易import scrapy class NewsSpider(scrapy.Spider): name news start_urls [https://example.com/news] def parse(self, response): for item in response.css(div.news-item): yield { title: item.css(h2::text).get(), link: item.css(h2 a::attr(href)).get(), }但工程化爬虫远不止这些。你需要处理去重、限速、异常重试、日志分级、数据入库。Scrapy通过内置的AutoThrottle、RetryMiddleware、DupeFilter等组件帮你解决了大部分通用问题。我的建议是初学Scrapy时老老实实把官方教程里的核心概念过一遍再回头对照源码包里的项目结构逐行理解。不要一上来就想做分布式爬虫先把单机版跑稳再考虑扩展这样调试成本最低。3. 反爬与爬虫稳定性从被限制到稳定运行3.1 429 Too Many Requests的常见原因与对策请求频率过高时很多站点会返回HTTP 429状态码也就是“Too Many Requests”。这个错误在Requests爬虫中非常常见错误信息里经常带exceeded retry limit, last status: 429 too many requests。很多初学者第一次遇到这个错误会以为代码写错了其实这是服务器在明确告诉你访问太快了先歇一会儿。遇到429首先要做的是降低请求频率。最简单粗暴的方法是在两次请求之间加time.sleep()但更优雅的做法是使用随机延时import random import time time.sleep(random.uniform(1, 3))这样可以让请求间隔在一定范围内波动降低被识别为机器人的概率。其次要设置合理的重试退避策略。当你设置了Retry时要区分哪些状态码可以重试。像500、502、504这种服务器端错误可以立刻重试但429代表限流盲目重试只会让情况更糟。正确的策略是等待一段时间后再重试而且每次重试的等待时间要递增这叫指数退避。from tenacity import retry, stop_after_attempt, wait_random_exponential retry(stopstop_after_attempt(3), waitwait_random_exponential(min1, max10)) def fetch_url(url): resp session.get(url, timeout(3, 10)) resp.raise_for_status() return resp另外头部信息也是触发429的原因之一。如果你所有请求都用同一个User-Agent服务器很容易识别出这是脚本行为。建议准备一个User-Agent池每次请求随机换一个user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..., Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ..., Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) ..., ] session.headers.update({User-Agent: random.choice(user_agents)})我自己还遇到过一种情况代码本身没有问题但因为爬虫长时间不间断运行触发服务器限流到后来连续几次请求都返回429。这种时候最有效的办法是拉长请求间隔或者挂代理IP分散请求来源。对于个人学习项目拉长间隔就够了没必要一上来就上代理。3.2 Cookie、安全验证与登录态处理爬虫遇到需要登录才能访问的数据时Cookie是关键。Requests库中处理Cookie有两种常见方式手动从浏览器复制Cookie或者用Session自动保持Cookie。手动复制Cookie适合快速验证但不适合长期运行因为Cookie会过期。用Session模拟登录是更可持续的方案。模拟登录的原理是先GET登录页面解析出隐藏字段比如csrf_token再POST用户名密码后续请求都用同一个Session保持登录态。session requests.Session() login_url https://example.com/login resp session.get(login_url, timeout(3, 10)) token re.search(rnamecsrf_token value(.*?), resp.text).group(1) session.post(login_url, data{ username: my_account, password: my_password, csrf_token: token, })如果你用Requests直接登录失败可以先用浏览器登录然后从开发者工具里复制Cookie放到请求头中session.headers.update({ Cookie: xxxyyy; sessionidabc123 })这种操作只适合你自己有账号且站点允许的范围不要用它绕过任何访问控制。源码包里还有处理安全验证的案例。比如访问某些站点时正常浏览器打开没问题但脚本访问会返回安全验证页面。这类情况往往意味着站点已经检测到请求缺少浏览器特征。应对思路有两个一是把请求头补齐到和浏览器一致包括Accept、Accept-Language、Referer、Sec-Fetch-*等字段二是如果验证比较复杂可以直接用Playwright这类自动化工具来访问页面拿到渲染后的HTML再交给BeautifulSoup解析。3.3 动态页面与iframe的抓取策略很多初学者以为网页返回的HTML里就能看到所有数据但实际情况是现代网站大量使用Ajax动态渲染。你直接请求URL拿到的HTML可能只是个空壳真正数据是通过异步接口加载的。遇到这种情况第一推荐方案不是自动化浏览器而是去找接口。打开浏览器的开发者工具切到Network面板刷新页面看哪些XHR请求返回了JSON数据。直接请求这些接口往往比解析HTML更简单。api_url https://example.com/api/news?page1 resp session.get(api_url, headers{...}) data resp.json() for item in data[items]: print(item[title])接口方式拿到的数据是结构化JSON省去了解析HTML的麻烦。不过有些接口有签名校验参数里带各种加密的sign、token这时候你可能需要花精力去逆向JS逻辑。如果逆向成本太高再考虑自动化浏览器方案。自动化浏览器方面我带项目时最常用的是Playwright。相比SeleniumPlaywright支持自动等待、iframe处理更方便还能生成网络日志。在爬虫中引入Playwright通常步骤是启动浏览器、打开页面、等待目标元素出现、执行一些点击或滚动操作、最后取页面内容。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com, timeout30000) page.wait_for_selector(#app .content) html page.content() browser.close()iframe是另一个常见麻烦。有些页面里嵌入了iframe而iframe内部才是真正的数据源。用requests直接请求外层URL是拿不到iframe内容的因为iframe有自己的独立地址。解决办法是先解析出iframe的src属性再去请求这个真实地址。用Playwright时则可以直接切换到frameframe page.frame(namemain_frame) if frame: content frame.content()动态页面和iframe在Scrapy项目里也经常一起出现。用Scrapy Playwright中间件可以实现在Scrapy中直接渲染页面不过配置成本比单独用Playwright高一些适合已经有Scrapy基础之后再考虑。源码包里也有一部分关于动态抓取的示例建议先弄懂手动浏览器开发者工具里能看到什么再去看代码思路会清晰很多。4. 爬虫类型与业务场景你的项目属于哪一种4.1 批量型、增量型、垂直型爬虫的区别与适用场景源码包里把爬虫分成了批量型、增量型、垂直型三种这三个概念也是面试和实战中经常提到的分类方式。它们的区别主要体现在抓取策略、更新频率和目标范围上。类型核心特点适用场景技术要点批量型爬虫一次性抓取大量数据跑完即结束历史数据迁移、离线分析、数据集构建高并发、断点续爬、去重增量型爬虫按周期抓取新增或变化的数据新闻监控、价格监控、舆情系统URL指纹、更新时间判断、定时调度垂直型爬虫聚焦于特定领域或特定网站电商商品、招聘信息、行业资讯深度解析、强反爬应对、数据结构化批量型爬虫最容易理解比如你要把一个论坛近十年的帖子标题和链接全部抓下来一次任务跑完数据就不再变了。这类项目对并发要求较高因为数据量大如果串行请求会非常耗时。我一般用Scrapy的并发设置来控制抓取速度CONCURRENT_REQUESTS 16 DOWNLOAD_DELAY 0.5增量型爬虫的重点在于“怎么判断哪些数据是新的”。常见做法是给URL计算指纹MD5或SHA1存到去重表里每次抓新页面前先查一下指纹是否已经存在只抓那些没见过的URL。另外还可以借助网页最后修改时间或列表里的时间字段只解析最近更新的内容。源码包中相当于给出了一套“定时增量”的参考实现可以用cron或APScheduler来定时触发。垂直型爬虫更像是面向特定业务定制的爬虫比如只抓取某个行业网站的详细信息字段。这种项目往往需要针对站点的页面结构做深度的解析同时要处理更复杂的反爬逻辑。它的通用性差一些但数据价值高因为信息高度结构化。4.2 从单机到分布式Scrapy-Redis的扩展思路当单机爬虫爬取速度跟不上数据量增长时自然会想到分布式爬虫。Scrapy-Redis是让Scrapy支持分布式的常用方案。分布式爬虫的核心思想是把URL队列、去重集合、调度这些状态从单机内存抽出来放到一个统一的地方通常就是Redis。这样多台机器可以共享同一个待爬队列各自取任务来爬。Scrapy-Redis的核心配置大致如下SCHEDULER scrapy_redis.scheduler.Scheduler DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter REDIS_HOST localhost REDIS_PORT 6379配置完成后Spider应该继承RedisSpider而不是普通的Spider并且不再定义start_urls而是从Redis里读取起始URL。from scrapy_redis.spiders import RedisSpider class MyRedisSpider(RedisSpider): name myspider_redis redis_key myspider:start_urls启动后向Redis队列推送初始URLredis-cli lpush myspider:start_urls https://example.com/start不过要给个提醒分布式爬虫的收益在个人学习或小规模数据抓取中并不明显反而会引入Redis运维、网络通信、任务分配等新问题。我见过不少团队在最开始就把项目搞成分布式结果大部分时间花在排查Redis连接问题上抓取速度并没有提升多少。正确的做法是先评估目标网站的规模如果几千个页面就能跑完单机完全够用如果百万级页面且目标网站支持高并发访问再考虑分布式。4.3 实战案例拆解天气预报爬虫与信息查询类爬虫源码包里最典型的实战案例要数天气预报爬虫。这个案例非常适合入门因为接口清晰、数据量少、结构简单但又能完整覆盖爬虫开发流程。如果用Requests和BeautifulSoup实现核心逻辑大致是import requests from bs4 import BeautifulSoup url https://example-weather.com/city/101010100 resp requests.get(url, timeout(3, 10)) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, lxml) temperature soup.select_one(.temp).get_text(stripTrue) weather_desc soup.select_one(.weather-desc).get_text(stripTrue) print(temperature, weather_desc)实际项目里天气类数据大多有现成API直接以JSON格式返回连解析HTML都省了。但作为学习案例用网页版来讲解HTML解析、CSS选择器、编码处理依然是很好的素材。你可以把这个思路迁移到任意信息类站点上。信息查询类爬虫也比较常见比如查游戏战绩、查快递、查企业信息。这类爬虫通常需要输入一个关键词然后从查询结果页面提取多条记录。涉及用户输入的场景要注意参数编码一般用params参数即可params {keyword: 某个查询词} resp session.get(https://example.com/search, paramsparams, timeout(3, 10))查询类爬虫常见的问题是“返回结果和浏览器不一致”原因通常是翻页参数、排序参数或者用户登录态不同。我遇到这种情况会先把浏览器请求的完整URL、请求头和Cookie逐项对比找到差异后逐项调整。这里要特别提一句合规问题。无论是天气、战绩还是企业信息抓取数据前都应该确认目标网站是否允许爬虫访问尊重对方的使用条款、robots协议和版权约定。用于学习的小规模抓取一般问题不大但如果要商用或大规模抓取务必先获得授权。这也是源码包在部分案例后面特意补充合规提醒的原因。5. 高频报错与排错技巧我在实战中踩过的坑5.1 高频报错速查表爬虫开发中报错是常态关键是快速定位。我整理了实战中最常遇到的几类报错和对应的排查方向报错/问题常见原因解决思路429 Too Many Requests请求频率过高触发限流降低频率、随机延时、轮换User-Agent、指数退避重试Connection timed out网络问题或目标站响应慢设置合理的超时时间增加重试必要时换代理SSL: CERTIFICATE_VERIFY_FAILEDHTTPS证书异常verifyFalse并压制警告但不建议长期依赖UnicodeDecodeError或乱码编码解析错误设置resp.encoding优先使用apparent_encoding或页面meta编码KeyError/IndexError选择器未匹配到目标元素先打印页面片段确认元素确实存在检查是否被反爬跳转安全验证/验证码页面请求特征被识别补齐请求头、模拟浏览器行为必要时用PlaywrightImportError: No module named lxml缺少解析器依赖pip install lxmlRedis连接失败Scrapy-Redis部署时Redis未启动或配置错误检查Redis服务状态、端口、密码配置这里要特别提一下“选择器未匹配到元素”的问题。很多初学者定位不到数据第一反应是选择器写错了但实际往往是页面内容并没有加载出来。比如有些站点对外来请求直接返回了验证页面导致你的BeautifulSoup在解析验证页里自然找不到目标元素。这时候先打印resp.text的前500个字符看看拿到的是不是你以为的页面这个习惯能帮你省下大量排查时间。5.2 开发调试的实用技巧我平时调试爬虫会遵循几个固定习惯。第一是开启日志或加入足够的print但不要每一条解析都打印那会刷屏。比较好的做法是打印关键步骤比如当前URL、状态码、提取了几条数据print(f[DEBUG] {url} - status: {resp.status_code}, items: {len(items)})对于Requests脚本可以用logging模块替代print方便控制日志级别和输出文件。第二是善用浏览器的开发者工具。很多爬虫问题不是代码问题而是对页面理解不够。看一个页面时我通常先看Network面板里有没有XHR接口直接返回数据再看Element面板确认目标数据到底在哪个标签下有没有嵌套在iframe里。肉眼确认后再去写选择器成功率会高很多。第三是学会缩小问题范围。当爬虫出错时确定问题出在“请求”还是“解析”。最简单的验证方法是先用curl或浏览器访问目标URL确认数据是否存在、是否返回正常状态码。如果请求没问题问题就在解析如果请求都有问题那就要检查请求头、Cookie、代理这些外层因素。这个二分排查法对新手特别管用。第四是控制并发和频率。调试阶段永远用单线程、低并发跑通后再逐步加并发。直接在Scrapy里调高CONCURRENT_REQUESTS很容易触发反爬一旦被封IP反而更难调试。我通常的做法是保持CONCURRENT_REQUESTS4确认稳定后再逐步提升同时用DOWNLOAD_DELAY兜底。5.3 爬虫开发中的合规与边界意识这一节虽然不是技术代码但我觉得比代码更重要。爬虫本身是中性工具但使用不当会带来法律和道德风险。学习过程中尽量选择公开接口、官方文档允许的开放数据或者目标网站明确提供API的数据源。不要对需要登录才能访问的私有数据、个人隐私数据强行抓取也不要在大流量网站上做高频率压力测试。我在实际项目里给自己定的几条原则是遵守robots协议控制请求频率不干扰目标网站的正常服务抓到的数据只用于个人学习或已获授权的业务涉及用户信息的数据脱敏处理。这些原则也应该贯穿在源码包的学习过程中。爬虫技术真正的价值不是教会你如何绕过所有限制去抓数据而是让你理解网络数据的组织方式、HTTP协议的交互逻辑以及大规模数据处理的工程方法。把这些底层能力练扎实比多会几个骚操作重要得多。最后分享一个我自己的习惯每写完一个爬虫我都会花几分钟整理请求头、频率配置、解析器选择这些“初始参数”。下次遇到类似站点时直接套用这套初始化配置能省掉大量重复试错时间。这套源码包里的基础教程部分其实也承担了同样的角色——它把爬虫开发中最常用、最稳定的方案沉淀下来等你真正需要上手新项目时就有据可依了。本文还有配套的精品资源点击获取
Python爬虫开发实战：从Requests到Scrapy的进阶指南
简介本资源是面向Python初学者与爬虫入门者的系统性学习套件聚焦Requests与BeautifulSoup两大核心库的实战应用解决从网页请求、HTML解析到数据提取与存储的一整套技术闭环问题。压缩包共208个文件含94个Python源码覆盖基础爬取、反爬应对、动态页面处理等、50个XML配置或测试用例、14个说明类TXT文档、13个PPTX教学幻灯片及Dockerfile、chromedriver、CSV结果样例等关键支撑文件整体87.17MB结构清晰模块化程度高。目前已有143人下载学习。读者可直接运行SourceCodeOfBook-master中全部项目代码结合附赠的.docx拓展资料与.txt部署指南掌握网站结构分析、请求模拟、数据清洗、异常处理及合规爬取要点内容预览显示含Scrapy配置模板、贴吧爬取CSV、Docker容器化部署支持兼顾进阶延伸能力培养。 拿到这套“Python爬虫开发从入门到实战”的配套源代码时大部分人的第一反应都是先跑起来看看效果。我的建议是先别急着运行花点时间把目录结构和代码组织方式捋清楚。这套代码包的价值不只是能跑通几个示例而是把Requests、BeautifulSoup、Scrapy这三座爬虫学习路上的大山按照合理的学习曲线串了起来。你既可以把它当成入门教程一步步跟练也可以把它当成实战手册遇到具体需求时直接翻到对应案例来参考。对于刚接触爬虫的初学者它是一份能让你少走很多弯路的导航图对于已经写过几个零散脚本、想进阶到工程化爬虫的开发者里面的Scrapy项目结构和反爬处理思路同样值得细看。我在整理和扩展这套代码的过程中把大量实战中踩过的坑也一并补充了进去所以下面这篇文章不仅讲源码本身还会把“为什么这么做”“遇到问题怎么排查”这些文档里不写的东西一起讲清楚。1. 拿到这份爬虫源码包先别急着跑先看清整体设计1.1 源码包里有什么基础教程与实战案例的两条主线这套源代码大体上可以分为两条主线。第一条是基础教程线围绕Requests、BeautifulSoup、Scrapy三个核心库展开每一章都配有可直接运行的示例代码。第二条是实战案例线把批量型爬虫、增量型爬虫、垂直型爬虫这些不同业务场景拆成了独立项目并且覆盖了从URL管理、请求发送、数据解析到存储落地的完整流程。从目录结构上看基础部分通常会按“请求-解析-框架”的顺序组织。Requests部分会教你如何发送GET/POST请求、处理请求头、管理SessionBeautifulSoup部分侧重于HTML解析、选择器使用、数据提取Scrapy部分则从项目创建开始讲Spider、Item、Pipeline、Middleware这些核心组件。实战部分则更像一个工具箱比如天气数据抓取、企业信息查询、新闻网站采集等案例每个案例都对应一类典型需求。我建议你把源码包当成一个“素材库”而不是“答案库”。看代码时多问问自己为什么这里要用Session而不是直接get为什么这个页面要用requests而不是Scrapy带着这些问题去读代码收获会大得多。1.2 学习顺序怎么排最合理很多人学爬虫容易犯一个错误一开始就上Scrapy结果被框架的各种概念绕晕。其实最合理的学习路径是先用Requests写单线程脚本理解HTTP请求的本质再用BeautifulSoup学解析理解HTML结构最后才能体会到Scrapy框架到底帮你解决了什么问题。我给出的顺序是“Requests入门 - BeautifulSoup解析 - Scrapy框架进阶”。先靠Requests写最原始的爬虫你能直观感受到“发送请求、拿到响应、解析数据、保存结果”这个过程。这个过程跑通之后再引入BeautifulSoup把解析从正则表达式的痛苦中解放出来。等这两步都熟练了你自然会遇到“脚本越写越乱、维护成本越来越高”的问题这时候再学Scrapy才会明白框架存在的意义。这套源码包里也是这么安排的。如果你顺着目录顺序学每个阶段的知识都有前面的铺垫不会出现“突然跳到高级话题”的割裂感。我自己带新人的时候也始终坚持这个顺序实践证明这是最不容易放弃的路线。1.3 爬虫开发的核心流程拆解不管爬虫项目简单还是复杂核心流程都离不开五步URL管理、请求发送、响应解析、数据清洗、存储落地。这个流程听起来简单但每一步都有不少细节。URL管理要考虑起始URL怎么定义、翻页怎么构造、去重怎么做。请求发送要考虑请求头、超时时间、重试机制、代理配置。响应解析则要根据页面类型选择方案静态页面用BeautifulSoup或XPath动态渲染页面可能还要引入Playwright。数据清洗是对提取结果做去空格、类型转换、去重合并这些处理。存储落地则是在文件、CSV、数据库之间做选择。源码包里的每个实战案例基本上都是围绕这条流程展开的。我见过不少初学者拿到代码后只盯着“解析”部分看觉得能提取到数据就算成功结果在请求稳定性和存储逻辑上频频翻车。所以建议你学习的时候把注意力平均分配到每个环节尤其是异常处理和请求重试这往往是实战中花费时间最多的部分。2. Requests、BeautifulSoup、Scrapy三个核心库的实战要点2.1 Requests不只是 get() 和 post()Requests是Python爬虫的敲门砖。源码包里的Requests示例通常会涉及发请求、带参数、设置Headers、处理JSON响应这些基础操作。但如果你只停留在requests.get(url)这种用法很快就发现很多网站根本爬不动原因多半是缺少请求头、没有处理Cookie、没有设置超时。我在实际开发中最常用的几个Requests配置如下import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, }) retry Retry( total3, read3, connect3, backoff_factor0.5, status_forcelist(500, 502, 504), ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter) resp session.get(url, timeout(3, 10))这套配置解决的是两个问题Session保持Cookie和连接复用Retry机制处理临时性网络故障。其中timeout很关键如果不设置请求可能因为某个响应极慢的接口导致整个爬虫卡死。timeout(3, 10)表示连接超时3秒、读取超时10秒实战中这个配置比较稳妥。另外一个容易被忽略的点是verifyFalse和urllib3.disable_warnings()。有些网站HTTPS证书并不是标准证书requests默认会验证证书并抛出异常这时候你需要在请求时关闭验证。关闭验证会有一个InsecureRequestWarning警告可以通过以下方式压制import urllib3 urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning) resp session.get(url, verifyFalse, timeout(3, 10))注意verifyFalse只建议在可控环境下使用不能作为默认习惯。2.2 BeautifulSoup解析慢页面时的高效姿势Requests负责把网页内容拿回来BeautifulSoup负责从HTML里提取你想要的数据。源码包里对BeautifulSoup的讲解通常会覆盖find()、find_all()、select()这几个方法以及get_text()、get(href)这些提取细节。这里我要专门强调两个容易踩坑的地方。第一个是解析器选择。BeautifulSoup支持html.parser、lxml、html5lib三种解析器。默认的html.parser虽然不需要额外安装依赖但解析大型页面时速度较慢。lxml解析速度快对畸形HTML容忍度高是实战中的首选。安装方式pip install lxml使用时明确指定解析器from bs4 import BeautifulSoup soup BeautifulSoup(html_content, lxml)第二个是通过select()配合CSS选择器来快速定位。find_all()需要写多级嵌套而select()可以直接一行搞定。比如想提取所有classnews-item的div里面的标题链接可以这样写items soup.select(div.news-item h2 a) for item in items: title item.get_text(stripTrue) href item.get(href)get_text(stripTrue)可以顺带去首尾空白避免拿到带换行符和多余空格的脏数据。这个细节在实际清洗数据时非常实用源码包里的案例基本也都是这么处理的。还有一个常见的解析问题网页内容乱码。通常是因为服务端返回的编码和requests库自动猜测的编码不一致。解决办法是直接从响应头里拿编码或者根据页面meta标签指定resp.encoding resp.apparent_encodingapparent_encoding是requests基于内容自动检测出的编码大部分页面都能处理但对一些特殊页面可能会有误判。更稳妥的做法是先解析HTML中的meta charset...再手动设置编码。比如import requests from bs4 import BeautifulSoup resp requests.get(url, timeout(3, 10)) soup BeautifulSoup(resp.text, lxml) meta soup.find(meta, charsetTrue) if meta and meta.get(charset): resp.encoding meta[charset]2.3 Scrapy框架化爬虫的工程思维从Requests脚本进阶到Scrapy本质上是从“能跑”走向“能维护、能扩展”的过程。源码包里的Scrapy部分通常包含一个完整的项目有items.py定义数据结构spiders/目录放爬虫逻辑pipelines.py做数据清洗和存储middlewares.py处理请求和响应。用Scrapy写爬虫你不再是“一个脚本从头写到尾”而是要把任务拆分成组件。比如在Spider中只负责解析页面并生成Item存储逻辑交给Pipeline请求头的动态修改交给Downloader Middleware这么做的好处是后续改了存储方式不用动解析代码改了代理逻辑不用动Spider。写一个最简单的Scrapy爬虫很容易import scrapy class NewsSpider(scrapy.Spider): name news start_urls [https://example.com/news] def parse(self, response): for item in response.css(div.news-item): yield { title: item.css(h2::text).get(), link: item.css(h2 a::attr(href)).get(), }但工程化爬虫远不止这些。你需要处理去重、限速、异常重试、日志分级、数据入库。Scrapy通过内置的AutoThrottle、RetryMiddleware、DupeFilter等组件帮你解决了大部分通用问题。我的建议是初学Scrapy时老老实实把官方教程里的核心概念过一遍再回头对照源码包里的项目结构逐行理解。不要一上来就想做分布式爬虫先把单机版跑稳再考虑扩展这样调试成本最低。3. 反爬与爬虫稳定性从被限制到稳定运行3.1 429 Too Many Requests的常见原因与对策请求频率过高时很多站点会返回HTTP 429状态码也就是“Too Many Requests”。这个错误在Requests爬虫中非常常见错误信息里经常带exceeded retry limit, last status: 429 too many requests。很多初学者第一次遇到这个错误会以为代码写错了其实这是服务器在明确告诉你访问太快了先歇一会儿。遇到429首先要做的是降低请求频率。最简单粗暴的方法是在两次请求之间加time.sleep()但更优雅的做法是使用随机延时import random import time time.sleep(random.uniform(1, 3))这样可以让请求间隔在一定范围内波动降低被识别为机器人的概率。其次要设置合理的重试退避策略。当你设置了Retry时要区分哪些状态码可以重试。像500、502、504这种服务器端错误可以立刻重试但429代表限流盲目重试只会让情况更糟。正确的策略是等待一段时间后再重试而且每次重试的等待时间要递增这叫指数退避。from tenacity import retry, stop_after_attempt, wait_random_exponential retry(stopstop_after_attempt(3), waitwait_random_exponential(min1, max10)) def fetch_url(url): resp session.get(url, timeout(3, 10)) resp.raise_for_status() return resp另外头部信息也是触发429的原因之一。如果你所有请求都用同一个User-Agent服务器很容易识别出这是脚本行为。建议准备一个User-Agent池每次请求随机换一个user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..., Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ..., Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) ..., ] session.headers.update({User-Agent: random.choice(user_agents)})我自己还遇到过一种情况代码本身没有问题但因为爬虫长时间不间断运行触发服务器限流到后来连续几次请求都返回429。这种时候最有效的办法是拉长请求间隔或者挂代理IP分散请求来源。对于个人学习项目拉长间隔就够了没必要一上来就上代理。3.2 Cookie、安全验证与登录态处理爬虫遇到需要登录才能访问的数据时Cookie是关键。Requests库中处理Cookie有两种常见方式手动从浏览器复制Cookie或者用Session自动保持Cookie。手动复制Cookie适合快速验证但不适合长期运行因为Cookie会过期。用Session模拟登录是更可持续的方案。模拟登录的原理是先GET登录页面解析出隐藏字段比如csrf_token再POST用户名密码后续请求都用同一个Session保持登录态。session requests.Session() login_url https://example.com/login resp session.get(login_url, timeout(3, 10)) token re.search(rnamecsrf_token value(.*?), resp.text).group(1) session.post(login_url, data{ username: my_account, password: my_password, csrf_token: token, })如果你用Requests直接登录失败可以先用浏览器登录然后从开发者工具里复制Cookie放到请求头中session.headers.update({ Cookie: xxxyyy; sessionidabc123 })这种操作只适合你自己有账号且站点允许的范围不要用它绕过任何访问控制。源码包里还有处理安全验证的案例。比如访问某些站点时正常浏览器打开没问题但脚本访问会返回安全验证页面。这类情况往往意味着站点已经检测到请求缺少浏览器特征。应对思路有两个一是把请求头补齐到和浏览器一致包括Accept、Accept-Language、Referer、Sec-Fetch-*等字段二是如果验证比较复杂可以直接用Playwright这类自动化工具来访问页面拿到渲染后的HTML再交给BeautifulSoup解析。3.3 动态页面与iframe的抓取策略很多初学者以为网页返回的HTML里就能看到所有数据但实际情况是现代网站大量使用Ajax动态渲染。你直接请求URL拿到的HTML可能只是个空壳真正数据是通过异步接口加载的。遇到这种情况第一推荐方案不是自动化浏览器而是去找接口。打开浏览器的开发者工具切到Network面板刷新页面看哪些XHR请求返回了JSON数据。直接请求这些接口往往比解析HTML更简单。api_url https://example.com/api/news?page1 resp session.get(api_url, headers{...}) data resp.json() for item in data[items]: print(item[title])接口方式拿到的数据是结构化JSON省去了解析HTML的麻烦。不过有些接口有签名校验参数里带各种加密的sign、token这时候你可能需要花精力去逆向JS逻辑。如果逆向成本太高再考虑自动化浏览器方案。自动化浏览器方面我带项目时最常用的是Playwright。相比SeleniumPlaywright支持自动等待、iframe处理更方便还能生成网络日志。在爬虫中引入Playwright通常步骤是启动浏览器、打开页面、等待目标元素出现、执行一些点击或滚动操作、最后取页面内容。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com, timeout30000) page.wait_for_selector(#app .content) html page.content() browser.close()iframe是另一个常见麻烦。有些页面里嵌入了iframe而iframe内部才是真正的数据源。用requests直接请求外层URL是拿不到iframe内容的因为iframe有自己的独立地址。解决办法是先解析出iframe的src属性再去请求这个真实地址。用Playwright时则可以直接切换到frameframe page.frame(namemain_frame) if frame: content frame.content()动态页面和iframe在Scrapy项目里也经常一起出现。用Scrapy Playwright中间件可以实现在Scrapy中直接渲染页面不过配置成本比单独用Playwright高一些适合已经有Scrapy基础之后再考虑。源码包里也有一部分关于动态抓取的示例建议先弄懂手动浏览器开发者工具里能看到什么再去看代码思路会清晰很多。4. 爬虫类型与业务场景你的项目属于哪一种4.1 批量型、增量型、垂直型爬虫的区别与适用场景源码包里把爬虫分成了批量型、增量型、垂直型三种这三个概念也是面试和实战中经常提到的分类方式。它们的区别主要体现在抓取策略、更新频率和目标范围上。类型核心特点适用场景技术要点批量型爬虫一次性抓取大量数据跑完即结束历史数据迁移、离线分析、数据集构建高并发、断点续爬、去重增量型爬虫按周期抓取新增或变化的数据新闻监控、价格监控、舆情系统URL指纹、更新时间判断、定时调度垂直型爬虫聚焦于特定领域或特定网站电商商品、招聘信息、行业资讯深度解析、强反爬应对、数据结构化批量型爬虫最容易理解比如你要把一个论坛近十年的帖子标题和链接全部抓下来一次任务跑完数据就不再变了。这类项目对并发要求较高因为数据量大如果串行请求会非常耗时。我一般用Scrapy的并发设置来控制抓取速度CONCURRENT_REQUESTS 16 DOWNLOAD_DELAY 0.5增量型爬虫的重点在于“怎么判断哪些数据是新的”。常见做法是给URL计算指纹MD5或SHA1存到去重表里每次抓新页面前先查一下指纹是否已经存在只抓那些没见过的URL。另外还可以借助网页最后修改时间或列表里的时间字段只解析最近更新的内容。源码包中相当于给出了一套“定时增量”的参考实现可以用cron或APScheduler来定时触发。垂直型爬虫更像是面向特定业务定制的爬虫比如只抓取某个行业网站的详细信息字段。这种项目往往需要针对站点的页面结构做深度的解析同时要处理更复杂的反爬逻辑。它的通用性差一些但数据价值高因为信息高度结构化。4.2 从单机到分布式Scrapy-Redis的扩展思路当单机爬虫爬取速度跟不上数据量增长时自然会想到分布式爬虫。Scrapy-Redis是让Scrapy支持分布式的常用方案。分布式爬虫的核心思想是把URL队列、去重集合、调度这些状态从单机内存抽出来放到一个统一的地方通常就是Redis。这样多台机器可以共享同一个待爬队列各自取任务来爬。Scrapy-Redis的核心配置大致如下SCHEDULER scrapy_redis.scheduler.Scheduler DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter REDIS_HOST localhost REDIS_PORT 6379配置完成后Spider应该继承RedisSpider而不是普通的Spider并且不再定义start_urls而是从Redis里读取起始URL。from scrapy_redis.spiders import RedisSpider class MyRedisSpider(RedisSpider): name myspider_redis redis_key myspider:start_urls启动后向Redis队列推送初始URLredis-cli lpush myspider:start_urls https://example.com/start不过要给个提醒分布式爬虫的收益在个人学习或小规模数据抓取中并不明显反而会引入Redis运维、网络通信、任务分配等新问题。我见过不少团队在最开始就把项目搞成分布式结果大部分时间花在排查Redis连接问题上抓取速度并没有提升多少。正确的做法是先评估目标网站的规模如果几千个页面就能跑完单机完全够用如果百万级页面且目标网站支持高并发访问再考虑分布式。4.3 实战案例拆解天气预报爬虫与信息查询类爬虫源码包里最典型的实战案例要数天气预报爬虫。这个案例非常适合入门因为接口清晰、数据量少、结构简单但又能完整覆盖爬虫开发流程。如果用Requests和BeautifulSoup实现核心逻辑大致是import requests from bs4 import BeautifulSoup url https://example-weather.com/city/101010100 resp requests.get(url, timeout(3, 10)) resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, lxml) temperature soup.select_one(.temp).get_text(stripTrue) weather_desc soup.select_one(.weather-desc).get_text(stripTrue) print(temperature, weather_desc)实际项目里天气类数据大多有现成API直接以JSON格式返回连解析HTML都省了。但作为学习案例用网页版来讲解HTML解析、CSS选择器、编码处理依然是很好的素材。你可以把这个思路迁移到任意信息类站点上。信息查询类爬虫也比较常见比如查游戏战绩、查快递、查企业信息。这类爬虫通常需要输入一个关键词然后从查询结果页面提取多条记录。涉及用户输入的场景要注意参数编码一般用params参数即可params {keyword: 某个查询词} resp session.get(https://example.com/search, paramsparams, timeout(3, 10))查询类爬虫常见的问题是“返回结果和浏览器不一致”原因通常是翻页参数、排序参数或者用户登录态不同。我遇到这种情况会先把浏览器请求的完整URL、请求头和Cookie逐项对比找到差异后逐项调整。这里要特别提一句合规问题。无论是天气、战绩还是企业信息抓取数据前都应该确认目标网站是否允许爬虫访问尊重对方的使用条款、robots协议和版权约定。用于学习的小规模抓取一般问题不大但如果要商用或大规模抓取务必先获得授权。这也是源码包在部分案例后面特意补充合规提醒的原因。5. 高频报错与排错技巧我在实战中踩过的坑5.1 高频报错速查表爬虫开发中报错是常态关键是快速定位。我整理了实战中最常遇到的几类报错和对应的排查方向报错/问题常见原因解决思路429 Too Many Requests请求频率过高触发限流降低频率、随机延时、轮换User-Agent、指数退避重试Connection timed out网络问题或目标站响应慢设置合理的超时时间增加重试必要时换代理SSL: CERTIFICATE_VERIFY_FAILEDHTTPS证书异常verifyFalse并压制警告但不建议长期依赖UnicodeDecodeError或乱码编码解析错误设置resp.encoding优先使用apparent_encoding或页面meta编码KeyError/IndexError选择器未匹配到目标元素先打印页面片段确认元素确实存在检查是否被反爬跳转安全验证/验证码页面请求特征被识别补齐请求头、模拟浏览器行为必要时用PlaywrightImportError: No module named lxml缺少解析器依赖pip install lxmlRedis连接失败Scrapy-Redis部署时Redis未启动或配置错误检查Redis服务状态、端口、密码配置这里要特别提一下“选择器未匹配到元素”的问题。很多初学者定位不到数据第一反应是选择器写错了但实际往往是页面内容并没有加载出来。比如有些站点对外来请求直接返回了验证页面导致你的BeautifulSoup在解析验证页里自然找不到目标元素。这时候先打印resp.text的前500个字符看看拿到的是不是你以为的页面这个习惯能帮你省下大量排查时间。5.2 开发调试的实用技巧我平时调试爬虫会遵循几个固定习惯。第一是开启日志或加入足够的print但不要每一条解析都打印那会刷屏。比较好的做法是打印关键步骤比如当前URL、状态码、提取了几条数据print(f[DEBUG] {url} - status: {resp.status_code}, items: {len(items)})对于Requests脚本可以用logging模块替代print方便控制日志级别和输出文件。第二是善用浏览器的开发者工具。很多爬虫问题不是代码问题而是对页面理解不够。看一个页面时我通常先看Network面板里有没有XHR接口直接返回数据再看Element面板确认目标数据到底在哪个标签下有没有嵌套在iframe里。肉眼确认后再去写选择器成功率会高很多。第三是学会缩小问题范围。当爬虫出错时确定问题出在“请求”还是“解析”。最简单的验证方法是先用curl或浏览器访问目标URL确认数据是否存在、是否返回正常状态码。如果请求没问题问题就在解析如果请求都有问题那就要检查请求头、Cookie、代理这些外层因素。这个二分排查法对新手特别管用。第四是控制并发和频率。调试阶段永远用单线程、低并发跑通后再逐步加并发。直接在Scrapy里调高CONCURRENT_REQUESTS很容易触发反爬一旦被封IP反而更难调试。我通常的做法是保持CONCURRENT_REQUESTS4确认稳定后再逐步提升同时用DOWNLOAD_DELAY兜底。5.3 爬虫开发中的合规与边界意识这一节虽然不是技术代码但我觉得比代码更重要。爬虫本身是中性工具但使用不当会带来法律和道德风险。学习过程中尽量选择公开接口、官方文档允许的开放数据或者目标网站明确提供API的数据源。不要对需要登录才能访问的私有数据、个人隐私数据强行抓取也不要在大流量网站上做高频率压力测试。我在实际项目里给自己定的几条原则是遵守robots协议控制请求频率不干扰目标网站的正常服务抓到的数据只用于个人学习或已获授权的业务涉及用户信息的数据脱敏处理。这些原则也应该贯穿在源码包的学习过程中。爬虫技术真正的价值不是教会你如何绕过所有限制去抓数据而是让你理解网络数据的组织方式、HTTP协议的交互逻辑以及大规模数据处理的工程方法。把这些底层能力练扎实比多会几个骚操作重要得多。最后分享一个我自己的习惯每写完一个爬虫我都会花几分钟整理请求头、频率配置、解析器选择这些“初始参数”。下次遇到类似站点时直接套用这套初始化配置能省掉大量重复试错时间。这套源码包里的基础教程部分其实也承担了同样的角色——它把爬虫开发中最常用、最稳定的方案沉淀下来等你真正需要上手新项目时就有据可依了。本文还有配套的精品资源点击获取