Python爬虫实战：requests+bs4批量下载漫画并合成PDF

这篇漫画下载教程我拖了挺久才写，因为市面上的同类文章要么讲得太浅，改了网站结构就废掉；要么一上来就堆 Scrapy、Splash、验证码识别这些重型武器，新手根本用不上。其实日常看漫画、做个人离线阅读库，远没那么复杂。你只需要 Python 的 requests 解析页面结构，bs4 提取图片地址，再用 img2pdf 把本地图片按顺序合成为一个 PDF 文件，整套流程走通也就一晚上时间。

这篇文章以“无加密”站点为目标，就是那种页面纯静态、图片地址直接写在 HTML 里、没有复杂 JS 渲染的漫画网站。这类站是爬虫新手最好的练手对象，结构透明、出错直观，而你学会的技能点——URL 拼接、请求头伪装、流式下载、批量文件处理——可以平移到绝大多数常规网站，包括新闻站、图库站、文档站。不需要你有爬虫基础，但至少得会一点 Python 语法，能看懂函数和循环。我会把每一步的“为什么这么做”也讲清楚，不然换了站点你照样抓瞎。

1. 项目思路与整体设计

1.1 为什么选“无加密”站点做实战

先说个大实话：网上流传的“爬取XX漫画网站”的教程，十个里有九个拿付费站点或加了加密参数的站点做案例，然后教你对着一段看不懂的 JS 分析半天，最后得出需要 Selenium 模拟浏览器。这种教程看完你只会复制粘贴，因为核心逻辑全是死记硬背，站点一改立刻报废。

无加密站点不一样。它的真实图片地址就躺在 HTML 里，你右键查看源代码就能看到。整个爬虫的逻辑退回到最朴素的模型：发一个 HTTP 请求拿 HTML 字符串，用字符串解析工具踢出 标签，拼成完整的图片 URL，再发请求把图片二进制数据写到本地文件。没有 token、没有动态签名、没有接口加密，每一步失败你都能从返回结果里直接判断原因。

选这种站点做实战，真正的价值在于训练你“拆解流程”的能力。拿到任何一个网站，你能先分清哪部分是静态 HTML、哪部分是异步加载、哪部分是加密接口，这比会调任何框架都重要。等你把无加密流程跑熟了，再去看 Selenium、Pyppeteer、mitmproxy 这些工具，你会知道它们分别在解决哪个环节的什么问题，而不是乱学一气。

1.2 技术选型与工具链

我的选择很保守，全栈依赖不超过五个库，每一个都经住了大量生产环境的考验：

很多人问我为什么不用 Scrapy。Scrapy 是优秀的框架，但对于这种几十个页面、图片直链的下载任务，它的中间件、管道、选择器配置反而是负担。requests 配合循环写下来，代码量更短，逻辑一目了然，出了问题你也能快速定位到具体某一行。工具是用来解决问题的，不是用来炫耀的，能用简单方案解决绝不上重武器。

我用 img2pdf 而不是直接用 Pillow 来保存 PDF，是因为 Pillow 在遇到 CMYK 模式的 JPEG 时经常闹脾气，合并出来的 PDF 要么偏色要么直接报错。img2pdf 直接读取图片的原始字节流封装进 PDF 容器，不做任何重编码，既快又稳，这个选择帮我少掉了好几天头发。

1.3 完整流程预览

整个项目可以拆成五个串联的环节：

1. 请求漫画目录页，解析出所有章节的名称和 URL。
2. 依次请求每个章节的详情页，解析该章节下每一张漫画图片的 URL。
3. 为每一张图片发送下载请求，以流式方式写入本地磁盘。
4. 按章节对本地图片排序，用 img2pdf 合并成单文件 PDF。
5. 清理过程中的临时图片文件，保留最终 PDF。

这套流程有一个非常优雅的地方：中途断了可以随时重跑。图片下载阶段做了断点续传，重复运行不会重复下载已有文件；PDF 合并阶段有完整度检查，不会把缺页的文件当作成功产物。对于漫画这种动辄几百张图片的任务来说，能不能断点续传直接决定脚本是“能用”还是“好用”。

2. 目标解析：看懂漫画站的页面结构

2.1 从目录页到图片页的请求链路

动工之前必须把网站的信息架构摸清楚。绝大多数漫画站的 URL 结构长这样：书籍目录页是一个 URL，每个章节对应目录页里的一个链接，点进章节后图片又分页展示，每页对应一个子 URL。

