8类经典爬虫项目实战：从静态解析到并发调度与数据清洗

爬虫这个领域有个很有意思的现象真正天天在写采集脚本的人很少去追什么热门项目榜单反倒是刚入门的朋友特别容易被8个必收藏的爬虫项目这类标题吸引收藏夹塞得满满当当真到要动手抓数据的时候还是不知道从哪下手。我自己在这个方向上摸爬滚打这些年带过不少新人也维护过几套长期跑在生产环境里的采集任务慢慢发现一个规律——那些被反复提及的经典爬虫项目价值根本不在代码本身而在于它们各自代表了一类典型场景和一套解决问题的思路。你把它们的骨架拆开看懂了遇到新站点时脑子里会自动跳出这个跟那个静态列表页是一路货这个得按接口逆向那套来的判断这才是可以不用但一定要知道的真正含义。这篇内容我打算换个讲法不给你贴一堆复制粘贴就能跑的脚本——那种东西网上到处都是而且站点结构一变就全废。我想做的是把这8类爬虫项目按场景—原理—实现要点—坑在哪这条线拆开讲透每一类都告诉你它解决的是什么问题、核心代码长什么样、参数为什么这么设、实际跑起来会撞上什么。全文会涉及静态页面解析、接口数据抓取、分页与增量、并发调度、登录态维持、动态渲染、文件资源批量获取、数据清洗入库这八个方向基本覆盖了日常采集工作里八成以上的场景。不管你是刚学完语法想找个练手方向还是已经能写点脚本但总在某个环节卡住应该都能从里面找到对你有用的东西。文中所有站点和项目均为虚构代称代码只保留结构逻辑你套到自己目标上时按实际情况调整即可。1. 先想清楚这8类项目到底在练什么很多人拿到一份项目清单就开始逐个抄代码抄完八个发现自己还是不会独立写。问题出在把项目当成了目的而不是练习载体。我习惯把爬虫能力拆成三层取数层怎么把目标内容拿到手、调度层怎么稳定、高效、不重复地拿、处理层拿到之后怎么变成能用的数据。这8类项目恰好是这三层能力的不同组合训练先建立这个认知后面看每一类就不会觉得是零散技巧的堆砌。1.1 取数层的两条主线解析页面 vs 逆向接口取数层是所有爬虫的地基而它其实只有两条主线。第一条是解析页面也就是请求回来的是HTML你用解析库从标签树里把目标抠出来第二条是逆向接口页面本身只是个壳真正的数据是前端通过异步请求拿到的JSON你直接对着那个接口发请求拿到的就是结构化数据省掉解析这一步。这两条路线的选择不是凭喜好而是看目标站点怎么组织数据。我一般的判断流程是这样的打开目标页按F12看网络面板刷新一次筛出XHR/Fetch类型的请求逐个看响应体里有没有你要的字段。如果有优先走接口路线因为JSON解析比HTML解析稳定得多字段名一般不会随便改而页面结构改版是家常便饭。如果响应里全是HTML、数据都嵌在标签里那就老老实实走解析路线。提示判断走哪条路线永远先看网络面板再动手写代码。我见过太多人上来就requests.get然后BeautifulSoup跑了两天才发现数据根本不在HTML里白白浪费工夫。1.2 调度层的核心矛盾快和稳怎么平衡调度层解决的是怎么持续地拿。新手最容易犯的错是把并发开到最大、请求间隔设成0结果要么被目标站点限流封禁要么把自己的网络打满导致大量超时。这里有个基本认知采集任务的瓶颈往往不在你的代码速度而在目标站点的承受能力和你的网络质量。所以调度设计的核心不是跑得越快越好而是在可接受的失败率下尽量快。具体到参数上并发数、请求间隔、超时时间、重试次数这四个是一组联动参数。我的经验起点是单机并发控制在5到10之间请求间隔0.5到1秒起步超时设10秒重试2到3次并带指数退避。这套参数不是拍脑袋而是基于大多数中小型站点的响应特征——它们通常能承受每秒个位数的请求超过就容易触发防护。当然具体还要实测后面第4节会讲怎么根据失败率动态调整。1.3 处理层的价值数据不洗等于没采处理层最容易被忽视但它决定了你采回来的东西能不能用。原始数据里常见的脏东西包括字段缺失、类型混乱数字存成字符串、重复记录、编码错乱、空白字符混入。我见过有人采了几万条数据兴冲冲要分析结果发现一半记录的日期字段格式不统一清洗花的时间比采集还多。所以从项目练习阶段就要养成习惯采集脚本里就带上基础清洗和去重逻辑而不是等数据落库了再回头处理。去重可以用目标唯一标识比如详情页URL里的ID做集合判断清洗至少要做去空白、类型转换、编码统一这三件事。这部分在第8类项目里会展开讲具体实现。2. 静态页面解析类项目最经典的入门训练静态页面解析是爬虫的Hello World但它绝不是没技术含量。恰恰相反把静态解析做扎实你对HTTP请求、编码、DOM结构的理解会直接上一个台阶后面学什么都快。这类项目的典型代表就是抓取一个列表页翻页拿到所有条目再进详情页拿完整信息。2.1 请求构造请求头里藏着成败很多人第一个脚本就卡在请求返回403或者返回的内容跟浏览器看到的不一样。九成原因是请求头没构造好。最基础的三个头是User-Agent、Referer和Accept。User-Agent告诉服务器你是什么客户端缺了它很多站点直接拒绝Referer说明你从哪个页面跳过来的有些站点会校验Accept声明你能接受什么内容类型。import requests headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://example.com/list, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9, } resp requests.get(https://example.com/list, headersheaders, timeout10) resp.encoding resp.apparent_encoding # 关键处理编码 html resp.text这里有个细节值得单独说编码处理。requests默认会根据响应头里的Content-Type猜编码但很多站点不写或者写错导致中文变成乱码。resp.apparent_encoding会基于内容本身去猜准确率高很多。我一般会先试resp.encoding发现乱码再切到apparent_encoding或者直接指定resp.encoding utf-8。这个坑几乎每个新人都踩过记住就行。2.2 解析选型BeautifulSoup、lxml还是正则解析HTML有三条常见路线各有适用场景不是谁绝对更好。方案优势劣势适用场景BeautifulSoup语法友好、容错强速度偏慢结构不规则、需要快速开发lxml XPath速度快、表达力强语法略陡结构规整、数据量大正则极致灵活难维护、易出错目标极简单或非HTML文本我的实际选择习惯是结构规整的列表页用XPath结构混乱或需要容错的用BeautifulSoup正则只在解析非HTML文本比如嵌在script里的JSON片段时才用。用正则解析HTML是下策因为HTML不是正则语言稍微复杂点的嵌套结构就会让你写出无法维护的表达式。from lxml import etree tree etree.HTML(html) # 抓列表里每个条目的标题和链接 items tree.xpath(//ul[classlist]/li) for item in items: title item.xpath(.//a/text())[0].strip() link item.xpath(.//a/href)[0] print(title, link)XPath里有个容易忽略的点//是全局搜索.//是相对当前节点搜索。在循环里一定要用.//否则每次都会从整个文档重新找既慢又容易抓错。这个细节我在代码review里见过太多次。2.3 翻页逻辑别只会写死页码翻页是静态列表项目的核心环节。最简单的翻页是URL里带页码参数比如?page1你循环改数字就行。但实际站点花样很多有的页码在URL路径里/list/page/2有的用POST请求带页码有的翻到一定页数后需要登录还有的干脆是加载更多按钮触发异步请求。我的处理原则是先确认翻页的终止条件再写循环。终止条件可能是返回空列表没有下一页链接达到预设最大页数。写死最大页数是最稳妥的兜底防止死循环。另外要处理页码超出范围返回第一页这种坑——有些站点你请求第999页它不报错而是返回第1页内容如果你不判断就会无限采集重复数据。page 1 seen set() while page 50: # 兜底上限 url fhttps://example.com/list?page{page} html fetch(url) items parse_items(html) if not items: break # 空列表终止 new_count 0 for it in items: if it[id] not in seen: seen.add(it[id]) new_count 1 if new_count 0: break # 全是重复说明翻页失效终止 page 1这段代码里new_count 0的判断很关键它同时防住了翻页参数失效返回重复内容和站点忽略页码两种情况。这种防御性写法是长期跑采集任务养成的习惯。3. 接口数据抓取类项目效率最高的一条路如果说静态解析是从成品里挑零件那接口抓取就是直接去仓库拿原料。这类项目的核心能力是看懂前端请求、复现请求参数一旦打通采集效率和稳定性都远超页面解析。3.1 接口定位从网络面板到参数还原定位接口的标准流程打开目标页F12进网络面板勾选XHR/Fetch过滤刷新页面按响应大小或关键词排序找到返回目标数据的那个请求。找到之后要做三件事记录请求URL、记录请求方法GET还是POST、记录请求头和请求体。难点通常在请求参数的来源。很多接口带签名参数sign、token、timestamp之类这些参数是前端JS算出来的直接复制会过期。这时候有两条路一是分析JS找到签名算法用Python复现二是用浏览器自动化让页面自己算第6节会讲。前者效率高但需要读JS后者省事但慢。我的建议是先用浏览器自动化跑通流程验证可行性再决定要不要投入时间逆向签名。import requests import json url https://example.com/api/list params { page: 1, size: 20, category: tech, } headers { User-Agent: Mozilla/5.0 ..., Referer: https://example.com/, X-Requested-With: XMLHttpRequest, } resp requests.get(url, paramsparams, headersheaders, timeout10) data resp.json() # 接口返回JSON直接解析 for row in data.get(data, {}).get(list, []): print(row[title], row[publishTime])注意resp.json()比json.loads(resp.text)更稳妥它会自动处理编码。另外接口返回的JSON结构往往嵌套很深取值时用.get()链式调用比直接用[]安全字段缺失时不会抛异常。3.2 参数规律分页、时间戳与游标接口的分页参数有三种常见形态理解它们的区别很重要。第一种是页码分页page/size最简单但数据量大时深翻页性能差。第二种是时间戳分页before/after某个时间常见于信息流类接口适合增量采集。第三种是游标分页cursor/offset服务端返回一个游标下次请求带上它这种最稳定但需要保存游标状态。增量采集是接口类项目的核心价值。我的做法是记录上次采集到的最大时间戳或最大ID下次只请求比它新的数据。这样每次只拉增量既快又不会重复。实现上就是把游标持久化到本地文件或数据库脚本启动时先读出来。注意时间戳分页要留意服务端时区和你的本地时区是否一致我踩过一次坑采集的时间范围整体偏移了8小时排查了半天才发现是时区问题。3.3 反爬应对频率、指纹与状态码接口类项目最常撞上的反爬是频率限制。表现是请求几十次后开始返回429Too Many Requests或者干脆返回空数据。应对思路不是硬刚而是降频退避分散。降频就是加大请求间隔退避是遇到限流后等待时间指数增长分散是轮换请求头里的User-Agent必要时轮换出口。import time import random def fetch_with_backoff(url, headers, max_retry3): for attempt in range(max_retry): try: resp requests.get(url, headersheaders, timeout10) if resp.status_code 200: return resp.json() elif resp.status_code 429: wait (2 ** attempt) random.uniform(0, 1) time.sleep(wait) else: time.sleep(1) except requests.RequestException: time.sleep(2 ** attempt) return None这段退避逻辑里加了随机抖动random.uniform目的是避免多个任务在同一时刻集体重试造成二次冲击。这个技巧在并发场景下尤其重要后面第5节还会提到。4. 分页与增量采集项目让脚本能长期跑单次采集和长期采集是两码事。前者跑通就行后者要考虑断点续传、增量识别、状态持久化。这类项目练的是工程化思维也是从会写脚本到能维护任务的分水岭。4.1 断点续传状态存哪里断点续传的核心是把采集进度持久化。最简单的做法是每采完一页就把当前页码写进一个本地文件脚本启动时先读这个文件从记录的页码继续。稍微复杂点的是记录已采集的ID集合用集合去重。数据量大时集合会占内存这时候用数据库的唯一索引或者布隆过滤器更合适。我一般用SQLite做状态存储因为它零配置、单文件、支持事务非常适合单机采集任务。建一张进度表记录任务名、当前游标、更新时间每次采集前读、采集后写简单可靠。import sqlite3 conn sqlite3.connect(crawler_state.db) conn.execute( CREATE TABLE IF NOT EXISTS progress ( task TEXT PRIMARY KEY, cursor TEXT, updated_at TEXT ) ) def get_cursor(task): row conn.execute( SELECT cursor FROM progress WHERE task?, (task,) ).fetchone() return row[0] if row else None def save_cursor(task, cursor): conn.execute( INSERT OR REPLACE INTO progress(task, cursor, updated_at) VALUES(?, ?, datetime(now)), (task, cursor) ) conn.commit()INSERT OR REPLACE是SQLite的语法糖存在就更新、不存在就插入省掉先查后写的两步操作。这种小技巧能让代码简洁不少。4.2 增量识别怎么知道哪些是新的增量识别的关键是找到一个单调递增的标识。常见的有发布时间、自增ID、更新时间戳。找到之后每次采集只处理标识大于上次记录的数据。这里有个陷阱如果标识不是严格单调的比如发布时间可能被编辑修改就会漏采或重采。稳妥的做法是留一个时间窗口重叠比如每次从上次最大时间戳减去1小时开始采靠去重逻辑兜住重复部分。4.3 失败重采把错误也存下来长期跑的任务一定会遇到失败。我的习惯是把失败的URL和原因单独存一张表主流程跑完后统一重采失败项。这样既不影响主流程进度又能保证数据完整性。失败原因要记清楚超时、404、解析失败、限流因为不同原因的处理策略不同——超时可以重试404重试也没用解析失败说明页面结构变了需要改代码。5. 并发调度类项目从单线程到任务队列单线程采集慢是必然的但并发不是简单加个线程池就完事。这类项目练的是任务拆分、并发控制、异常隔离做得好能让采集速度提升一个数量级做不好就是一堆报错和封禁。5.1 并发模型选型线程、进程还是协程Python里做并发有三条路选错了会事倍功半。模型适用场景关键限制多线程IO密集型网络请求GIL限制CPU并行多进程CPU密集型解析、计算进程间通信开销大协程asyncio高并发IO需要异步库支持爬虫绝大多数时间是花在等网络响应上属于典型的IO密集型所以多线程和协程是主力。多线程写法直观、生态成熟适合中小规模协程在几千并发时资源占用远低于线程适合大规模采集。我的经验是几百并发以内用线程池足够上千并发考虑协程。from concurrent.futures import ThreadPoolExecutor, as_completed def fetch_one(url): try: resp requests.get(url, headersheaders, timeout10) return url, resp.text except Exception as e: return url, None urls [fhttps://example.com/item/{i} for i in range(1, 101)] with ThreadPoolExecutor(max_workers8) as pool: futures {pool.submit(fetch_one, u): u for u in urls} for fut in as_completed(futures): url, html fut.result() if html: parse_and_save(url, html)as_completed的好处是哪个任务先完成就先处理哪个不用按提交顺序等整体吞吐更高。max_workers8是保守起点实测目标站点能承受再往上调。5.2 并发控制的三个阀门并发不是越大越好要设三个阀门并发数上限同时进行的请求数、速率限制每秒请求数、队列长度待处理任务积压上限。并发数控制同时连接数速率限制控制对目标站点的压力队列长度防止内存被任务对象撑爆。速率限制可以用令牌桶算法实现简单说就是维护一个令牌计数器每秒补充固定数量请求前先取令牌取不到就等。这样能精确控制每秒请求数比单纯sleep更平滑。5.3 异常隔离一个失败不能拖垮全局并发场景下最怕的是单个任务异常导致整个池子卡住。所以每个任务函数内部必须自己捕获异常绝不能让异常冒泡到线程池。另外要设超时防止某个请求卡死占用线程。我见过一个案例某个URL的服务器不响应也不断开线程一直挂着最后整个池子的线程都被占满任务彻底停摆。加了timeout参数后问题解决。6. 登录态维持类项目跨过那道门很多有价值的数据在登录后才能看到这类项目练的是会话管理、Cookie处理、登录流程复现。它比无状态采集复杂一个量级因为多了身份这个维度。6.1 会话维持requests.Session的妙用最基础的登录态维持是用requests.Session()它会自动保存和携带Cookie你登录一次后续请求都带着身份。session requests.Session() # 第一步登录 login_data {username: user, password: pass} session.post(https://example.com/login, datalogin_data, headersheaders) # 第二步后续请求自动带Cookie resp session.get(https://example.com/profile, headersheaders)这里的关键是登录请求的参数格式要和浏览器一致——是表单data还是JSONjson字段名是什么有没有隐藏的csrf token。这些都要从网络面板里对照着看。6.2 验证码与二次验证能绕则绕绕不过就人工验证码是登录类项目绕不开的话题。我的原则是优先找无验证码的登录入口其次用浏览器自动化让用户手动过一次最后才考虑识别方案。图形验证码识别准确率有限滑块验证码逆向成本高很多时候人工过一次拿到Cookie后长期复用反而最省事。Cookie的复用要注意有效期很多站点登录态几天就过期需要重新登录。我的做法是把Cookie持久化到文件脚本启动时先加载请求失败返回登录页时再触发重新登录流程。6.3 登录态失效的检测登录态失效的典型表现是请求返回200但内容是登录页或者被重定向到登录URL。检测方法是在解析前先判断响应里有没有登录页的特征比如请登录字样、登录表单的特定class。发现失效就重新登录而不是傻傻地继续采一堆登录页当数据。7. 动态渲染类项目当数据藏在JS后面有些站点的数据是前端JS渲染出来的你请求HTML拿到的只是个空壳。这类项目练的是浏览器自动化工具主要是Selenium、Playwright这类。它的特点是慢但通用几乎能对付任何页面。7.1 什么时候必须上浏览器判断标准很简单请求回来的HTML里没有目标数据且接口逆向成本过高。比如数据经过复杂加密、签名算法难以复现、或者页面交互逻辑复杂需要点击、滚动才加载。这时候用浏览器自动化让页面自己跑完渲染你再去取渲染后的DOM省心。7.2 等待策略别用固定sleep新手用Selenium最爱写time.sleep(5)然后取元素结果要么等太久浪费时间要么没等够报找不到元素。正确做法是用显式等待等某个元素出现或某个条件成立再继续。from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() driver.get(https://example.com/dynamic) # 等目标元素出现最多等15秒 WebDriverWait(driver, 15).until( EC.presence_of_element_located((By.CSS_SELECTOR, .item-list)) ) items driver.find_elements(By.CSS_SELECTOR, .item-list .item) for it in items: print(it.text) driver.quit()显式等待的好处是元素一出现就继续不用干等固定时间整体速度快很多。presence_of_element_located只等元素存在如果还要等它可点击用element_to_be_clickable。7.3 无头模式与资源拦截生产环境跑浏览器自动化一般开无头模式headless不弹窗口省资源。但要注意有些站点会检测无头特征必要时得伪装。另外可以拦截图片、字体、媒体等无关资源只加载HTML和JS能显著提速。提示浏览器自动化资源占用大能接口逆向就别用它。我一般把它当验证工具——先用它跑通流程确认数据确实存在再评估要不要投入时间做接口逆向。8. 文件资源批量获取与数据清洗入库最后一类项目把前面所有能力串起来批量下载文件资源清洗后入库。它练的是批量任务的健壮性和数据质量意识是最接近真实生产的一类。8.1 大文件下载流式与断点下载大文件不能一次性读进内存要用流式写入。requests的streamTrue配合分块写入是标准做法。def download(url, path): with requests.get(url, headersheaders, streamTrue, timeout30) as r: r.raise_for_status() with open(path, wb) as f: for chunk in r.iter_content(chunk_size8192): if chunk: f.write(chunk)chunk_size8192是经验值太小频繁写盘慢太大占内存。断点续传靠请求头里的Range字段记录已下载字节数下次从该位置继续。不过要注意服务端是否支持Range不支持的话续传会失败。8.2 数据清洗的四个必做动作采回来的原始数据我固定做四件事去空白strip所有字符串字段、类型转换数字、日期转成正确类型、去重按唯一标识、编码统一全部转UTF-8。这四步做完数据质量能提升一大截。import re from datetime import datetime def clean_record(raw): rec {} rec[id] str(raw.get(id, )).strip() rec[title] re.sub(r\s, , raw.get(title, )).strip() # 数字字段转int失败给默认值 try: rec[views] int(raw.get(views, 0)) except (ValueError, TypeError): rec[views] 0 # 日期统一格式 date_str raw.get(publishTime, ) try: rec[publish_time] datetime.fromisoformat(date_str).isoformat() except ValueError: rec[publish_time] None return recre.sub(r\s, , ...)把连续空白压成单个空格比单纯strip更能清理中间的多余空白。类型转换一定要包try因为原始数据里什么脏东西都可能有。8.3 入库批量插入与冲突处理入库用批量插入比逐条插入快一个数量级。以SQLite为例用executemany配合事务。冲突处理用INSERT OR IGNORE重复跳过或INSERT OR REPLACE重复覆盖按业务需求选。def save_batch(conn, records): sql INSERT OR IGNORE INTO items (id, title, views, publish_time) VALUES (?, ?, ?, ?) rows [(r[id], r[title], r[views], r[publish_time]) for r in records] with conn: conn.executemany(sql, rows)with conn:会自动提交事务异常时回滚比手动commit/rollback干净。批量插入时每批控制在几百到一千条太大反而慢。9. 常见问题与排查速查表采集任务跑起来之后问题会以各种面目出现。我把这些年高频遇到的整理成表遇到时先对照排查能省不少时间。现象可能原因排查方向解决思路返回403请求头缺失或被识别对比浏览器请求头补全UA、Referer等返回内容与浏览器不同数据在JS里看网络面板XHR改走接口或浏览器渲染中文乱码编码判断错误打印resp.encoding手动指定或apparent_encoding翻页返回重复数据页码参数失效对比不同页响应加去重判断并终止请求几十次后被限流频率过高看状态码429降频、退避、轮换头并发后大量超时并发过高或网络瓶颈降并发测试调低max_workers登录后仍返回登录页Cookie未携带或失效检查Session和Cookie重新登录并持久化元素找不到页面未渲染完加显式等待用WebDriverWait数据字段缺失页面结构变化对比新旧HTML更新解析规则内存持续增长数据全堆在内存检查是否边采边存改流式处理这张表里我最想强调的是数据字段缺失这一条。页面改版是采集任务的头号杀手而且往往悄无声息——脚本不报错只是采回来的字段变空了。所以长期任务一定要加数据质量监控比如每次采集后统计字段非空率低于阈值就告警。这个习惯帮我提前发现过好几次改版。10. 几个踩坑踩出来的实操心得代码层面的东西网上能搜到但有些经验只有真跑过才知道。挑几个我觉得最有价值的说说。第一个是请求间隔不要设成固定值。固定间隔的请求模式很容易被识别加个随机抖动比如0.5到1.5秒之间随机会自然很多。这个改动很小但实测对降低被限流概率有明显帮助。第二个是日志比print重要得多。新手爱用print调试但长期任务必须用logging因为你需要记录时间、级别、任务标识出问题时才能回溯。我一般把日志同时输出到控制台和文件文件按天切分方便事后查。第三个是永远给任务设上限。不管是最大页数、最大条数还是最大运行时间一定要有兜底。我见过一个脚本因为翻页逻辑bug无限循环跑了一晚上把目标站点请求了几十万次第二天直接被封。加了上限后这类事故就绝迹了。第四个是先小规模验证再全量跑。任何新写的采集逻辑先拿10条数据跑通、人工核对结果正确再放开全量。这个习惯能避免跑了几小时发现解析全错的悲剧。第五个是把配置和代码分离。目标URL、并发数、请求间隔这些参数抽到配置文件里改参数不用动代码。这在维护多个采集任务时尤其省事一套代码配不同配置就能跑不同目标。这8类项目拆下来你会发现它们其实是一套能力的递进从取数到调度到处理从单机到并发从无状态到有状态。真正把它们吃透不是把8份代码都跑一遍而是每类都亲手改一改、调调参数、故意制造点错误看看怎么排查。我自己带新人的时候最看重的不是他能不能跑通而是他遇到报错时能不能说出我怀疑是XX原因打算这样验证。这种判断力才是这些经典项目真正想教给你的东西。