拿捏数据抓取从零开始构建自己的Python爬虫工具箱爬虫这个词很多人一听就觉得门槛高、容易被封、甚至带点灰色但实际做过几个项目之后你会发现它本质上就是一个“自动读取网页公开信息并整理成结构化数据”的程序。我最早接触Python爬虫是因为要帮一个小组调研行业竞品信息几十个页面的公开数据手工复制粘贴实在折磨前后花了一个周末写了第一版爬虫把原本三天的活儿缩成了三秒。从那以后我陆续用爬虫做过新闻聚合、公开数据集采集、商品信息对比也踩过各种花式反爬和编码的坑。这篇指南不教你那种“拿来即用然后被拉黑”的莽夫式写法而是把从入门到进阶的主线捋清楚从HTTP基础讲起到手写一个可用的、对目标站点友好的爬虫再到并发提速和框架选型最后附上一份高频问题排查清单。适合刚学完Python基础、想找真实练手项目的新手也适合已经会写简单爬虫但总卡在细节上的进阶玩家。1. 为什么学爬虫一次真实的需求复盘1.1 爬虫到底解决了什么痛点我们每天都在和网页打交道但绝大多数人只看到了浏览器的渲染结果看不到背后的数据流转。实际上浏览器展示的每一个页面本质上都是一堆HTML、CSS和JavaScript文件的组合。爬虫做的事情就是把浏览器自动“读网页”“提取信息”的这套过程用程序重新实现一遍并把结果整理成你能分析的格式比如CSV、Excel或者数据库表。一个很典型的场景是你想对比几块显卡在不同电商平台上的历史价格走势。手工操作的话你需要每天打开好几个页面记下价格、促销信息、库存状态再手工录入表格。坚持一周人就开始焦虑了坚持一个月基本放弃。而写一个爬虫定时抓取、增量更新、异常重试这些都可以自动化你只需要在一开始确认好采集规则即可。从这个角度看爬虫解决的核心痛点不是“爬”而是“数据获取的重复劳动”。它把“打开网页—定位信息—复制粘贴”这个标准动作变成了一条可重复执行、可监控、可扩展的流水线。这也是为什么数据分析、运营、市场调研这些岗位的人都愿意花时间学一点爬虫——它不是炫技而是实打实提升效率的工具。1.2 什么项目适合作为第一个爬虫起点选对练手项目直接决定你入门的体感。我有几个明确建议首选静态页面、信息结构稳定、没有复杂登录的公开信息站点比如新闻站点的标题列表、政府公开数据页面、图书馆的图书信息页。这类站点页面结构相对规整反爬压力小即使写错了代码影响也有限。不建议一上来就挑战需要登录、有强验证码、核心数据藏在接口里的站点。那种项目会在一开始就抛出HTTP 403、验证码识别、签名参数等一堆问题不仅打击信心还会让你误以为爬虫很难。讲实话第一版成功的爬虫越简单越好目标就是让代码跑通、结果落盘哪怕只抓到20条数据。我当时选的练手目标是一个本地新闻门户的公告列表。页面是后端渲染的列表结构十几行HTML就能看明白不需要执行JavaScript也没有反爬策略。整个过程只涉及四个环节构造请求、解析HTML、翻页、存数据把爬虫主流程体验一遍后面再学什么都有基础框架可以对照。2. 核心知识前置HTTP与页面解析2.1 请求与响应模型是地基不管你用requests、httpx还是Scrapy本质都是发起一个HTTP请求然后拿到服务器返回的响应。HTTP本身不神秘你可以把它理解成餐厅点餐客户端把需求写在一张单子上请求头、请求方法、URL后厨根据单子做出菜响应状态码、响应头、响应体端上来之后你才知道今天这个菜合不合胃口。状态码是需要第一时间熟悉的语言。2xx表示成功最常见的200就是一切正常301和302是重定向意味着你要访问的地址已经搬了家requests默认会帮你跟随403是服务器明说不想搭理你这个时候就不要再怼了先检查请求头是否缺少必要的浏览器标识404是目标路径不存在500系列则是服务器内部出问题可以稍后重试。有个点新手容易忽略requests.get()返回的response对象里除了.text文本内容还有.status_code状态码、.headers响应头、.encoding编码方式、.url最终地址。排查问题的时候第一步永远是把它打印出来看看。我见过太多人一报错就去看解析逻辑结果问题明明出在请求阶段。2.2 页面解析的三条路线怎么选拿到HTML之后下一步就是从中提取目标信息。这一步有三条主流路线正则表达式速度快、依赖零但可读性差写复杂的匹配规则容易把自己绕晕适合结构简单且一眼能看出模式的字段。BeautifulSoup入门友好支持CSS选择器写起来像在写自然语言最适合新手建立“解析”的心智模型。lxml底层用C实现解析速度最快XPath表达式非常灵活适合处理结构有规律但体积较大的页面。大多数个人项目BeautifulSoup加lxml解析器已经绰绰有余。如果你做的是需要高吞吐的生产级采集任务那直接考虑lxml的XPath会更快。但注意一点不要一上来就想用Selenium模拟浏览器。无头浏览器意味着更高的资源占用、更慢的加载速度而且现在很多站点的反爬恰恰会重点盯防自动化浏览器特征。只有当页面数据完全靠JavaScript动态渲染、接口请求又极难构造的时候才值得动用这最后一招。2.3 Session会话与Cookies管理很多网站会用Cookie记录你的浏览状态比如登录态、偏好设置、访问足迹。早期写爬虫最容易犯的错就是每请求一次就创建一个新的请求对象结果服务器每次看到你都是“陌生人”频繁要求重新登录或者弹出验证。正确做法是使用requests.Session()创建一个会话对象让它自动帮你管理Cookie。代码上的差别就是import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 }) resp session.get(https://example.com/page)第一次请求返回的Cookie会被session记住下一次请求自动带上。这个机制不仅能让你“看起来像个连续的浏览者”也是后面处理登录流程的基础。这里插一句关于请求头的良心建议User-Agent是服务器识别客户端的核心字段之一。很多站点对新版本浏览器的请求会更友好所以顺手写一个常见的浏览器UA而不是用Python默认的UA能减少相当一部分“你好你是爬虫”的误会。这属于正常的技术规范不是对抗手段。3. 从零写一个可用的爬虫程序3.1 动手前检查三件事写第一行代码前先花10分钟做三个检查第一目标站点是否有明显的Robots协议说明。我习惯先访问目标域名下的/robots.txt看一眼哪些路径允许抓取、哪些禁止。这不是形式主义是基本的职业素养也是保护自己不在后续沟通中陷入被动的第一步。第二确认页面是服务端渲染还是客户端渲染。最简单的验证办法是用浏览器的“查看源代码”功能看看目标数据是否直接出现在HTML源码里。如果源码里能看到完整数据恭喜你解析难度低一大截。第三明确采集范围和数据字段。把要提取的字段写下来比如新闻标题、发布时间、链接、摘要不要在写代码的过程中才临时想那样容易越写越乱。3.2 第一版代码从单页开始跑通假设我们要采集一个虚构新闻站点的列表页地址是https://news.example.com/list每条新闻是一个div classnews-item里面有标题、链接、日期。第一版代码越朴素越好import requests from bs4 import BeautifulSoup url https://news.example.com/list headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding # 自动嗅探编码 soup BeautifulSoup(resp.text, lxml) items soup.select(div.news-item) for item in items: title_node item.select_one(h2 a) if not title_node: continue title title_node.get_text(stripTrue) link title_node.get(href) date_node item.select_one(span.date) date date_node.get_text(stripTrue) if date_node else print(title, link, date)这段代码有几个细节值得说。timeout10是必须写的否则遇到响应慢的站点程序会无限期卡死。raise_for_status()会把4xx和5xx直接变成异常让你第一时间知道请求出了问题。设置编码那一步是因为有些老站点的页面没有声明字符集用Python默认的UTF-8去解析会得到一堆乱码apparent_encoding是requests基于内容猜测的编码大多数中文页面用它都能正确显示。3.3 翻页逻辑与数据清洗列表页跑通后下一步把“翻页”这个动作自动化。常见的翻页方式有三种URL里带页码参数比如/list?page2URL路径含页码比如/list/2通过点击按钮触发JavaScript加载这种不能靠改URL解决。对前两种翻页逻辑只需要一个循环for page in range(1, 11): page_url fhttps://news.example.com/list?page{page} # 复用上面的请求和解析逻辑 ...你会遇到的第一个陷阱是“第一页和其他页的URL结构不一样”很多站点第一页是/list第二页才是/list?page2循环里要单独处理一下。第二个陷阱是“尾页判断”不要想当然地认为一定能跑到第10页有的站点翻到最后一页时会返回空列表这时候要及时终止循环而不是继续发起无意义的请求。数据清洗这个环节很多人会跳过直接存原始字符串。我的建议是至少做三件事strip()去掉首尾空格、空字段设置默认值、链接补全为绝对路径。链接补全可以借助urllib.parse.urljoinfrom urllib.parse import urljoin full_url urljoin(page_url, link)这一步看似简单作用很大。很多页面里的链接是相对的比如/article/123.html如果不加域名存储下来的数据就没有使用价值。3.4 数据落盘CSV、Excel还是数据库数据清洗完就要落盘。我个人的选择标准很简单数据量小、结构固定、想用Excel打开就存CSV数据量中等、需要多表关联或者条件查询就上SQLite数据量大、需要并发写入再考虑MySQL或PostgreSQL。CSV是最轻量的方案Python标准库的csv模块就能搞定import csv with open(news.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([标题, 链接, 日期]) for item in items: writer.writerow([item[title], item[link], item[date]])注意两件事一是文件打开模式要加newline否则在Windows下每条记录之间会多一个空行二是编码要用utf-8-sig而不是utf-8这样生成的CSV用Excel打开时中文才不会乱码。4. 反爬机制与合规边界4.1 常见反爬手段与它们背后的意图我刚入门的时候一度以为反爬是网站故意给程序员添堵后来自己做站点管理才明白反爬的本质是保护服务器资源和服务稳定性。理解这一点你就知道怎么用“让人家放心”的方式采集。最常见的反爬有五类第一类请求头校验。服务器检查User-Agent、Referer、Accept等字段判断请求是否来自真实浏览器。第二类请求频率限制。同一IP在短时间内发出大量请求直接触发封禁。第三类登录态校验。关键数据要求登录后才能看到未登录状态只能看到诱导页。第四类页面混淆。把数据藏在JavaScript变量里或者用CSS偏移的方式扰乱文字顺序提高解析成本。第五类验证码。当服务器无法判断你是人还是程序时会抛出验证码作为最后防线。看到这些机制你要记住一个原则反爬不是“敌人”它是一套规则。你需要在规则允许的范围内采集。4.2 合理的应对策略对待反爬分三个层次思考。第一层把请求姿态调成“仿人模式”。用真实的浏览器UA、带上必要的请求头、两次请求之间加1到2秒的随机延时、避开业务高峰时段。注意这里的延时必须有随机性固定间隔反而更适合被规律识别。很多框架如Scrapy自带下载延时配置自己写的话就用time.sleep(random.uniform(1, 3))。第二层适度使用会话保持。用Session对象维持Cookie避免每次请求都被当成新用户。如果目标站点要求登录后可见优先程序化实现登录流程拿到登录态之后再采集。这里的核心是“你登录了然后请求你自己的账号能看到的数据”这在许多场景下是合规的。第三层承认边界。遇到验证码或者强风控正确的做法是停下来评估是否有官方API、数据集或其他合法渠道可以获取数据。强行绕过验证码不仅技术上成本极高而且行为性质已经发生了变化属于对抗性操作风险也随之上升。4.3 法律红线与职业习惯这部分我必须说清楚因为它比任何代码技巧都重要。爬虫的合规底线大致可以概括为三条采集内容限定在公开数据范围内不碰需要登录才能访问的私密信息采集行为不破坏目标站点的正常服务不构成对服务器资源的恶意占用采集所得数据的用途不涉及商业贩卖、隐私侵犯等不正当行为。Robots协议虽然不等同于法律条文但它是网站所有者表达意愿的窗口。《民法典》和《反不正当竞争法》对于数据权益的讨论核心都围绕着“公开”与“合理使用”的边界展开。我自己的执行标准是先看Robots协议再评估数据是否公开可见最后确认用途正当。这三条都过了动手不迟有一条模糊就先缓一缓。另外养成两个职业习惯代码里写上采集来源和采集日期方便追溯定时清理不再使用的采集脚本和数据不给服务器增加无谓负担。这些细节看着不起眼出问题的时候能帮你少走很多弯路。5. 进阶路线并发、框架与工程化5.1 什么时候该上并发单线程爬虫写起来简单但速度确实慢。假设一个页面请求耗时0.5秒采集1000个页面就需要500秒超过8分钟。如果你要采集的是几万甚至几十万条数据单线程就跑不动了。提高采集效率有两个主流手段线程池和异步协程。线程池用concurrent.futures.ThreadPoolExecutor实现思路是开启固定数量的线程并发发请求代码改动最小适合以requests为代表的同步库from concurrent.futures import ThreadPoolExecutor, as_completed urls [https://news.example.com/list?page{}.format(i) for i in range(1, 51)] def fetch(url): resp requests.get(url, headersheaders, timeout10) return resp.text with ThreadPoolExecutor(max_workers5) as pool: futures [pool.submit(fetch, url) for url in urls] for future in as_completed(futures): html future.result() # 解析并存库线程数不是越大越好。开50个线程同时打一个站点服务器不封你才怪一般个人电脑加上礼貌采集5到10个线程已经够用。协程则更适合IO密集型任务用httpx配合asyncio可以做到真正的异步IO但理解和调试成本更高建议先把线程池用熟再碰。5.2 Scrapy框架到底省了哪些事当你需要维护的采集任务越来越多重复造的轮子就越来越多。Scrapy的价值不在于爬得快而在于帮你想好了工程化问题请求调度、去重、并发控制、下载延时、日志系统、中间件、管道存储这些都有现成的组件。对比一下就很直观纯requests方案里你要自己管理URL队列、自己去重、自己写重试机制、自己控制并发Scrapy里这些是框架内置能力。中间件还能统一处理请求头轮换、状态码检查、异常重试管道可以定义数据清洗和存储策略。如果你的项目涉及大量页面、规则复杂、需要长期维护直接上Scrapy是省心的选择。但我不建议新手一上来就用框架。原因很简单框架封装太多出了问题你连排查方向都找不到。用requests手写过全流程理解了请求、解析、清洗、存储、调度每一步的细节再用Scrapy你会瞬间明白每个配置项背后的设计意图。5.3 监控、重试与日志是最后一个短板爬虫程序跑在后台最怕的就是“静默失败”。你设置的定时任务半夜三点运行某个页面结构改了导致解析结果为空早上起来看数据发现抓回来一堆空记录。应对办法是建立三个基本防线。第一个是日志把请求的URL、状态码、异常信息、解析结果条数都记录下来用标准库logging就能做到至少确保出问题时能回溯。第二个是重试对超时和5xx错误采用指数退避策略重试比如第一次等1秒、第二次等2秒、第三次等4秒最多重试3次。第三个是结果校验每次采集完统计条数如果条数明显偏离历史均值就发个邮件或者推送通知让你第一时间知道需要人工介入。这个习惯从第一个正式项目就要养成。前期多写一行日志后期可能帮你省下好几个小时的排查时间。6. 常见问题排查速查表6.1 高频报错与解决方案我整理了一份自己常用的问题对照表每行都是真实踩过的坑。报错信息常见原因处理办法requests.exceptions.ConnectTimeout目标站点响应过慢增大timeout参数排查本地网络确认站点是否可访问requests.exceptions.SSLError目标站点证书异常或不匹配优先更新证书仅在受信任测试环境用verifyFalse并关闭警告UnicodeDecodeError/ 中文乱码页面编码识别错误使用resp.apparent_encoding或指定页面声明的编码AttributeError: NoneType解析时选中的元素不存在先打印一段HTML检查结构用if node:保护空值HTTP 403 Forbidden服务器拒绝了请求检查UA、Referer等请求头降低请求频率确认是否命中反爬HTTP 429 Too Many Requests请求过于频繁立即停止增加延时等待一段时间后再恢复解析结果为空但浏览器正常数据由JavaScript动态渲染查看页面源码确认尝试寻找接口最后才考虑浏览器渲染方案TypeError: GET() got unexpected keyword argumentrequests版本库调用方式有误确认是否被本地自定义同名模块干扰检查导入路径这里面最隐蔽的是最后一个本地有个叫requests.py的文件导致import requests导入的其实是自己写的文件代码直接报错。遇到怪异的报错先检查文件命名和导入路径往往能少走很多弯路。6.2 独家避坑技巧这里分享几个一般文档里不会写、但实战中帮过我大忙的技巧。第一善用浏览器的开发者工具但要看对地方。大众习惯点“查看源代码”但排查请求问题要去看“网络”面板里面能看到页面发起的每一个请求包括接口地址、请求头、响应内容。很多你以为要前端渲染才能拿到的数据其实只是一个接口返回JSON构造请求直连接口比解析HTML高效得多。第二字段解析时不要只用一条CSS选择器。页面改版是常态今天管用的div.news-item h2 a明天可能就变成了article h2 a。我在代码里习惯写一个获取字段的小函数内部尝试多种选择器命中一个就返回这样页面结构微调时不会立刻全盘失败def get_title(item): for selector in [h2 a, .title a, h3 a]: node item.select_one(selector) if node: return node.get_text(stripTrue) return 第三控制全局请求总量。我给自己的采集任务定过一个朴素规则任何情况下单台机器对同一个域名的请求QPS不超过3。这个数字听着保守但确实是“能用且不会给服务器添麻烦”的平衡点。数据是分批慢慢积累的没必要把一次采集当成比赛。第四定期清理数据存储和日志文件。爬虫跑久了CSV会越来越大日志里的调试信息也会堆积。我习惯在程序启动时做一次日志切割并按月归档旧数据让工作目录保持干净。结尾一点个人体会爬虫写多了之后我最深的感触是代码能力只占五成另外五成靠的是对目标站点的理解和对数据质量的敏感度。同样一个页面有人写出来的爬虫跑三天就崩有人能稳定跑半年区别往往不在解析技巧而在请求频率的设计、异常处理是否完备、数据清洗是否细致。我现在的习惯是新项目先花半小时手工浏览目标站点看看它的页面结构、翻页方式、可能的边界情况再动手写代码。这一步几乎决定后面是否顺遂。还有一点想说的是爬虫的价值从来不在于你能“绕过”多少限制而在于你能从公开信息中整理出多少有价值的认知。把底层工具用熟尊重规则保持敬畏你的数据之路会走得比大多数人更长更稳。如果这篇指南里的某个技巧帮你省下了半天时间那就是它最大的意义。
拿捏数据抓取从零开始构建自己的Python爬虫工具箱爬虫这个词很多人一听就觉得门槛高、容易被封、甚至带点灰色但实际做过几个项目之后你会发现它本质上就是一个“自动读取网页公开信息并整理成结构化数据”的程序。我最早接触Python爬虫是因为要帮一个小组调研行业竞品信息几十个页面的公开数据手工复制粘贴实在折磨前后花了一个周末写了第一版爬虫把原本三天的活儿缩成了三秒。从那以后我陆续用爬虫做过新闻聚合、公开数据集采集、商品信息对比也踩过各种花式反爬和编码的坑。这篇指南不教你那种“拿来即用然后被拉黑”的莽夫式写法而是把从入门到进阶的主线捋清楚从HTTP基础讲起到手写一个可用的、对目标站点友好的爬虫再到并发提速和框架选型最后附上一份高频问题排查清单。适合刚学完Python基础、想找真实练手项目的新手也适合已经会写简单爬虫但总卡在细节上的进阶玩家。1. 为什么学爬虫一次真实的需求复盘1.1 爬虫到底解决了什么痛点我们每天都在和网页打交道但绝大多数人只看到了浏览器的渲染结果看不到背后的数据流转。实际上浏览器展示的每一个页面本质上都是一堆HTML、CSS和JavaScript文件的组合。爬虫做的事情就是把浏览器自动“读网页”“提取信息”的这套过程用程序重新实现一遍并把结果整理成你能分析的格式比如CSV、Excel或者数据库表。一个很典型的场景是你想对比几块显卡在不同电商平台上的历史价格走势。手工操作的话你需要每天打开好几个页面记下价格、促销信息、库存状态再手工录入表格。坚持一周人就开始焦虑了坚持一个月基本放弃。而写一个爬虫定时抓取、增量更新、异常重试这些都可以自动化你只需要在一开始确认好采集规则即可。从这个角度看爬虫解决的核心痛点不是“爬”而是“数据获取的重复劳动”。它把“打开网页—定位信息—复制粘贴”这个标准动作变成了一条可重复执行、可监控、可扩展的流水线。这也是为什么数据分析、运营、市场调研这些岗位的人都愿意花时间学一点爬虫——它不是炫技而是实打实提升效率的工具。1.2 什么项目适合作为第一个爬虫起点选对练手项目直接决定你入门的体感。我有几个明确建议首选静态页面、信息结构稳定、没有复杂登录的公开信息站点比如新闻站点的标题列表、政府公开数据页面、图书馆的图书信息页。这类站点页面结构相对规整反爬压力小即使写错了代码影响也有限。不建议一上来就挑战需要登录、有强验证码、核心数据藏在接口里的站点。那种项目会在一开始就抛出HTTP 403、验证码识别、签名参数等一堆问题不仅打击信心还会让你误以为爬虫很难。讲实话第一版成功的爬虫越简单越好目标就是让代码跑通、结果落盘哪怕只抓到20条数据。我当时选的练手目标是一个本地新闻门户的公告列表。页面是后端渲染的列表结构十几行HTML就能看明白不需要执行JavaScript也没有反爬策略。整个过程只涉及四个环节构造请求、解析HTML、翻页、存数据把爬虫主流程体验一遍后面再学什么都有基础框架可以对照。2. 核心知识前置HTTP与页面解析2.1 请求与响应模型是地基不管你用requests、httpx还是Scrapy本质都是发起一个HTTP请求然后拿到服务器返回的响应。HTTP本身不神秘你可以把它理解成餐厅点餐客户端把需求写在一张单子上请求头、请求方法、URL后厨根据单子做出菜响应状态码、响应头、响应体端上来之后你才知道今天这个菜合不合胃口。状态码是需要第一时间熟悉的语言。2xx表示成功最常见的200就是一切正常301和302是重定向意味着你要访问的地址已经搬了家requests默认会帮你跟随403是服务器明说不想搭理你这个时候就不要再怼了先检查请求头是否缺少必要的浏览器标识404是目标路径不存在500系列则是服务器内部出问题可以稍后重试。有个点新手容易忽略requests.get()返回的response对象里除了.text文本内容还有.status_code状态码、.headers响应头、.encoding编码方式、.url最终地址。排查问题的时候第一步永远是把它打印出来看看。我见过太多人一报错就去看解析逻辑结果问题明明出在请求阶段。2.2 页面解析的三条路线怎么选拿到HTML之后下一步就是从中提取目标信息。这一步有三条主流路线正则表达式速度快、依赖零但可读性差写复杂的匹配规则容易把自己绕晕适合结构简单且一眼能看出模式的字段。BeautifulSoup入门友好支持CSS选择器写起来像在写自然语言最适合新手建立“解析”的心智模型。lxml底层用C实现解析速度最快XPath表达式非常灵活适合处理结构有规律但体积较大的页面。大多数个人项目BeautifulSoup加lxml解析器已经绰绰有余。如果你做的是需要高吞吐的生产级采集任务那直接考虑lxml的XPath会更快。但注意一点不要一上来就想用Selenium模拟浏览器。无头浏览器意味着更高的资源占用、更慢的加载速度而且现在很多站点的反爬恰恰会重点盯防自动化浏览器特征。只有当页面数据完全靠JavaScript动态渲染、接口请求又极难构造的时候才值得动用这最后一招。2.3 Session会话与Cookies管理很多网站会用Cookie记录你的浏览状态比如登录态、偏好设置、访问足迹。早期写爬虫最容易犯的错就是每请求一次就创建一个新的请求对象结果服务器每次看到你都是“陌生人”频繁要求重新登录或者弹出验证。正确做法是使用requests.Session()创建一个会话对象让它自动帮你管理Cookie。代码上的差别就是import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 }) resp session.get(https://example.com/page)第一次请求返回的Cookie会被session记住下一次请求自动带上。这个机制不仅能让你“看起来像个连续的浏览者”也是后面处理登录流程的基础。这里插一句关于请求头的良心建议User-Agent是服务器识别客户端的核心字段之一。很多站点对新版本浏览器的请求会更友好所以顺手写一个常见的浏览器UA而不是用Python默认的UA能减少相当一部分“你好你是爬虫”的误会。这属于正常的技术规范不是对抗手段。3. 从零写一个可用的爬虫程序3.1 动手前检查三件事写第一行代码前先花10分钟做三个检查第一目标站点是否有明显的Robots协议说明。我习惯先访问目标域名下的/robots.txt看一眼哪些路径允许抓取、哪些禁止。这不是形式主义是基本的职业素养也是保护自己不在后续沟通中陷入被动的第一步。第二确认页面是服务端渲染还是客户端渲染。最简单的验证办法是用浏览器的“查看源代码”功能看看目标数据是否直接出现在HTML源码里。如果源码里能看到完整数据恭喜你解析难度低一大截。第三明确采集范围和数据字段。把要提取的字段写下来比如新闻标题、发布时间、链接、摘要不要在写代码的过程中才临时想那样容易越写越乱。3.2 第一版代码从单页开始跑通假设我们要采集一个虚构新闻站点的列表页地址是https://news.example.com/list每条新闻是一个div classnews-item里面有标题、链接、日期。第一版代码越朴素越好import requests from bs4 import BeautifulSoup url https://news.example.com/list headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 } resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding # 自动嗅探编码 soup BeautifulSoup(resp.text, lxml) items soup.select(div.news-item) for item in items: title_node item.select_one(h2 a) if not title_node: continue title title_node.get_text(stripTrue) link title_node.get(href) date_node item.select_one(span.date) date date_node.get_text(stripTrue) if date_node else print(title, link, date)这段代码有几个细节值得说。timeout10是必须写的否则遇到响应慢的站点程序会无限期卡死。raise_for_status()会把4xx和5xx直接变成异常让你第一时间知道请求出了问题。设置编码那一步是因为有些老站点的页面没有声明字符集用Python默认的UTF-8去解析会得到一堆乱码apparent_encoding是requests基于内容猜测的编码大多数中文页面用它都能正确显示。3.3 翻页逻辑与数据清洗列表页跑通后下一步把“翻页”这个动作自动化。常见的翻页方式有三种URL里带页码参数比如/list?page2URL路径含页码比如/list/2通过点击按钮触发JavaScript加载这种不能靠改URL解决。对前两种翻页逻辑只需要一个循环for page in range(1, 11): page_url fhttps://news.example.com/list?page{page} # 复用上面的请求和解析逻辑 ...你会遇到的第一个陷阱是“第一页和其他页的URL结构不一样”很多站点第一页是/list第二页才是/list?page2循环里要单独处理一下。第二个陷阱是“尾页判断”不要想当然地认为一定能跑到第10页有的站点翻到最后一页时会返回空列表这时候要及时终止循环而不是继续发起无意义的请求。数据清洗这个环节很多人会跳过直接存原始字符串。我的建议是至少做三件事strip()去掉首尾空格、空字段设置默认值、链接补全为绝对路径。链接补全可以借助urllib.parse.urljoinfrom urllib.parse import urljoin full_url urljoin(page_url, link)这一步看似简单作用很大。很多页面里的链接是相对的比如/article/123.html如果不加域名存储下来的数据就没有使用价值。3.4 数据落盘CSV、Excel还是数据库数据清洗完就要落盘。我个人的选择标准很简单数据量小、结构固定、想用Excel打开就存CSV数据量中等、需要多表关联或者条件查询就上SQLite数据量大、需要并发写入再考虑MySQL或PostgreSQL。CSV是最轻量的方案Python标准库的csv模块就能搞定import csv with open(news.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([标题, 链接, 日期]) for item in items: writer.writerow([item[title], item[link], item[date]])注意两件事一是文件打开模式要加newline否则在Windows下每条记录之间会多一个空行二是编码要用utf-8-sig而不是utf-8这样生成的CSV用Excel打开时中文才不会乱码。4. 反爬机制与合规边界4.1 常见反爬手段与它们背后的意图我刚入门的时候一度以为反爬是网站故意给程序员添堵后来自己做站点管理才明白反爬的本质是保护服务器资源和服务稳定性。理解这一点你就知道怎么用“让人家放心”的方式采集。最常见的反爬有五类第一类请求头校验。服务器检查User-Agent、Referer、Accept等字段判断请求是否来自真实浏览器。第二类请求频率限制。同一IP在短时间内发出大量请求直接触发封禁。第三类登录态校验。关键数据要求登录后才能看到未登录状态只能看到诱导页。第四类页面混淆。把数据藏在JavaScript变量里或者用CSS偏移的方式扰乱文字顺序提高解析成本。第五类验证码。当服务器无法判断你是人还是程序时会抛出验证码作为最后防线。看到这些机制你要记住一个原则反爬不是“敌人”它是一套规则。你需要在规则允许的范围内采集。4.2 合理的应对策略对待反爬分三个层次思考。第一层把请求姿态调成“仿人模式”。用真实的浏览器UA、带上必要的请求头、两次请求之间加1到2秒的随机延时、避开业务高峰时段。注意这里的延时必须有随机性固定间隔反而更适合被规律识别。很多框架如Scrapy自带下载延时配置自己写的话就用time.sleep(random.uniform(1, 3))。第二层适度使用会话保持。用Session对象维持Cookie避免每次请求都被当成新用户。如果目标站点要求登录后可见优先程序化实现登录流程拿到登录态之后再采集。这里的核心是“你登录了然后请求你自己的账号能看到的数据”这在许多场景下是合规的。第三层承认边界。遇到验证码或者强风控正确的做法是停下来评估是否有官方API、数据集或其他合法渠道可以获取数据。强行绕过验证码不仅技术上成本极高而且行为性质已经发生了变化属于对抗性操作风险也随之上升。4.3 法律红线与职业习惯这部分我必须说清楚因为它比任何代码技巧都重要。爬虫的合规底线大致可以概括为三条采集内容限定在公开数据范围内不碰需要登录才能访问的私密信息采集行为不破坏目标站点的正常服务不构成对服务器资源的恶意占用采集所得数据的用途不涉及商业贩卖、隐私侵犯等不正当行为。Robots协议虽然不等同于法律条文但它是网站所有者表达意愿的窗口。《民法典》和《反不正当竞争法》对于数据权益的讨论核心都围绕着“公开”与“合理使用”的边界展开。我自己的执行标准是先看Robots协议再评估数据是否公开可见最后确认用途正当。这三条都过了动手不迟有一条模糊就先缓一缓。另外养成两个职业习惯代码里写上采集来源和采集日期方便追溯定时清理不再使用的采集脚本和数据不给服务器增加无谓负担。这些细节看着不起眼出问题的时候能帮你少走很多弯路。5. 进阶路线并发、框架与工程化5.1 什么时候该上并发单线程爬虫写起来简单但速度确实慢。假设一个页面请求耗时0.5秒采集1000个页面就需要500秒超过8分钟。如果你要采集的是几万甚至几十万条数据单线程就跑不动了。提高采集效率有两个主流手段线程池和异步协程。线程池用concurrent.futures.ThreadPoolExecutor实现思路是开启固定数量的线程并发发请求代码改动最小适合以requests为代表的同步库from concurrent.futures import ThreadPoolExecutor, as_completed urls [https://news.example.com/list?page{}.format(i) for i in range(1, 51)] def fetch(url): resp requests.get(url, headersheaders, timeout10) return resp.text with ThreadPoolExecutor(max_workers5) as pool: futures [pool.submit(fetch, url) for url in urls] for future in as_completed(futures): html future.result() # 解析并存库线程数不是越大越好。开50个线程同时打一个站点服务器不封你才怪一般个人电脑加上礼貌采集5到10个线程已经够用。协程则更适合IO密集型任务用httpx配合asyncio可以做到真正的异步IO但理解和调试成本更高建议先把线程池用熟再碰。5.2 Scrapy框架到底省了哪些事当你需要维护的采集任务越来越多重复造的轮子就越来越多。Scrapy的价值不在于爬得快而在于帮你想好了工程化问题请求调度、去重、并发控制、下载延时、日志系统、中间件、管道存储这些都有现成的组件。对比一下就很直观纯requests方案里你要自己管理URL队列、自己去重、自己写重试机制、自己控制并发Scrapy里这些是框架内置能力。中间件还能统一处理请求头轮换、状态码检查、异常重试管道可以定义数据清洗和存储策略。如果你的项目涉及大量页面、规则复杂、需要长期维护直接上Scrapy是省心的选择。但我不建议新手一上来就用框架。原因很简单框架封装太多出了问题你连排查方向都找不到。用requests手写过全流程理解了请求、解析、清洗、存储、调度每一步的细节再用Scrapy你会瞬间明白每个配置项背后的设计意图。5.3 监控、重试与日志是最后一个短板爬虫程序跑在后台最怕的就是“静默失败”。你设置的定时任务半夜三点运行某个页面结构改了导致解析结果为空早上起来看数据发现抓回来一堆空记录。应对办法是建立三个基本防线。第一个是日志把请求的URL、状态码、异常信息、解析结果条数都记录下来用标准库logging就能做到至少确保出问题时能回溯。第二个是重试对超时和5xx错误采用指数退避策略重试比如第一次等1秒、第二次等2秒、第三次等4秒最多重试3次。第三个是结果校验每次采集完统计条数如果条数明显偏离历史均值就发个邮件或者推送通知让你第一时间知道需要人工介入。这个习惯从第一个正式项目就要养成。前期多写一行日志后期可能帮你省下好几个小时的排查时间。6. 常见问题排查速查表6.1 高频报错与解决方案我整理了一份自己常用的问题对照表每行都是真实踩过的坑。报错信息常见原因处理办法requests.exceptions.ConnectTimeout目标站点响应过慢增大timeout参数排查本地网络确认站点是否可访问requests.exceptions.SSLError目标站点证书异常或不匹配优先更新证书仅在受信任测试环境用verifyFalse并关闭警告UnicodeDecodeError/ 中文乱码页面编码识别错误使用resp.apparent_encoding或指定页面声明的编码AttributeError: NoneType解析时选中的元素不存在先打印一段HTML检查结构用if node:保护空值HTTP 403 Forbidden服务器拒绝了请求检查UA、Referer等请求头降低请求频率确认是否命中反爬HTTP 429 Too Many Requests请求过于频繁立即停止增加延时等待一段时间后再恢复解析结果为空但浏览器正常数据由JavaScript动态渲染查看页面源码确认尝试寻找接口最后才考虑浏览器渲染方案TypeError: GET() got unexpected keyword argumentrequests版本库调用方式有误确认是否被本地自定义同名模块干扰检查导入路径这里面最隐蔽的是最后一个本地有个叫requests.py的文件导致import requests导入的其实是自己写的文件代码直接报错。遇到怪异的报错先检查文件命名和导入路径往往能少走很多弯路。6.2 独家避坑技巧这里分享几个一般文档里不会写、但实战中帮过我大忙的技巧。第一善用浏览器的开发者工具但要看对地方。大众习惯点“查看源代码”但排查请求问题要去看“网络”面板里面能看到页面发起的每一个请求包括接口地址、请求头、响应内容。很多你以为要前端渲染才能拿到的数据其实只是一个接口返回JSON构造请求直连接口比解析HTML高效得多。第二字段解析时不要只用一条CSS选择器。页面改版是常态今天管用的div.news-item h2 a明天可能就变成了article h2 a。我在代码里习惯写一个获取字段的小函数内部尝试多种选择器命中一个就返回这样页面结构微调时不会立刻全盘失败def get_title(item): for selector in [h2 a, .title a, h3 a]: node item.select_one(selector) if node: return node.get_text(stripTrue) return 第三控制全局请求总量。我给自己的采集任务定过一个朴素规则任何情况下单台机器对同一个域名的请求QPS不超过3。这个数字听着保守但确实是“能用且不会给服务器添麻烦”的平衡点。数据是分批慢慢积累的没必要把一次采集当成比赛。第四定期清理数据存储和日志文件。爬虫跑久了CSV会越来越大日志里的调试信息也会堆积。我习惯在程序启动时做一次日志切割并按月归档旧数据让工作目录保持干净。结尾一点个人体会爬虫写多了之后我最深的感触是代码能力只占五成另外五成靠的是对目标站点的理解和对数据质量的敏感度。同样一个页面有人写出来的爬虫跑三天就崩有人能稳定跑半年区别往往不在解析技巧而在请求频率的设计、异常处理是否完备、数据清洗是否细致。我现在的习惯是新项目先花半小时手工浏览目标站点看看它的页面结构、翻页方式、可能的边界情况再动手写代码。这一步几乎决定后面是否顺遂。还有一点想说的是爬虫的价值从来不在于你能“绕过”多少限制而在于你能从公开信息中整理出多少有价值的认知。把底层工具用熟尊重规则保持敬畏你的数据之路会走得比大多数人更长更稳。如果这篇指南里的某个技巧帮你省下了半天时间那就是它最大的意义。