我用一个通用例子来演示，假设目标站点结构如下：

• 书籍主页：https://manga.example.com/book/12345/
• 章节目录：就在书籍主页里，用<ul>列表呈现，每个<a>标签指向章节地址
• 章节页面：https://manga.example.com/book/12345/chapter/3/
• 漫画图片：章节页面中的<img>标签，src属性指向图片地址

这个结构清晰得简直是专门为教学准备的。实际遇到复杂站点也别慌，Flex 布局、懒加载、CSS 背景图替换这几种花样，后面排查章节我会细讲。眼下先把这个最基础的结构吃透。

判断一个章节有多少页，你可以直接观察 URL 规律。如果章节地址末尾的数字是页码，那就好办；但更多站点是在章节页内放一个“下一张”按钮，一个页面只有一张大图。第二种结构更常见，所以我们解析的目标就是“每一页对应一张大图”。

2.2 用开发者工具定位真实图片地址

不要一上来就写代码，先手动把流程走通一次。打开浏览器，进入一个漫画章节页，按 F12 打开开发者工具，切到 Network（网络）面板，刷新页面，然后筛选出图片类型的资源请求。

这里有个小技巧：很多懒加载站点把真实图片地址放在>HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36", "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", "Referer": "https://manga.example.com/", }

Referer 字段尤其重要。大部分图片 CDN 只允许图片被页面正常加载时访问，检查 Referer 必须匹配白名单域名，一旦发现来源不对直接拒绝。这招对小白爬虫几乎一招致命，但只要你在下载图片时把 Referer 改成章节页的地址就能轻松绕开。下载图片和解析 HTML 用的请求头最好分开维护，因为图片请求需要 Referer，而 HTML 请求不需要。

3. 代码实现：从章节抓取到PDF合并

3.1 环境准备与依赖安装

老规矩，先建虚拟环境。我不推荐把依赖直接装到全局，因为 requests、bs4 这些库升级频繁，你很难保证不同项目之间的依赖不互相打架。

python -m venv manga-downloader source manga-downloader/bin/activate # Windows 用 manga-downloader\Scripts\activate pip install requests beautifulsoup4 pillow img2pdf

requests 负责网络层，BeautifulSoup4 负责解析 HTML，Pillow 用在后面做图片损坏检查，img2pdf 做 PDF 合成。四个库加起来不到几十兆，装完就能开工。全部装好后，新建一个manga_crawler.py文件，接下来所有代码都写在这里。

3.2 抓取章节列表

第一步是拿到书籍主页，解析出所有章节链接。我用一个书旗漫画风格的模拟站点做示范，但选择器和 URL 结构完全按照通用逻辑编写，你们用任何同类站点都能对照着改。

import requests from bs4 import BeautifulSoup from urllib.parse import urljoin, urlparse BOOK_URL = "https://manga.example.com/book/12345/" def get_chapter_list(book_url): resp = requests.get(book_url, headers=HEADERS, timeout=10) resp.raise_for_status() resp.encoding = resp.apparent_encoding soup = BeautifulSoup(resp.text, "html.parser") chapter_list = [] # 选择章节列表的选择器，不同站点需要调整 for a in soup.select("ul.chapter-list li a"): title = a.get_text(strip=True) href = a.get("href") if title and href: full_url = urljoin(book_url, href) chapter_list.append((title, full_url)) return chapter_list chapters = get_chapter_list(BOOK_URL) print(f"共发现 {len(chapters)} 个章节") for title, url in chapters[:5]: print(title, url)

urljoin是这个环节的核心函数。HTML 里的链接分三种：完整地址、根路径相对地址/book/xxx/、当前路径相对地址chapter/3/。urljoin能把它们全部规范化成完整 URL，省去你手写拼接逻辑，少踩坑。我见过太多人自己写字符串拼接，遇到目录层级不同就拼错了。

章节标题里经常混入换行符、空格和特殊字符，这些后面要用来做文件名。Windows 文件名不允许包含\/:*?"<>|这九个字符，所以提前清洗比最后报错再改要舒服得多。我通常用一行正则处理：

import re def safe_filename(name): return re.sub(r'[\\/*?:"<>|]', "", name).strip()

3.3 提取每页图片地址

拿到章节 URL 后，请求章节页并提取图片地址。不同的漫画站结构差异不小，但无外乎是<img>标签藏在哪个容器里：

