简介：这是一份面向Python爬虫入门与进阶学习者的完整教程文档，内容涵盖爬虫基础概念、requests与BeautifulSoup解析、Scrapy框架、Selenium动态抓取，以及代理池、请求头伪装等反爬虫应对技巧，并配有电商商品数据抓取的实战项目。教程从原理到代码示例逐层展开，既适合零基础读者建立整体认知，也能帮助已有一定经验的开发者补齐反爬与动态渲染方面的短板。包内为1个doc文档，压缩后约38KB。虽体积不大，但结构完整，按“基础—工具—反爬—实战”组织，阅读时可根据目录快速定位。文档中穿插了可直接复用的Python代码片段，覆盖请求发送、页面解析、Scrapy项目创建和Selenium浏览器模拟等关键操作，便于边学边练。目前已有295人学习下载。对于想系统梳理Python爬虫知识、快速上手常见抓取场景的开发者来说，这份资料能够提供清晰的路线图和可落地的案例参考。
1. 为什么说 Python 爬虫开发是切入后端最稳的路线
Python 爬虫开发，听起来像是编程学习里最不起眼的方向，但对于从事数据采集、自动化测试、运维监控的开发者来说，这是第一个能把编程能力完整落地到「采集-解析-存储」闭环的技术方向。你在写的不再是练习题，而是一套真实系统：HTTP 请求怎么发、页面怎么解析、数据怎么落库、目标站点的反爬策略怎么应对，这些能力全部可以迁移到后端服务开发里。适合谁？刚学完 Python 语法想做真实项目的初学者，写了几个月 requests 脚本想升级成框架的熟手，以及需要定时采集数据做报表的从业者。这里有一条反直觉的结论：爬虫真正的难点不是写代码，而是把「请求、解析、存储」三个环节的边界分清楚。前期分不清，后期必然返工。这篇笔记按这条主线展开，每个环节都给可复现的命令和参数，结尾落到一个完整的落库实战上。
2. 前置准备：搭建开发环境与理解 HTTP 请求的底层逻辑
Python 爬虫开发的第一步，不是急着写爬虫代码，而是把开发环境和 HTTP 请求模型这两件事搞对。很多学了半年 requests 的人，一换电脑就装不回环境，一换目标站点就不知道怎么解析，问题基本都出在这一步。环境用 venv 隔离，请求用浏览器开发者工具拆解，这两件事只占整个开发流程的两成时间，却决定了后面八成调试效率。
2.1 用 venv 做环境隔离，别让依赖互相打架
爬虫项目的依赖面不算宽，但坑不少。requests、beautifulsoup4、lxml 是三个最基础的包，后面再叠加 Scrapy、pandas 这类工具，依赖树一深，版本冲突的概率直线上升。如果不做环境隔离，装一个新库可能破坏另一个库，而且极难排查。有人为了解决一个异常把系统 Python 卸载重装，结果所有项目一起瘫痪，这种事故在技术社区里每天都有。
虚拟环境解决的是依赖隔离问题：每个项目在独立目录里维护一套 Python 解释器和第三方包，互不干扰。在项目根目录执行：
python -m venv .venv source .venv/bin/activate # Windows 下用 .venv\Scripts\activate第一行创建虚拟环境目录，第二行激活。激活后终端提示符会带(.venv)前缀，此时通过 pip 安装的包都只属于当前项目。换新机器时，重新建环境并执行pip install -r requirements.txt就能恢复。
这里有个容易忽略的细节：新建环境后先升级 pip，再装依赖。旧版 pip 在解析某些带二进制扩展的包时会有兼容问题，报错信息经常模棱两可，明明卡在 pip 版本上，你会误以为是自己代码有问题。我一般会按顺序执行：
pip install --upgrade pip pip install requests beautifulsoup4 lxml pip freeze > requirements.txtpip freeze > requirements.txt把当前环境依赖固化到文件，等于给项目拍了一张快照。这样后期换电脑、上服务器，都不会出现"我这能跑你那跑不了"的尴尬。爬虫开发里环境就是地基，地基没打好，每换一次环境都像从头入行。
2.2 用浏览器开发者工具拆解一次真实请求：URL、Headers、Body、Cookie
新手写爬虫时最常遇到的困惑是：requests 拿到的东西和浏览器里看到的不一样。早期我总以为是自己代码写错了，后来才明白，浏览器发出的请求和脚本发出的请求本质上不是同一个"请求"。浏览器除了 URL，还会携带 User-Agent、Accept、Referer、Cookie 等一整套上下文，你只发一个裸 GET，服务器自然区别对待。
要看懂真实请求，最好的方式是打开浏览器开发者工具，切到网络面板，刷新目标页面，找到文档类型的那条记录。点开后重点看四块内容：
URL 部分包含路径与查询参数。分页类站点通常把 page 参数放在查询字符串里，这类参数要抽出来做循环。请求头里最关键的是 User-Agent 和 Referer，UA 声明客户端身份，Referer 表示来源页面，很多站点拿这两项做访问校验，少一个就 403。Cookie 分成两类：一类是服务器通过 Set-Cookie 下发的会话 Cookie，需要放在 Session 里自动管理；另一类是登录后才能拿到的授权 Cookie，可能需要手动注入。最后看 Content-Type，响应是text/html就解析 HTML，是application/json就直接调用resp.json()。把 JSON 当 HTML 去解析，会写出一堆永远取不到值的选择器。
这四块内容弄明白，后续所有 requests 请求就有依据。遇到反爬时，不用瞎猜哪里被拦，逐字段对照浏览器里的请求就能收敛问题。这一步说是爬虫开发的底层基本功，毫不夸张。
2.3 发出第一个 requests 请求：带 Header 和超时的最小实现
在拆解完请求链路以后，把它转成代码只需要几十行。我习惯把请求封装成函数，方便循环里复用，而不是每页重复写一遍 headers。最小可用版本如下：
import requests def fetch_page(url: str) -> requests.Response: headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) ", "Referer": "https://example.com/", } resp = requests.get(url, headers=headers, timeout=10) resp.raise_for_status() # 状态码非 2xx 时主动抛异常 return resp if __name__ == "__main__": resp = fetch_page("https://example.com/list") print(resp.status_code) print(resp.encoding) print(resp.text[:300])raise_for_status()是很容易被忽略的一行。没有它时，404、500 也会返回一个 Response 对象，代码继续往下跑，解析出来全是空数据，排查起来极其耗时。加上之后，出错立刻抛异常，调用栈直接指向具体 URL。timeout 参数我写的是 10 秒，它同时覆盖连接和读取两个阶段。如果想把连接和读取分开控制，可以传元组timeout=(5, 10)，连接等 5 秒、读取等 10 秒，这在接口偶发变慢的场景下更精准。
POST 场景也常用。目标如果是 JSON 接口，用requests.post(url, json=data, headers=headers, timeout=10)，json=参数会帮你自动序列化并设置正确的 Content-Type。有人会把这里误写成data=str(data)，导致服务端解析失败返回 4xx。GET 和 POST 的语义不同：列表分页用 GET 传 query，登录态验证用 POST 提交表单。
3. 数据解析：BeautifulSoup 与 XPath 的选型与具体用法
请求拿到的 HTML 本质是一棵文档树，解析就是在这棵树里精准定位目标节点，再提取文本和属性。Python 爬虫开发里有两套主流解析方案：BeautifulSoup 配 CSS 选择器，lxml 配 XPath。选哪套取决于项目规模和数据密度，后面逐一说明。
3.1 为什么解析是爬虫开发里最容易出"玄学"的环节
写解析代码最折磨人的场景，是同一个表达式在浏览器里明明能选中节点，换成脚本却返回空数组。这种问题多数不是表达式写错，而是程序拿到的 HTML 与你眼睛看到的 HTML 不是同一份。浏览器展示的是渲染完成的 DOM，而 requests 收到的是服务器返回的原始 HTML，两者存在本质差异。
尤其是用 JavaScript 动态渲染的页面，原始 HTML 里压根没有目标节点，抓下来的内容是一个空壳。遇到这种情况，先保存一份 resp.text 到本地文件，再对着本地文件写解析，能快速确定问题在请求环节还是解析环节。等解析写通了，再回去补请求策略，逻辑就清晰得多。
另一个容易翻车的是定位精度。"碰巧能选中"和"语义上应该选中"是两回事。比如列表页每个条目都有div.item，但这些节点里还混着推荐位、广告位甚至面包屑，class 可能带相同前缀，只写div.item会把不相干的数据都捞进来。我习惯先看目标节点在文档里的祖先层级，再挑最短且语义精准的路径，优先用id或>from bs4 import BeautifulSoup html = """<div class="article-list"> <div class="item">from lxml import html doc = html.fromstring(resp.text) # 定位所有 item，再取标题文本与链接 for node in doc.xpath("//div[@class='item']"): title = node.xpath(".//h3/a/text()") href = node.xpath(".//h3/a/@href") if title and href: print(title[0].strip(), href[0])
//div[@class='item']的含义是在整个文档任意层级查找 class 为 item 的 div 节点。//表示全文档匹配，@表示取属性。循环内再次查询时，.//开头的点号表示从当前节点开始向下找，不加点号会回到全文档重新匹配，这是新手写 XPath 最常见的错误。
如果只想要属性值列表，XPath 可以一步到位，不需要写循环：
hrefs = doc.xpath("//div[@class='item']/h3/a/@href")/h3/a用单斜杠表达"直接子节点"，适合结构稳定的页面；换成//h3/a会允许中间跨层级，牺牲一点精确度换稳定性。还要区分text()和//text()：前者只取当前节点直接文本，后者会拼接所有子孙节点文本。标题里带加粗或行内标签时，只调text()会丢内容，这时候先取节点，再用"".join(node.itertext())拼接才完整。
调试 XPath 有个省时技巧：在浏览器开发者工具的 Elements 面板里按 Ctrl+F，输入表达式就能在页面上直接高亮命中节点。写代码前先把表达式调通，能省掉大量改代码重跑的时间。
4. 工程化：从单脚本到 Scrapy 框架的迁移路径
requests 用顺手之后，很多人会陷入一个误区：遇到多页面抓取任务，就用线程池或 asyncio 把 requests 包一层。这样做不是不行，只是把框架已有的能力重复造了一遍。并发要自己控制、去重要自己维护、重试要自己写、代理要自己接入。Scrapy 把这些能力内建好了，这才是它值得迁移的原因。
判断是否要迁移，我一般看三个条件：目标页面是否超过一千个、是否需要递归抓取详情页、是否要定时增量运行。三个条件命中两个，迁移性价比就很高。命中一个或者零个，requests 足以胜任，没有必要为了框架而框架。
4.1 什么时候该从 requests 切到 Scrapy：并发、去重、调度
requests 的模型是阻塞的：发一个请求，等一个响应，再发下一个。即便用线程池提升效率，线程数一高，切换损耗和内存占用也上来了。Scrapy 默认的异步并发模型没有这个问题，能在几十个请求同时跑的情况下保持较低资源占用。
| 能力 | requests 脚本 | Scrapy |
|---|---|---|
| 并发模型 | 手动线程池或协程 | 内置异步并发 |
| 请求去重 | 自己维护集合 | 基于指纹自动去重 |
| 失败重试 | 自己写循环 | 内置重试中间件 |
| 代理轮换 | 手动集成 | 下载中间件扩展 |
| 数据处理 | 脚本内部组织 | Item Pipeline 分流 |
| 调度优先级 | 无 | 内置调度队列 |
这个对比不是让你立刻抛弃 requests，而是帮你判断什么时机换更划算。单页爬虫、接口调试、一次性数据采集，requests 完全够用。大规模持续运行的任务，硬要用 requests 把自己写成低配版 Scrapy，时间成本反而更高。我带过的项目里，有人为 5000 个页面手写线程池，代码换三个人才跑通，中间还因为取消任务的处理不完善导致重复入库。这种坑能避开就避开，迁移到框架的成本远比你想象的低。
4.2 Scrapy 项目的最小骨架：Items、Spider、Pipeline
创建一个 Scrapy 项目只要两条命令：
scrapy startproject demo_spider cd demo_spider scrapy genspider article example.comstartproject生成项目骨架，包含 items.py、middlewares.py、pipelines.py、settings.py。genspider创建名为 article 的爬虫模块，并自动写到spiders/article.py。注意allowed_domains会限制抓取范围，设错会把合法页面拦在外面，放太宽又会放走大量无关域名，迁移旧脚本时要仔细核对目标站点的子域名。
爬虫里先定义 Item，把要采集的字段声明出来：
import scrapy class ArticleItem(scrapy.Item): title = scrapy.Field() url = scrapy.Field() publish_time = scrapy.Field() source = scrapy.Field()Item 的作用是固定数据结构。后续 Pipeline 清洗、CSV 导出、数据库写入都围绕这段结构展开。没有 Item 时，数据随手装进字典，字段名不一致很难排查，这是工程化项目最容易出现的问题。
Spider 文件承载解析逻辑：
import scrapy from demo_spider.items import ArticleItem class ArticleSpider(scrapy.Spider): name = "article" start_urls = ["https://example.com/list"] def parse(self, response): for node in response.xpath("//div[@class='item']"): item = ArticleItem() item["title"] = node.xpath(".//h3/a/text()").get() item["url"] = response.urljoin(node.xpath(".//h3/a/@href").get()) item["publish_time"] = node.xpath(".//time/@datetime").get() item["source"] = self.name yield item.get()是 Scrapy Selector 的方法，等价于取第一个匹配结果，没有命中时返回 None，不会抛异常。response.urljoin把相对链接补全成绝对地址，省略这一步，后续 Pipeline 拿到的就是残缺路径。整个 parse 方法是生成器，每yield一个 Item 或 Request，框架就接手后续处理。这是 Scrapy 与 requests 的核心差异：requests 是主动循环，Scrapy 是回调驱动。
4.3 配置限速、重试、代理的落地参数
从 requests 迁移到 Scrapy，最容易犯的错是一上来就追求满并发。更稳妥的做法是保留原先的抓取节奏，逐步提高压力。settings.py 里的几个参数直接决定请求速率：
# settings.py 局部 DOWNLOAD_DELAY = 1.0 CONCURRENT_REQUESTS = 16 CONCURRENT_REQUESTS_PER_DOMAIN = 8 RETRY_ENABLED = True RETRY_TIMES = 3 RETRY_HTTP_CODES = [403, 429, 500, 502, 503] DOWNLOAD_TIMEOUT = 15DOWNLOAD_DELAY 控制每个请求之间的间隔秒数，和 CONCURRENT_REQUESTS 相乘基本就是每秒请求数。16 并发、1 秒延迟，实际每秒大约 8~16 个请求。面对不熟悉的站点，我会先开 8 并发、2 秒延迟，跑 20 分钟观察数据增长，再逐步加压力。
RETRY_HTTP_CODES 值得单独强调。默认重试列表里没有 403，但很多 403 是反爬拦截，配合代理中间件换 IP 重试有机会变成 200，所以我一般把 403 加进去。DOWNLOAD_TIMEOUT是单个请求的响应超时，设太短会遇到正常慢接口被误杀，设太长又会拖慢整体进度，15 秒是一个比较稳的起步值。
代理接入不写在 Spider 里，放在下载中间件中：
# middlewares.py 局部 class RandomProxyMiddleware: def process_request(self, request, spider): # 每次请求发送前从代理池取一个地址 proxy = proxy_pool.get_random() if proxy: request.meta["proxy"] = "http://" + proxyprocess_request在每个请求发出前被调用，统一给 request 的 meta 设置代理地址。这样业务逻辑与网络策略分离，后期要换代理池或者加白名单，改中间件一处就行。代理池的稳定性比数量更重要，一个不稳定的代理池带来的超时重试，会把有效抓取率拖到比直连还低。没有现成代理池时，我一般先不配代理，靠限速和随机延时也能应对大多数中小规模采集。
开发阶段把日志级别调成 DEBUG，能看到每个请求的状态码、耗时和去重记录；生产环境调回 INFO 或 WARNING，避免日志文件膨胀。这些细节平时看不出差别，线上跑起来之后，日志和限速配置就是保命的工具。
5. 爬虫避坑：高频问题的排查方法与血泪经验
下面按「现象 → 原因 → 解决」整理四条踩坑记录。这些坑在爬虫开发里几乎人人都会遇到，有一定规律性，排查一次记住方案，后面能省下大量时间。
5.1 返回 403 但浏览器能打开：Headers 缺失与 Cookie 同步失败
现象：脚本请求同一 URL 返回 403 Forbidden，浏览器里却能正常打开。
原因：服务器根据 User-Agent、Referer、Cookie 组合判断来访身份，脚本里要么没带全，要么带了固定值但不匹配服务端状态。还有一种常见情况是站点先下发 Cookie，后续请求必须携带该 Cookie，脚本没做这一步。
解决：用requests.Session()代替单次requests.get。
import requests session = requests.Session() headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) ", } # 先访问首页，让 Session 自动记住服务器种下的 Cookie session.get("https://example.com/", headers=headers, timeout=10) # 再带着 Cookie 访问目标页 resp = session.get("https://example.com/list", headers=headers, timeout=10) print(resp.status_code)Session 对象自动管理 Cookie，等效于模拟同一个浏览器的连续访问。如果此时还 403，就把浏览器开发者工具里该请求的完整 Headers 逐项复制到代码里，缺哪个补哪个，通常能定位到问题。
5.2 选择器昨天能中，今天全空：页面结构变化的三个应对习惯
现象：同一个抓取任务，上个月还能正常取出标题列表，今天返回空数组或空列表。日志里没有任何异常，只是数据量骤降到零。
原因：目标站点前端改版，class 改名、结构调整、HTML 渲染改成 JS 异步加载，都会让已有选择器失效。这类问题隐蔽，因为脚本不报错，只会静默地返回空结果。
解决：三条习惯配合使用。第一，选择器优先基于稳定语义属性，如 id、data-id，而不是渲染生成的 class 名。第二，在解析代码里加空结果告警，当一条列表解析出 0 条记录时，立刻输出警告日志，让问题在当天暴露。第三，线上环境放抽样校验脚本，每天随机抽 20 条结果与数据库已有记录比对字段完整性，发现异常就通知。很多爬虫事故都是在空数据状态下默默跑了好几天才被发现，代价很大。
5.3 数据重复入库：去重逻辑与增量更新的实践
现象：运行一天后，数据库里同一个 URL 对应多条记录，统计数量翻倍。
原因：同一条数据被多个入口解析到，或者爬虫中断后重新启动，把已处理过的页面又抓了一遍。requests 脚本里如果没有维护已访问集合，这个问题几乎必然出现。
解决：数据库层面建唯一索引，同时脚本里维护已处理的 URL 集合。
seen = set() def already_done(url: str) -> bool: if url in seen: return True seen.add(url) return False这段代码要放在数据提交之前。即便用 Scrapy 自带请求去重，Item 层面的业务去重仍然要做，因为同一个内容可能从两个不同入口页面被抓到。数据库语句层面，SQLite 用INSERT OR IGNORE，MySQL 用INSERT ... ON DUPLICATE KEY UPDATE，都能在重复写入时自动跳过，比先查再插少一次往返。
5.4 请求频率过高被封 IP：限速与代理切换的实操
现象：抓取跑到一半，所有请求开始返回 429 或 503，接着是超时，最后页面验证码伺候。
原因：单 IP 请求频率超过站点阈值，触发了限流或封禁。很多站点不限制并发，但会统计每分钟请求数，超过就临时拉黑。
解决：先降速，再看代理。请求间加随机延时比固定延时更接近人工点击节奏：
import random import time import requests def fetch_with_delay(url: str, headers: dict) -> requests.Response: time.sleep(random.uniform(1, 3)) return requests.get(url, headers=headers, timeout=10)random.uniform(1, 3)生成 1 到 3 秒之间的随机等待时间，能有效降低连续请求的指纹特征。当抓取量达到千万级再考虑代理池，代理池里同一 IP 的并发也要限制，否则换上去的新 IP 很快也会被封。规模不大的项目，保守限速永远是最安全的方案。
6. 实战项目：爬取一个真实站点并落库的全流程
最后这个项目把前面的内容串起来：目标是一个资讯站点的列表页，抓标题、链接、发布时间三个字段，落到 SQLite 数据库。存储选 SQLite 是因为零配置、单文件，适合爬虫这种单机任务。
6.1 目标与存储设计
表结构设计如下：
| 字段 | 类型 | 说明 |
|---|---|---|
| id | INTEGER PRIMARY KEY | 自增主键 |
| title | TEXT | 标题 |
| url | TEXT UNIQUE | 链接，建唯一索引 |
| publish_time | TEXT | 发布时间 |
URL 加 UNIQUE 约束，为后续的增量更新打底，这样同一篇文章不会因为重复运行而产生多条记录。
6.2 从请求解析到落库的完整脚本
import sqlite3 import requests from bs4 import BeautifulSoup headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) ", } conn = sqlite3.connect("news.db") conn.execute("CREATE TABLE IF NOT EXISTS articles (" "id INTEGER PRIMARY KEY, " "title TEXT, " "url TEXT UNIQUE, " "publish_time TEXT)") resp = requests.get("https://example.com/list", headers=headers, timeout=10) resp.raise_for_status() soup = BeautifulSoup(resp.text, "lxml") for block in soup.select("div.item"): title_node = block.select_one("h3 a") time_node = block.select_one("time") if title_node is None or time_node is None: continue title = title_node.get_text(strip=True) url = title_node.get("href") pub = time_node.get("datetime") # INSERT OR IGNORE 配合 url 唯一索引，重复运行不产生重复数据 conn.execute( "INSERT OR IGNORE INTO articles (title, url, publish_time) " "VALUES (?, ?, ?)", (title, url, pub), ) conn.commit() conn.close() print("done")INSERT OR IGNORE和 url 唯一索引组合，是小型爬虫最省事的增量方案：重复运行不会报错，也不会产生新数据。执行一次之后再次运行，数据库总行数不变，说明去重逻辑生效。
6.3 上线之后的主要维护点
跑起来之后我会盯三件事。第一，每天早上抽查一次新增数据量，新增是 0 就优先检查页面结构有没有变化。第二，记录每次运行耗时，耗时突然变长往往不是网站变慢，而是请求被限流。第三，定期清理解析代码里注释掉的旧选择器，爬虫项目最容易堆积这些历史残留，留着只会让维护的人无从下手。
我的一个固定习惯是：改完选择器就做一次对比测试。从上一批真实保存的页面 HTML 里抽十条，先跑旧解析逻辑，再跑新逻辑，确认结果完全一致后才放上线。这个动作成本很低，却能避免"改一处、挂一片"的事故。做爬虫其实是在和自己的耐心比赛，少追求一点极限并发，多预留一点结构变化的预判，这条路才走得远。希望帮到你。
本文还有配套的精品资源，点击获取
