有一次，一个刚开始学 Python 的朋友给我发来一段代码，说“我照着教程爬了一个网站，但是换了一个网站就不知道从哪里改了”。他电脑里存了二十多份爬虫源码，有从视频里抄的，有从文章里复制的，还有从各种案例合集里下载的。但真正轮到自己面对一个新页面时，依然卡在第一步：不知道这段数据到底该用哪种方式拿。
这个问题我在很多初学者身上见过。不是因为语法没学会，也不是因为工具不熟，而是因为学的都是“某一条代码”，不是“一类问题的解法”。所以当我看到类似“18个Python爬虫实战案例，附源码，适合小白入门”的教程时，我反而觉得这种形式比单独的语法教程更有价值——前提是你知道该怎么用它。
单独看，这个合集好像是教人爬18个网站；往深一层看，它其实是在反复训练一套流程：分析页面、发起请求、解析数据、保存结果。这才是零基础学爬虫最需要的东西。
1. 先搞清楚这套实战案例真正在训练什么
很多初学者误解了“实战案例”的价值。他们认为“实战”就是“把真实网站跑通”，跑通一个就算学会一个。但实际上，18个案例的价值不在那18个网站本身，而是案例背后反复出现的同一套处理流程。
1.1 爬虫的核心不是代码，是流程
任何一次爬取任务，无论目标网站多复杂，都可以拆成四步：
- 分析目标：先判断内容是静态 HTML、接口返回的 JSON，还是 JavaScript 动态渲染出来的。
- 发起请求：用合适的库和参数把数据拿到本地。
- 解析提取：从 HTML、JSON 或其他格式中取出你要的字段。
- 保存使用：把结果写到 CSV、Excel、数据库，或者直接打印出来。
这四步每一步都有很多细节，但对于入门者，重要的是先形成这样一个框架。有了框架，你看到一个新网站时就知道自己卡在哪一步，知道该去查什么样的资料。
1.2 批量型、增量型、垂直型：三种场景，三种策略
从这类案例的常见分类来看，爬虫大致能分成三种应用场景：
- 批量型爬虫：从某个列表页出发，按分页把全站或某类数据抓下来。适合新闻、商品、文章列表这类结构固定的场景。
- 增量型爬虫：只抓新增或变化的数据，避免重复请求。适合持续更新数据的场景，比如监控价格、关注新帖。
- 垂直型爬虫：针对某一特定行业或特定网站定制的爬虫，规则强、通用性低，但准确率高。比如只抓某个平台的商品评论。
学习阶段，你不需要把这三种完全分开。但你应该知道，同一个网站，如果只是想抓一份数据，用批量型最简单；如果以后想长期监控，就必须考虑增量逻辑。18个案例里通常一次性抓取的居多，这没问题，关键是理解“每次全量抓”和“只抓新增”在工程实现上差在哪里。
2. 所有案例背后都离不开的四个基础能力
无论案例是爬电影榜单、商品价格还是新闻资讯，真正反复用到的核心工具就那几个。
2.1 请求库：requests 是入门首选
最常见的写法是这样的：
import requests url = "https://example.com/list" headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" } resp = requests.get(url, headers=headers, timeout=10) resp.encoding = resp.apparent_encoding print(resp.status_code)这段代码里有三个点是新手经常忽略的：
- headers 里的 User-Agent 一定要设置。很多网站会检查请求头，没有 UA 的请求很容易被直接拒绝。
- timeout 参数一定要给。不给超时时间，遇到响应慢的站点，程序可能一直卡住。
- resp.encoding 最好根据网页实际编码设置，否则中文会乱码。resp.apparent_encoding 是 requests 根据页面内容推测出来的编码，很多情况下比默认编码更可靠。
2.2 解析库：BeautifulSoup 够用，lxml 和 re 按需选
拿到 HTML 文本之后，怎么提取数据是关键。最常见的组合是 BeautifulSoup + lxml：
from bs4 import BeautifulSoup soup = BeautifulSoup(resp.text, "lxml") titles = soup.select(".article-title") for title in titles: print(title.get_text(strip=True))CSS 选择器是这里性价比最高的技能。你不需要背熟所有选择器语法，只需要掌握类选择器、id选择器、标签选择器和属性选择器这几种，就足以处理大部分案例。
正则表达式（re）也是一种选择，但它适合处理文本模式很规则的内容，比如从一段 JavaScript 变量里抠出 JSON。新手不建议上来就在 HTML 上硬抠正则，因为遇到嵌套标签、换行、实体字符时很容易出错。
2.3 动态页面的通用思路：先找接口，而不是硬啃渲染结果
很多“实战案例”会涉及动态渲染的网站。初学者这时候最容易做的事是安装 Selenium、Playwright 之类的自动浏览器工具，把页面整个渲染出来再抓。
这种方案确实能解决问题，但如果你只是想要页面里那几行数据，它不是最优解。更高效的做法是：打开浏览器开发者工具，切到 Network 面板，刷新页面，找到返回 JSON 数据的接口请求，直接用 requests 请求那个接口。
import requests api_url = "https://example.com/api/list" params = {"page": 1, "pageSize": 20} headers = {"User-Agent": "Mozilla/5.0"} resp = requests.get(api_url, params=params, headers=headers, timeout=10) data = resp.json() for item in data.get("data", {}).get("list", []): print(item.get("title"))这种方式的优势很明显：
- 请求快，不依赖浏览器渲染。
- 数据是结构化的 JSON，不需要解析 HTML。
- 服务器压力小，代码也更简洁。
缺点是需要你花时间分析请求参数，遇到加密参数时会比较麻烦。但对初学者来说，“先找接口”应该成为一种本能。
动态页面优先找接口，而不是先上 Selenium。接口拿不到，再考虑自动浏览器方案。
2.4 数据保存：先 CSV，再考虑数据库
入门阶段的代码里，把结果保存成 CSV 是最稳妥的：
import csv with open("result.csv", "w", newline="", encoding="utf-8-sig") as f: writer = csv.writer(f) writer.writerow(["标题", "链接"]) writer.writerow(["示例标题", "https://example.com/1"])这里两个细节值得注意：
- newline="" 是避免 CSV 每行之间出现空行。
- encoding 用 utf-8-sig 而不是 utf-8，是因为 Excel 打开 utf-8 文件时容易乱码，utf-8-sig 会在文件开头加 BOM，Excel 能正确识别。
如果数据量大，或者以后要频繁查询，可以再学 SQLite。但入门阶段，CSV 已经足够完成大部分练习任务。
3. 面对一个新网站，用四步拆解法判断从哪里开始改代码
很多初学者在拿到一个案例后，直接改个 URL 就运行，结果要么没数据，要么报错。正确的做法是先花五分钟分析目标页面，而不是急着写代码。
3.1 第一步：判断页面是静态还是动态
在浏览器里打开目标页面，右键查看源代码（注意不是“检查”），搜索你要的那个数据。如果能在源代码里直接找到，说明是静态页面，适合用 requests + BeautifulSoup 直接抓。
如果源代码里搜不到，但页面上有数据，说明是动态渲染。这时候打开开发者工具的 Network 面板，刷新，过滤 XHR 或 Fetch 请求，找返回 JSON 的接口。
3.2 第二步：确定数据量和分页方式
问自己三个问题：
- 目标总共多少条数据？
- 是下一页翻页，还是下拉加载？
- 分页参数是页码（page=1）还是偏移量（offset=20）？
这个直接决定循环怎么设计。翻页逻辑用错了，很容易抓成重复数据。
3.3 第三步：先抓一页，验证解析正确
不要一上来就写全站循环。先写一段只抓第一页的代码，打印解析结果，确认数据本身没问题。这一步能帮你把“请求问题”和“解析问题”分开。
这里先别急着调参数。先抓一页，验证整个链路通了，再考虑批量。
3.4 第四步：确认输出形式，再批量执行
数据量小（几十条），直接循环没问题。数据量大（上千条），要加控制。一般建议：
- 每抓几页 sleep 一下，别让服务器觉得你在攻击它。
- 把结果分批次保存，避免程序中途崩溃时全部白跑。
- 遇到异常时打印日志，记录当前进度，方便断点重跑。
这四步看似简单，但它能把一次“失败的爬取尝试”变成“可复现的排查过程”。这也是 18 个案例真正想训练你的东西。
4. 新手最容易踩的五个坑：不是代码问题，是思路问题
很多初学者报错后第一反应是复制错误信息去搜索引擎，这当然没错。但有时候真正的问题不是代码本身，而是对手头任务的误解。下面五种情况最典型。
4.1 把网页复制工具当成万能方案
遇到动态页面就上 Selenium，浏览器能打开就能抓，这句网上的说法误导了很多人。自动浏览器方案启动慢、占用高、难以并发，只适合那些前端渲染极其复杂、确实找不到接口的页面。从长期实践来看，我会建议把“先找接口”放在默认选项，把 Selenium 当作最后手段。
4.2 请求频率控制不当，导致 IP 被限制
很多初学者看到案例里“爬了 1000 页”就觉得越快越好。实际上，多数网站都有访问频率限制，短时间大量请求很容易触发反爬机制。这里的底线不是网站封不封你，而是你得尊重目标服务器的负载。入门练习，每两秒一个请求完全够用。
import time import requests from requests.exceptions import RequestException for page in range(1, 11): try: resp = requests.get(url, params={"page": page}, timeout=10) if resp.status_code != 200: print(f"第{page}页返回非200：{resp.status_code}") continue # 解析并保存 print(f"第{page}页处理完成") except RequestException as e: print(f"第{page}页请求失败：{e}") time.sleep(2)这段代码并不复杂，但它代表了一种工程意识：即使某个请求失败，程序也应该能继续，而不是崩掉。
4.3 忽略异常处理，一遇到报错就中断
真实的爬虫代码里，没有异常处理是活不过一个晚上的。至少要做这些：
- 用 try/except 捕获请求异常，记录失败的 URL。
- 检查返回状态码，不是 200 就打印警告。
- 解析前先确认网页结构是否符合预期。
4.4 拿到的数据是乱码或空值，不知道先查哪一层
排查顺序建议是这样：
- 先看响应状态码：200、403、404、500，分别代表不同含义。
- 再看请求头：是不是少了 User-Agent、Referer、Cookie。
- 再看编码：响应文本里中文乱码，优先查 encoding。
- 再看选择器：标签名、类名是不是匹配当前页面。
- 最后看数据来源：如果解析不到，可能数据根本不在 HTML 里，而是接口返回的 JSON。
很多人一乱码就怀疑是代码问题，其实大部分情况是编码或选择器问题。按这个链路走，90% 的问题能定位。
4.5 过度追求“全自动”，忽略了环境稳定性
还有一类新手，跑通一页之后马上想让它全自动每天跑。这个想法没错，但爬虫只是一个数据获取环节，长期跑还要考虑代码部署在哪里、失败重试怎么做、数据重复怎么去重、目标网站改版怎么通知你。这个阶段的爬虫已经不是“爬虫代码”，而是一个小系统。先跑通单次任务，再考虑调度，这个顺序不能反。
5. 从复制案例到独立完成：三个阶段的进阶路径
假设你把 18 个案例都跟着敲了一遍，下一步该怎么走？我建议按下面这三个阶段来。
5.1 阶段一：模仿——把代码敲出肌肉记忆
不要复制粘贴，而是一个字一个字敲一遍。这样做不是为了练打字，而是让你被迫关注每一行代码存在的理由。敲完以后再改动几个参数，比如把 CSS 选择器换掉、改字段输出顺序，确认修改后仍然能跑通。
5.2 阶段二：改造——替换数据源，验证流程复用
找一个结构类似、但完全不同领域的网站（比如把博客案例改成新闻案例），用同一个流程分析、请求、解析、保存。如果流程能复用，说明你掌握了类型解法，而不是只会某条代码。
5.3 阶段三：设计——从零开始解决一个新任务
自己设定一个需求：比如“抓取某个网站的前 100 条数据，保存到 CSV”。不要参考现成代码，从分析页面开始，一步步实现。遇到卡点先尝试自己排查，再查资料。这个过程才是真正的爬虫项目实践。
这三个阶段对应的其实是“看懂代码—改写代码—设计代码”的能力跨越。很多网上的案例只能带你走到第一阶段，剩下的要自己补。
| 阶段 | 做什么 | 检验标准 |
|---|---|---|
| 模仿 | 手动敲案例代码，改参数 | 改参数后仍能跑通 |
| 改造 | 换同类网站，替换 URL 和选择器 | 新网站能独立跑通 |
| 设计 | 从零实现一个新需求 | 能自行完成完整流程 |
6. 爬虫学习真正的长期价值不在“爬”，而在工程化思维
说回最开始的判断：18 个实战案例之所以适合小白，不是因为它能让你拥有 18 个网站的爬虫源码，而是因为它逼着你反复走完完整的采集流程。在这个过程中，你学到的其实是几套通用的工程思维。
6.1 最小可运行验证
先抓一页，确认接口、解析、保存全流程正常，再上批量。这个习惯适用于爬虫，也适用于几乎任何软件开发任务。它能避免你一次性写 300 行代码后全盘报错的痛苦。
6.2 边界与异常意识
实际运行中，网络不稳定、页面改版、字段缺失都是常态。一个能长期用的脚本，必须把“正常运行”当作少数情况来设计，把各种异常当作默认情况来处理。日志、重试、兜底，这三样东西越早接触越好。
6.3 合规与尊重边界
网络爬虫本身是技术中性的，但使用有边界。请求频率过高会给对方服务器造成压力，这种影响无论对个人还是对网站方都是负担。练习时：
- 优先选择公开数据和明确允许抓取的网站。
- 控制频率，不要短时间密集请求。
- 不采集个人敏感信息，不把数据用于商业用途。
- 认真看目标网站的 robots.txt 和使用条款。
这一点与其说是技术问题，不如说是把“能爬”和“应该爬”分开的基本判断。如果你以后做正式项目，这个判断会直接影响你和数据供应方之间能否长期合作。
6.4 从代码到系统的升级意识
18 个案例是一个很好的起点，但它离一个真正的数据采集系统还差几块拼图：日志记录、失败重试、任务调度、数据去重、变更监控。这也是为什么我不建议在入门阶段就急着追求“全自动每天抓”：基本流程还没跑稳，叠加太多调度逻辑只会让问题排查更困难。
先跑通，再优化，最后考虑工程化。这是最稳妥的路径。
回到开头那个朋友的问题——“换了一个网站就不知道从哪里改了”。这个问题不是因为他代码量不够，而是因为他对“流程”的理解还停留在具体代码上。如果他先把分析页面、发起请求、解析数据、保存结果这条链路变成一种习惯，再看到任何网站，心里都会有数：这属于哪一步，我该查什么。
18 个实战案例只是入口。你从里面带走的，不应该只是 18 份源码，而是一套看到一个页面就知道该怎么拆解、怎么验证、怎么长期维护的方法。这才是这些案例真正值得学一遍的理由。