def get_page_image_url(chapter_url): resp = requests.get(chapter_url, headers=HEADERS, timeout=10) resp.raise_for_status() resp.encoding = resp.apparent_encoding soup = BeautifulSoup(resp.text, "html.parser") img = soup.select_one("div.reader-content img") if not img: return None # 优先取>import os from pathlib import Path def download_image(img_url, save_path, referer): if Path(save_path).exists() and Path(save_path).stat().st_size > 1024: print(f"跳过已存在文件：{save_path}") return True headers = {**HEADERS, "Referer": referer} try: with requests.get(img_url, headers=headers, stream=True, timeout=30) as resp: resp.raise_for_status() total = int(resp.headers.get("content-length", 0)) downloaded = 0 with open(save_path, "wb") as f: for chunk in resp.iter_content(chunk_size=8192): if chunk: f.write(chunk) downloaded += len(chunk) # 大小校验：如果服务端给了 content-length，下载完对比一下 if total and downloaded != total: print(f"下载不完整：{save_path}，预期 {total}，实际 {downloaded}") return False return True except requests.RequestException as e: print(f"下载失败：{img_url}，原因：{e}") return False

注意我把stream=True放在最外层请求里了，这样响应对象不会立即把所有内容读入内存。写入时固定用 8KB 的块大小，这个值对大多数网站和本地磁盘都是最优解，太小浪费 CPU，太大容易在弱网条件下卡住。

下载顺序我按章节页的自然顺序来，也就是从前往后下载，然后保存为001.jpg、002.jpg这种带零填充的文件名。零填充非常重要，因为字符串排序时10.jpg会排在2.jpg前面，如果没有零填充后续合并 PDF 的顺序就乱了。这是新手最容易忽略又最容易翻车的地方。

def download_chapter(title, chapter_url): chapter_dir = Path("downloads") / safe_filename(title) chapter_dir.mkdir(parents=True, exist_ok=True) page_url = chapter_url page_num = 1 failed = 0 while page_url: img_url = get_page_image_url(page_url) if not img_url: break filename = f"{page_num:03d}.jpg" save_path = chapter_dir / filename ok = download_image(img_url, save_path, referer=chapter_url) if not ok: failed += 1 if failed > 3: # 连续失败多次，可能是被限流了，歇一会儿 time.sleep(10) else: failed = 0 next_link = get_next_page_link(page_url) page_url = urljoin(chapter_url, next_link) if next_link else None page_num += 1 time.sleep(0.5) print(f"章节 {title} 下载完成，共 {page_num - 1} 页")

这个get_next_page_link函数就是去解析当前页面里“下一张”按钮的 href 属性。这是漫画站最通用的分页方式，比猜测页码靠谱得多。我在分页判断时加了容错机制：连续失败三次就休眠 10 秒，这是应对隐式限流的常用策略。

3.5 按章节合并PDF

下载完成只是做完一半，合并 PDF 是另一半。合并前我先用 Pillow 做一次完整性检查，目的是排除那些下到一半的损坏图片，避免生成的 PDF 打不开或者缺页：

from PIL import Image import img2pdf def images_to_pdf(image_dir, output_pdf): image_files = sorted( [os.path.join(image_dir, f) for f in os.listdir(image_dir) if f.endswith(".jpg")] ) valid_files = [] for img_path in image_files: try: with Image.open(img_path) as im: im.verify() # 验证图片完整性 valid_files.append(img_path) except Exception: print(f"发现损坏图片，已移除：{img_path}") os.remove(img_path) if not valid_files: print("没有有效的图片，跳过 PDF 生成") return with open(output_pdf, "wb") as f: f.write(img2pdf.convert(valid_files)) print(f"PDF 已生成：{output_pdf}")

img2pdf.convert接收一个图片文件列表，输出格式是 PDF 字节流。它会自动处理图片的分辨率和尺寸，不需要你手工调整。之前提过不用 Pillow 转 PDF 的原因——色彩模式问题——在这段代码里暴露得明明白白：Pillow 只用来读取并验证图片，真正封装 PDF 的活全部交给 img2pdf。

另外我帮你想好了一个清理策略：合并 PDF 成功后，保留一个章节的原始图片还是直接清理？我的建议是临时图片保留到所有章节合并完毕后再统一清理，万一中间章节需要重新合并就不用重新下载。磁盘吃紧的话，合并完先删除该章节图片，最后再整体检查一遍 PDF 大小是否合理。

