简介：这份Python爬虫技术文档面向具备一定编程基础、希望系统掌握网络数据采集方法与规范的学习者和开发者，围绕从基础概念到实战技巧的路径展开。内容从爬虫的自动化抓取价值与Python语言优势讲起，梳理发送请求、解析网页、数据存储三大核心环节，并结合requests、BeautifulSoup、lxml与Scrapy说明各自特点与适用场景，同时涉及动态加载处理、反爬应对和效率提升等进阶思路。文档还强调遵守法律法规、网站协议与用户隐私保护，适合用于公开数据批量获取、信息监测系统构建及个人小项目练习。资源包共1个docx文件，约16KB，篇幅精炼，便于快速查阅关键知识点与代码示例。目前已有629人学习，可作为入门梳理和开发检索的参考材料。
1. 从一条请求说起：为什么爬虫的难点从来不在"爬"
很多人第一次写 Python 爬虫，五行代码就跑通了：发一个 HTTP 请求，拿回 HTML，find_all 抠出想要的字段。于是一个错觉扎根下来——网络爬虫不过是 requests 加选择器。真正上手抓第二个站，页面空白、字段错位、跑两百条就被掐断，血泪经验全在这一步补上。数据采集这件事的难点从不在"把字节拿回来"，而在三件更底层的事：让对面认为这是一次正常访问，让解析在你没见过的 HTML 上依然稳，让几千个请求不把连接数和内存撑爆。这三条约束分别对应请求层、解析层、调度层，也构成了整条链路的真正地基。
2. 请求层：requests 封装了什么，又凭什么被认出来
2.1 一次 GET 在网络栈上走过的路径
requests.get(url)这一行看起来只有一个函数调用，底下压着一条完整的链路：域名解析拿到 IP，建立 TCP 连接，如果是 HTTPS 还要走 TLS 握手协商密钥，然后才把一行GET /list?page=1 HTTP/1.1加上若干请求头写进 socket，等服务端回200 OK和一坨响应体。requests 帮你做的是把这一串动作收敛成对象：Response.status_code是状态行，Response.headers是响应头字典，Response.text是按某个编码解码后的字符串，Response.content是原始字节。
理解了这条链，就能理解为什么很多"抓不到"的问题不在解析而在握手阶段。下面这段是能直接跑的骨架，几个参数的取舍值得逐条说清。
import requests # timeout 必须显式给：不写就是无限等待，一个卡死的连接能拖垮整个循环 resp = requests.get( "https://www.example.com/list", # 不带 query，参数交给 params 更安全 params={"page": 1}, # requests 负责 URL 编码，避免手拼 & 和中文 headers={"Accept-Language": "zh-CN,zh;q=0.9"}, timeout=(3.05, 10), # (连接超时, 读取超时)，单位秒 allow_redirects=True, # 跟随 3xx，最多 30 次 ) # 服务端没在响应头里写 charset 时，text 会退回 ISO-8859-1，中文全是乱码 resp.encoding = resp.apparent_encoding # 按字节分布猜编码，再取 text print(resp.status_code, len(resp.text))timeout写成二元组是常见但容易忽略的细节：第一个值是建立连接的上限，第二个值是连接建立后等待首字节的上限。很多人只写一个数字，那是两者共用的兜底值，在丢包严重的链路上会让连接阶段等得过久。apparent_encoding的做法是拿响应体去试几种常见编码，选置信度最高的那个，代价是要多扫一遍字节，大响应体上会有可感知的开销，所以只在确认乱码时才用。
2.2 连接复用：Session 省下的不是代码行数而是握手时间
单次requests.get走完就关连接。如果一次任务要打一千个请求，等于做了一千次 TCP 三次握手和一千次 TLS 协商。TLS 握手在跨地域链路上动辄几十到几百毫秒，这部分开销在总耗时里占比相当可观。Session的核心价值就在这：它持有一个HTTPAdapter，底层是 urllib3 的连接池，对同一 host 的请求会复用已建立的连接，同时自动维护 Cookie 容器和默认请求头。
import requests from requests.adapters import HTTPAdapter session = requests.Session() # pool_maxsize 是单个 host 的连接池上限，默认 10 # 并发数超过它时，连接会被反复丢弃重建，反而比单线程还慢 adapter = HTTPAdapter(pool_connections=20, pool_maxsize=20, max_retries=0) session.mount("https://", adapter) # 只对 https 生效，http 需另挂一个 session.headers.update({"User-Agent": "Mozilla/5.0 ..."})pool_maxsize和pool_connections的区别常被混淆：前者是每台主机保留多少条空闲连接，后者是总共缓存多少台主机的池子。把pool_maxsize设得远大于实际并发没有意义，设得小于并发则会出现"刚建好就被挤掉"的抖动，表现为耗时曲线忽高忽低。血泪经验是让pool_maxsize略大于你的并发 worker 数，多留两三条余量即可。
2.3 改了 User-Agent 还是被拦：识别维度不止请求头
新手最常见的认知是"设置一个浏览器 UA 就万事大吉"。现实里服务端能看到的信号至少有四层，UA 只是最表层的一个。
第一层是请求头的完整性与顺序。用 requests 默认配置发出去的头部集合和真实浏览器差异很大，比如缺少Accept、Accept-Encoding、Sec-Fetch-*系列，且头部排列顺序往往是固定模板。第二层是 TLS 握手的指纹，也就是 ClientHello 里携带的加密套件列表、扩展顺序、椭圆曲线偏好等组合特征。这一层在应用层完全看不见，requests 走的是标准 TLS 栈，其指纹和主流浏览器有明显区别，无论你把 UA 改得多像都没用。第三层是 Cookie 与状态的一致性，一次会话里前后请求的 Cookie 集合应当自洽，凭空多出或少掉字段都像机器行为。第四层是访问节奏，固定间隔 0.5 秒的请求序列在统计上过于规整。
提示：这四层里，只有第一层和第三层是应用代码能低成本改善的，第二层要靠换底层 HTTP 实现，第四层靠随机化间隔。任何"改一个头就过"的偏方都只在特定站点成立。
2.4 重试与退避：把失败当成常态来设计
爬虫跑到一定规模后，失败率不会是 0。限流返回 429、网关抖动返回 502、连接被重置，这些都是常态。缺省行为是抛异常然后整个任务崩掉，更好的做法是把重试策略显式声明出来，让对方看到的是"退一步再来"，而不是"撞墙式重试"。
from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry retry = Retry( total=3, # 最多重试 3 次 backoff_factor=0.5, # 退避基数：第 n 次等待 0.5 * 2^(n-1) 秒 status_forcelist=[429, 500, 502, 503, 504], allowed_methods=["GET"], # 只重试幂等方法，POST 重试可能重复提交 respect_retry_after_header=True, # 服务端给了 Retry-After 就听它的 ) session.mount("https://", HTTPAdapter(max_retries=retry))backoff_factor是这套机制的关键。它产生的是指数退避序列，配合respect_retry_after_header能显著降低二次触发限流的概率。把allowed_methods限制在 GET 上也重要，写操作重试可能造成重复入库，这类事故排查起来非常难。
3. 解析层：BeautifulSoup 和 lxml 的分岔，藏着容错与性能的取舍
3.1 从字节到 DOM 树：解析器到底在做什么
拿到 HTML 字符串只是起点，真正的数据结构是一棵 DOM 树。解析过程分两步：先做词法分词，把连续的字符流切成标签、属性、文本、注释这些 token；再做建树，按 HTML 规范里的隐式闭合规则把 token 组织成父子节点。第二步是复杂度的来源——真实世界的 HTML 大量存在未闭合的<p>、错位的</div>、多余的<table>嵌套，浏览器能容忍这些错误并给出可用的树，这就是所谓的容错解析。
理解这一点很关键：你选哪个解析器，直接决定了"一棵烂 HTML 会被建成什么样的树"。树不一样，同样的选择器就可能命中不同的节点，这是很多"本地跑通线上跑不通"的真正原因。
3.2 三个解析器的账：速度、容错、依赖
| 解析器 | 底层实现 | 速度量级 | 容错行为 | 额外依赖 |
|---|---|---|---|---|
html.parser | Python 标准库 | 慢 | 中等，遇错常直接丢弃 | 无 |
lxml | C 库 libxml2 | 快 | 严格，遇错可能截断树 | 需要编译安装 |
html5lib | 纯 Python 实现规范 | 最慢 | 最接近浏览器 | 无 |
这张表决定了选型逻辑：批量任务、结构规整的页面用lxml；页面结构混乱、需要和浏览器完全一致的树，用html5lib换取正确性；只是临时验证、不想装编译依赖，用html.parser顶一下。常见的实现思路是先用lxml跑通全量，再用html5lib对失败的样本做一次补偿解析，两者结合兼顾吞吐和覆盖率。
from bs4 import BeautifulSoup # 用 lxml 作为后端，比 html.parser 快一个量级左右，但遇到严重畸形 HTML 会截断 soup = BeautifulSoup(html_content, "lxml") # 想和浏览器行为对齐时换成 html5lib，代价是慢 soup_strict = BeautifulSoup(html_content, "html5lib")3.3 BeautifulSoup 的定位语义与 lxml 的 XPath 差异
两个库的思路完全不同。BeautifulSoup 是"遍历对象"，你拿到的是 Tag 对象，通过属性访问和find_all逐层下钻；lxml 是"用表达式描述路径"，XPath 把目标节点的位置写成一条从根节点出发的路径表达式，由引擎一次性求值。前者写起来直观、调试容易，后者表达力强、能一次定位到深层节点。
from bs4 import BeautifulSoup from lxml import etree soup = BeautifulSoup(html_content, "lxml") # find_all 返回列表，属性用 get 取，空值不会抛异常而是返回 None for a in soup.find_all("a", class_="item-link"): print(a.get("href")) html = etree.HTML(html_content) # XPath 用 // 从任意层级开始匹配，text() 直接取文本节点 titles = html.xpath("//div[@class='list']//h2/text()") # 取属性要用 /@ 而不是 text() hrefs = html.xpath("//a[contains(@href, '/detail/')]/@href")一个容易踩的差异：text()取到的是直接文本子节点，如果标题内部还套了<span>高亮标签，//h2/text()只会返回前半截。稳妥写法是//h2//text()再拼接，或者用string(//h2)取整棵子树的文本。这个坑在带关键词高亮的搜索页上极高频。
3.4 选择器的脆弱性：按 class 抓为什么迟早崩
多数站点用的是构建工具生成的 class 名，形如sc-1x2y3z或带哈希后缀的样式名。这类名字会随每次前端发版变化，按它写死的选择器在下次发版后必然失效。更稳的锚定策略是优先依赖语义结构：找一个变化频率低的容器节点（比如带固定 id 的列表区），再在其内部按相对位置或稳定属性定位。
判断一个选择器是否可靠，可以问三个问题：这个属性是给人看的还是给机器看的？它在三个不同页面样本里是否一致？前端改版时最可能动的是什么？如果答案指向"可能动"，就要准备回退路径。工程上的做法是写一组候选选择器，按优先级依次尝试，首个命中即返回，全部未命中的样本单独落盘留待人工分析。这套"多候选 + 失败样本留存"的组合，是让解析层在长期运行中不崩的关键。
4. 调度层：Scrapy 把引擎拆成五个组件，解决的是什么问题
4.1 同步阻塞的成本模型：95% 的时间在等
一个 HTTP 请求的耗时里，真正花在本地 CPU 上的部分极少，绝大部分时间是在等网络往返、等服务端处理、等响应体传输。同步代码的模型是"发出去就阻塞在这个线程上"，这段时间线程什么都做不了。假设单请求平均 200 毫秒，本地处理 5 毫秒，那么线程利用率不到 3%，一万个请求串行要跑半个多小时。
多线程能摊薄这个浪费，但线程本身有成本：每个线程要占栈空间，上下文切换有开销，几百个线程之后调度本身就成了瓶颈。而且 Python 的 GIL 让线程在 CPU 密集场景下无法并行，虽然爬虫属于 IO 密集、GIL 在等待期间会释放，但线程模型的天花板依然明显。这就是异步 IO 存在的理由：单线程里用一个事件循环管理成百上千个挂起的请求，谁的数据到了就唤醒谁，切换成本从操作系统级降到用户态的函数调用。
4.2 引擎、调度器、下载器、Spider、Pipeline 的职责边界
Scrapy 的架构本质上是把上面这套并发模型产品化。它拆成五个组件，每个只干一件事：
| 组件 | 职责 | 关键点 |
|---|---|---|
| Engine | 控制数据流，协调各组件 | 不写业务逻辑，只管转发 |
| Scheduler | 维护待抓 URL 队列，去重 | 去重是它最核心的职责 |
| Downloader | 执行实际请求，返回 Response | 并发与限速在这一层 |
| Spider | 解析 Response，产出 Item 和新 URL | 业务代码唯一该写的地方 |
| Pipeline | 清洗、校验、持久化 Item | 按优先级顺序串行执行 |
数据流是一条单向环路：Engine 从 Scheduler 取一个 Request 交给 Downloader，Downloader 返回 Response 交给 Spider 解析，Spider 吐出 Item 和新的 Request，Item 进 Pipeline，Request 回 Scheduler。这种设计的价值在于每层的失败可以独立观测和处理——下载失败记在 Downloader 的统计里，解析异常记在 Spider 的日志里，两者不会混在一起。
import scrapy class ListSpider(scrapy.Spider): name = "list" start_urls = ["https://www.example.com/list"] # 自定义设置：只针对这个 Spider 生效，覆盖全局配置 custom_settings = { "DOWNLOAD_DELAY": 0.5, # 同域名相邻请求的最小间隔 "CONCURRENT_REQUESTS_PER_DOMAIN": 4, # 单域名并发上限 "RETRY_TIMES": 2, } def parse(self, response): # response.xpath 直接返回选择器列表，extract() 取值 for node in response.xpath("//div[@class='item']"): yield { "title": node.xpath("./h2/text()").get(default="").strip(), "url": response.urljoin(node.xpath("./a/@href").get()), } # 翻页：把下一个 Request 交回调度器，而不是自己发 next_page = response.xpath("//a[@rel='next']/@href").get() if next_page: yield response.follow(next_page, callback=self.parse)4.3 并发参数怎么配：CONCURRENT_REQUESTS 与 DOWNLOAD_DELAY 的配合
这两个参数的关系常被误解。CONCURRENT_REQUESTS是同时在途的请求数上限，DOWNLOAD_DELAY是同域名相邻两次请求之间的最小间隔。它们不是替代关系：前者控制"同时压多少"，后者控制"每秒打多少"。只调大并发不设延迟，等于在最短时间内把请求数打满，触发限流的概率极高；只设延迟不调并发，则退化成串行。
合理的起点是延迟 0.5 到 1 秒、单域名并发 4 到 8，然后根据响应码分布调整：如果 429 和 503 的比例上升，先加延迟而不是减并发。AUTOTHROTTLE_ENABLED可以让框架根据响应延迟自动调节，但它的调节有滞后性，突发限流时反应不够快，仍需要人工兜底阈值。
4.4 asyncio 版的最小实现
不用框架时，asyncio加aiohttp能复刻同样的模型。关键在于把"等待"变成可挂起的 await 点。
import asyncio import aiohttp async def fetch(session, url, sem): # Semaphore 控制同时在途的协程数，等价于 CONCURRENT_REQUESTS async with sem: try: async with session.get(url, timeout=aiohttp.ClientTimeout(total=10)) as resp: return await resp.text() except asyncio.TimeoutError: return None # 超时不抛出，交给上层统计 async def main(urls): sem = asyncio.Semaphore(8) connector = aiohttp.TCPConnector(limit=20, limit_per_host=8) # 连接池上限 async with aiohttp.ClientSession(connector=connector) as session: tasks = [fetch(session, u, sem) for u in urls] return await asyncio.gather(*tasks) # 全部完成才返回 results = asyncio.run(main(url_list))Semaphore和TCPConnector的双重限制不是冗余：前者约束协程的并发数，后者约束底层连接的复用上限。只设前者会导致协程数超过连接池容量，请求在等连接而不是等网络，反而变慢。asyncio.gather的默认行为是一个任务抛异常就整体失败，生产代码通常要加return_exceptions=True收集局部失败，避免一条坏 URL 拖垮整批。
5. 避坑与排查：爬虫翻车的六种现场
5.1 现象、原因、解决：六条踩坑记录
现象一：本地跑通，换台机器返回的内容完全不一样。原因通常是请求头或 Cookie 携带了本机环境残留，或者目标站按出口地址做了区域化返回。解决方式是先把请求头收敛成一份显式白名单，只留必要字段，再用同一份配置在两台机器上跑同一 URL 对比响应哈希，差异点立刻暴露。
现象二：明明页面能看到数据，抓下来是空壳。原因是数据由前端 JS 在挂载后异步拉取，初始 HTML 里根本没有。判断方法很简单：关掉浏览器 JS 再刷新，看内容是否还在。不在就说明要换思路，要么直接找它请求的数据接口，要么用浏览器自动化驱动执行 JS 后取page_source。
现象三：跑了几十条之后全部超时，重启又正常。这是连接池和文件描述符被耗尽的典型表现。检查Session是否在循环里反复新建而没有关闭，以及pool_maxsize是否远小于并发数。修复是复用单一 Session，并在批量任务结束时显式close()。
现象四：解析出来的字段整体错位一行。原因是列表里混入了广告位或置顶项，其 DOM 结构和正常条目不同，你的选择器把它也匹配进来却没有对应字段。排查方式是统计每条记录的字段完整度，缺失率异常的那几条单独打印原始 HTML 对比。修复是在选择器里加上结构约束，或用父容器的固定 class 先做过滤。
现象五：中文全部变成乱码，且不同页面乱得不一样。响应头缺 charset 时 requests 默认按 ISO-8859-1 解码。用apparent_encoding能猜个大概，但混编码页面会猜错。更稳的做法是先用resp.content拿字节，再按页面<meta charset>声明解码，两者都没有才退回猜测。
现象六：入库数据出现重复行，且去重逻辑明明写了。高频原因是重试机制把同一个请求发了两次，而写库没有幂等约束。这类问题的后悔药是给数据表加唯一索引，把去重从"代码里判断"降到"存储层拒绝"，比任何内存 Set 都可靠。
5.2 抓不到数据时的分层排查顺序
出问题时最忌讳从头改起。有效的顺序是从外往里逐层验证，每一层都有明确的观测点。
第一步，用curl直接打同一个 URL，看返回的状态码和响应体长度。这一步排除了代码层干扰。如果curl也是空壳，问题在网络或目标站，与解析无关。第二步，比对请求头，逐项删减找出关键的那一个，而不是一次全加上。第三步，把响应体落盘成文件，脱离网络用本地文件反复调解析器，这样能快速迭代选择器而不触发限流。第四步，对失败的样本做聚类，看是集中在某个页面类型还是随机分布，前者是解析问题，后者是调度或限流问题。
注意：排查期间不要用生产流量的并发去跑测试，一次限流的代价可能是几小时的封禁期，反而拖慢定位。
6. 边界与取舍：robots.txt 不是形式，抓取频率是给自己留的后悔药
技术上讲，只要请求发得出去，页面就抓得到。真正决定一个采集任务能不能长期跑下去的，是边界管理。robots.txt是一个放在站点根目录的纯文本文件，用User-agent分组声明哪些路径允许、哪些禁止，还可以用Crawl-delay给出建议间隔。它没有强制力，但它是站点方明确表达意愿的唯一标准渠道，遵守它的成本几乎为零——解析规则只有几条，用标准库就能读完。
import urllib.robotparser rp = urllib.robotparser.RobotFileParser() rp.set_url("https://www.example.com/robots.txt") rp.read() # 判断某个 UA 能否访问某路径，第二个参数是 UA 字符串 allowed = rp.can_fetch("*", "https://www.example.com/list") delay = rp.crawl_delay("*") # 可能返回 None，需要给默认值取舍点在于，Crawl-delay是建议值不是强制值，很多站点干脆不写。这时候的判断依据要退回到"我的请求量相对这个站点的正常流量是什么比例"。如果一个小站日均访问几千次，你的爬虫每小时打几万次，无论技术上是否可行，都会给对方造成实质负担。这也是为什么频率控制应该设计成可调参数而不是硬编码常量——出问题时能立刻降下来，而不是改代码重新发布。
另一个常被低估的取舍是数据留存。抓下来的原始 HTML 该不该存？存了占空间，不存则解析逻辑一改就无法回溯验证。我一般的做法是只对解析失败的样本留存原始响应，加上时间戳和 URL，控制在一个可接受的体积内，其余正常样本只留结构化结果。这样既保留了调试能力，也不至于让磁盘成为负担。
隐私这一侧同样有明确边界：公开页面上的个人身份信息不等于可以采集的数据，尤其当采集目的是聚合而非引用时。判断标准可以简化成一句——如果数据的主体知道你在收集它，是否会感到意外。会，就说明越界了。
这套东西我踩过太多次坑之后形成了一个固定习惯：任何新任务开工前，先读一遍目标站的 robots.txt，先把延迟设成 1 秒跑通全流程，再逐步压到对方能接受的极限。见过太多因为一开始就拉满并发、被限流之后再也进不去的场面，那才是真正的时间损失。希望帮到你，把这份资源里的请求、解析、调度三段代码逐段跑一遍，比读十篇教程更能建立直觉。
本文还有配套的精品资源，点击获取