4. 常见问题与排查技巧实录

4.1 请求被拒或返回403

这是新手上路遇到最多的状况。403 的常见原因有四个：没带 UA、没带 Referer、请求频率太高、IP 被封锁。逐个排查的顺序也很讲究。

先看请求头。你可以在代码里临时打印一下响应状态码和响应头，如果返回 403 但手动浏览器访问正常，那就是请求头问题。把浏览器里 F12 Copy as cURL 出来的请求头完整搬过来，一般就能解决。

如果请求头完整但还是 403，就要考虑频率了。我见过有人把time.sleep(0.5)改成直接不睡，结果 200 张图片冲到第 30 张就被封 IP，整个脚本白跑。频率是你的保护伞，尤其是目标站没有加密的情况下，你只有低调一点才不会触发它的防护阈值。每张图片之间至少间隔 0.3~0.5 秒，这个节奏既不会让人等太久，也不会触发限流。

真要遇到 IP 被临时封锁，别想什么代理池。个人娱乐级爬虫用不上那套复杂基建，你只需要耐心等待几分钟到几小时，换个网络环境接着跑就行。真正需要分布式和代理池的场景，是那些以爬虫为主业的商业项目，咱们的场景用不上。

4.2 图片下载损坏或不完整

这种问题最坑，因为图片文件名字、数量都在，打开才发现图片是坏的一半灰白。原因通常是下载过程中连接被断开，或者服务器返回了错误页面但你误当图片保存了。

我的策略是双重校验：文件大小校验加上 Pillow 完整性校验。文件大小校验在下载函数里已经做过，Pillow 校验在合并 PDF 前做。两层筛完，基本能保证进入 PDF 的每一张图都是能正常打开的。

还有一种情况是下载了一张 HTML 错误页面，但文件被保存成了.jpg。判断方法很简单：用文本方式打开文件，开头如果出现<!DOCTYPE html>或者一串 JSON 字符串，那就是服务器返回了拦截页面。这种文件在 Pillow 完整性检查阶段会被筛出来，但最稳妥的做法是下载时检查resp.headers.get("content-type")，如果它返回的不是image/jpeg、image/png之类，直接放弃这张图片。

4.3 合并PDF顺序错乱

PDF 页序错乱最常见的原因就是文件名排序问题。如果你已经用了零填充格式，基本不会踩这个坑。但如果某个章节图片超过一千页，999.jpg之后就会出现1000.jpg，字符串排序时它反而排到998.jpg前面。

处理办法有两个：一是把文件名扩展为四位甚至五位零填充，够你用到九千页；二是在合并时不要依赖文件名排序，而是把页码信息存在一个独立的文件列表里，按页码字段排序。我个人的习惯是双保险——既零填充，又在合并前用sort(key=lambda x: int(re.search(r'(\d+)', x).group(1)))做一次数字排序，万无一失。

4.4 关于多线程下载的取舍

很多人拿到下载脚本后的第一个想法是“太慢了，我要加多线程”。先别急，我要泼一盆冷水。

多线程能提速的前提是服务器愿意让你提速。如果一个漫画站没有加密、没有反爬机制，它的带宽本来就是最大的瓶颈。你用单线程 0.5 秒一张图，一章 50 页也就半分钟；用 20 个线程狂下，不仅不一定会快，还可能因为触发限流被强制断开，最后反而要花更多时间处理失败重试。

如果你确定要提速，最稳妥的做法是用ThreadPoolExecutor控制并发数，最大不超过 5：

from concurrent.futures import ThreadPoolExecutor, as_completed with ThreadPoolExecutor(max_workers=5) as executor: futures = [ executor.submit(download_image, img_url, save_path, referer) for img_url, save_path, referer in download_tasks ] for future in as_completed(futures): print("完成一项", future.result())

多线程只用于下载阶段，解析和合并保持单线程。合并 PDF 必须保证顺序，多线程处理顺序逻辑只会让你的代码一团乱麻，得不偿失。

5. 扩展思路与合规边界

5.1 增量更新与章节监控

漫画是连载制，今天下载完不等于永远结束。很多朋友用这个脚本只下载完当下内容就丢到一边，下一周更新了再手动重跑全量脚本，浪费时间浪费流量。

增量更新很简单：在项目目录里建一个downloaded.json文件，每成功处理一个章节，就把章节标题和 URL 写进这个 JSON。下次跑脚本时先读取 JSON，发现某个章节已经处理过直接跳过。这么做还能在脚本异常退出后帮你快速续跑，而不是从头再来。

配合一个定时任务，比如 Windows 的计划任务或者 Linux 的 cron，每周日下午自动跑一次增量检查，你就能拥有一个完全自动化的追更系统。我个人很喜欢这种“设置一次就再也不操心”的方案，这也是爬虫给我生活带来的最大便利之一。

5.2 遇到JS渲染站点怎么办

你可能已经注意到了：我教你的这套方案，只适用于图片地址直接出现在 HTML 源码里的站点。有些漫画站会用 JavaScript 动态拼接图片地址，或者用懒加载插件让图片地址在初始 HTML 中不可见。遇到这种站怎么办？

两个备选方案。第一，用浏览器开发者工具手动查数据接口。很多 JS 渲染站点并不是没有接口，只是接口在页面加载后才会请求。你打开 Network 面板，筛选 XHR 或 Fetch 请求，往往能看到一个api.php?action=chapter&id=xxx之类的接口，返回 JSON 数据，里面直接就是所有图片地址的数组。这种情况你根本不用 Selenium，直接模拟请求这个接口就行。

第二个方案是用 Selenium 或 Playwright 渲染页面，等图片加载完成后再提取 URL。这种方案速度慢、耗资源，但确实是通用兜底方案。我平时尽量走接口方案，因为它更快更飘，但 Selenium 作为最后手段也有存在价值。

这里不展开讲太多，因为那是另一篇教程的量。知道有这条路，将来真遇到了，不会觉得无路可走。

5.3 爬虫练习的边界与建议

技术本身是工具，用得好不好全在拿它做什么。写这个教程的核心目的是帮大家掌握网络请求、HTML 解析、文件处理和自动化这批基本功，并不是教大家批量扒图盗版传播。

在动手爬任何站点之前，我的建议是主动阅读目标站的robots.txt和用户协议，尊重站点声明。个人学习、离线阅读、存档备份这类场景，通常问题不太大；但如果你要把下载内容打包传播、商用盈利，性质就完全变了。传播盗版漫画涉及版权问题，这个红线一定不要碰。

现在漫画平台很多都有官方 App 和会员服务，你花钱买下的阅读权益比任何爬虫都稳定。爬虫更适合的场景是抓取已进入公有领域的内容、你拥有的内容，或者用于纯粹的技术学习。我每写完一个爬虫，都会考虑如果我是网站方，我会不会介意这种行为——这是判断边界最简单直接的方法。

6. 最后再分享几个实操细节

如果你的脚本已经能正常运行了，后面这几条细节能帮你的产物体感更上一层楼。

第一，下载下来的图片建议顺手压缩一下再合并。很多漫画站的原图是 1500px 宽以上的高清图，一张就要 1MB 左右，一章 50 页就是 50MB，整个 PDF 体积非常夸张。如果你只是自己在手机或平板上看，可以用 Pillow 把图片等比缩放到宽 1280px、质量 85 再合并，体积能减少 60%，观感几乎没差别。

第二，PDF 的元数据值得设置。标题、作者、创建日期这些信息做好之后，你的离线书库在阅读器里会显得极其工整，翻起来也舒服。img2pdf 本身不提供元数据设置接口，你可以用 PyPDF2 在生成 PDF 后再写一遍元数据，或者干脆就用 PDF 阅读器自带的功能批量编辑。这步不是必选项，但做完之后你的“个人漫画图书馆”会很有成就感。

第三，这个项目的代码结构可以复用：目录页解析、详情页解析、文件下载、文件合并这四个模块，几乎就是大多数爬虫项目的标准流程。你把漫画站换成图片素材站、壁纸站、文档站，逻辑几乎不用动，改改选择器和输出格式就能跑。学会这种模块化拆解，比你照着教程敲一百遍代码都有用。

我在实际写这个项目时，第一个版本跑起来全是毛病：忘记加 Referer 被 CDN 拒了、文件名没清洗导致 Windows 报错、章节排序错乱导致 PDF 倒着翻。这些坑我全都踩了一遍，最后沉淀成这篇文章里的各种防御措施。你现在照着这份教程来，基本可以一路顺畅到底。如果中途还是遇到没见过的报错，先用好你的开发者工具，看看服务器到底返回了什么，这个问题你独立解决过一次，你的爬虫功力就真正上了一个台阶。