小说下载工具全攻略：运行方式、导出格式与本地书库归档

把一本书完整地留在自己硬盘里这件事听着简单真动手坑不少。前阵子帮朋友整理他追了三年的书单才发现很多人对小说下载工具的理解还停留在“点一下按钮出来一个 txt”。真到自己上手问题就来了有人导出来的文件满屏乱码转成 UTF-8 之后章节标题反而没了有人做出的 epub 在阅读器里目录全是空白点进去只能一页页往下翻还有人挂了两小时只下回来三百章剩下七百章打开全是空壳。这篇就把这套活儿从头到尾捋一遍——导出格式怎么选、运行方式怎么挑、本地保存要注意哪些细节。标题里那个平台名字大家都懂下面我统一用“目标平台”来指代避免不必要的麻烦。内容面向三类人完全不懂代码只想双击即用的、会点 Python 想自己改参数的、以及想把几百本书长期归档管理的。不管你在哪一档后面都能找到能直接抄的部分。1. 先把需求拆清楚本地书库到底要解决什么1.1 四个真实痛点决定你该选哪种方案很多人一上来就问“哪个工具最好用”这问法本身就有问题。工具好不好用取决于你要解决的是哪一类问题。我把这几年经手的场景归了归类基本跑不出下面四种。第一种是离线阅读。通勤地铁、飞机、老家没网的房间里你不可能指望随时连得上。这类需求的核心是“内容完整 文件能打开”对排版要求不高TXT 就够。第二种是跨设备同步。手机看完换平板平板看完换电纸书如果每次都要重新找进度体验会崩。这时候格式就重要了EPUB 能记住阅读位置TXT 在很多阅读器里只能靠百分比估。第三种是长期归档。有些书你追了几年中间断更、下架、改名、章节被删改等你想回头找某一章原平台已经找不到了。这类需求的关键是“可检索 可校验”得有稳定的命名规则和目录结构。第四种是二次加工比如你想把书导进笔记软件做摘录或者用脚本统计某本书的词频、人物出场次数那就要 HTML 或 Markdown 这种结构化的中间产物。这四类需求对应完全不同的技术取舍。只做离线阅读却硬上 EPUB 打包等于给自己找麻烦反过来想做归档却只存 TXT三年后你连哪本书是哪个版本都分不清。所以我建议先花五分钟想清楚自己属于哪一类再往下看。1.2 技术路线三选一先判断你要“重”还是“轻”抛开班门弄斧的细节这件事的技术路线其实只有三条。第一条是现成的图形化工具下载解压双击填个链接选个格式就完事。优点是零门槛缺点是黑盒——参数改不了出问题只能等作者更新而且这类工具良莠不齐有些会捆绑一堆你不需要的东西。第二条是开源脚本 自己配环境通常是 Python 写的能改并发数、能改输出格式、能加自定义清洗规则。缺点是要装依赖第一次跑起来可能要折腾半小时。第三条是容器化或常驻脚本把整个流程封进一个镜像里定时跑、批量跑、跑完自动归档。这台机器可以是你家里的旧笔记本、软路由、或者是台常年开着的迷你主机。我的经验是一次性需求走第一条长期追更走第二条书库规模超过五十本就走第三条。原因很朴素——手工操作的成本是线性增长的而脚本化的成本是一次性的。你下第一本书的时候觉得手动挺快下到第三十本就会开始烦躁因为重复劳动最消耗人。而一旦上了脚本后面每加一本书的边际成本几乎是零。2. 三种运行方式从双击即用到长期挂机2.1 方式一打包好的可执行程序适合完全不想碰命令行的人这是最省心的一条路。作者通常会把 Python 脚本用打包工具封成单个 exe 或 app运行时不需要你装任何东西。你要做的只有三件事解压到一个纯英文路径下、双击运行、按提示粘贴书籍地址。听起来简单但这里有三个高频翻车点我几乎每次帮人看问题都能碰到。第一个是路径里带中文或空格。很多打包工具生成的程序在读写临时文件时对非 ASCII 路径处理得很糟糕表现就是程序一闪而过、或者卡在“正在解析”不动。解决办法很土但有效直接扔到D:\books这种路径下。第二个是杀毒软件误报。打包后的可执行文件体积大、行为模式像“批量网络请求”很容易被启发式引擎盯上。这不是让你去关杀软而是建议你把程序目录加进白名单并且只从你能确认来源的地方拿文件。第三个是缺少运行库。部分打包方案依赖系统里的 VC 运行库或 .NET 组件老系统上会提示缺 dll装一下对应的运行库即可。这个方式还有个隐藏限制参数基本锁死。作者给你什么就是什么你想改并发数、想加个自定义的章节过滤规则做不到。所以它适合“我就下这一本下完拉倒”的场景。2.2 方式二源码 Python 环境灵活度最高会一点点命令行的强烈建议走这条。流程是装 Python建议 3.9 以上、建虚拟环境、装依赖、改配置、运行。为什么一定要建虚拟环境因为这类脚本的依赖往往比较“挑版本”比如某个解析库要求 4.x另一个转换库又锁死了 3.x直接装在全局环境里早晚会和你其他项目打架。虚拟环境把这堆东西隔离在一个文件夹里删掉就干净了不留后患。命令很简单python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate pip install -r requirements.txt装完依赖之后第一件事不是急着跑而是打开配置文件看一眼。绝大多数脚本都会有个config.yaml或者config.py里面有几个关键项值得你亲手调并发线程数、请求间隔、超时时间、重试次数、输出目录、导出格式。这几个参数的默认值往往是作者按“最保守”设的跑起来慢得让人着急但贸然拉满又容易触发目标站点的频控。后面第 4 节我会给一组实测比较稳的数值。这条路的额外好处是能改代码。比如你想在正文清洗阶段加一条规则把每章末尾那段“本章未完点击下一页”自动删掉改两行正则就行。这类小定制图形化工具是永远给不了你的。2.3 方式三容器化或脚本常驻为长期书库准备到了这一步思路就变了——你不再是“下一本书”而是在维护一个持续运转的小系统。典型做法是把整个流程封进一个容器镜像或者写一个 shell 脚本挂到定时任务里每天凌晨跑一次把有更新的书增量拉下来。容器化的好处是环境完全隔离换台机器把镜像一拷就能跑不会出现“在我这儿好好的到你那儿就报错”的经典问题。关键点有三个目录挂载要把输出目录映射到宿主机否则容器一删书就没了时区要设对不然日志时间全是 UTC排查问题时对不上日志要落盘跑批任务的失败必须能事后回溯不能只在终端刷一下就没了。下面是一份可以直接改的编排配置用来示意结构services: bookgrab: image: local/bookgrab:latest volumes: - ./output:/app/output - ./config:/app/config environment: - TZAsia/Shanghai - LOG_LEVELINFO restart: unless-stopped定时任务这边cron表达式写成0 3 * * *就行凌晨三点跑避开人多的时段。有个小坑提醒一下增量更新必须依赖一个稳定的书籍标识通常是书籍 ID 加章节 ID 的组合。如果你只按书名判断遇到改名的书就会重复下载如果只按章节序号判断遇到插章、并章、倒序的书就会错位。我在第 4 节会讲怎么做这个去重。2.4 三种方式的取舍对照维度可执行程序源码运行容器/常驻上手门槛极低中等较高参数可调性几乎为零高高环境隔离无中虚拟环境强适合规模1 到 3 本10 到 50 本50 本以上主要风险来源不可控、误报依赖版本冲突配置写错导致静默失败排错难度高黑盒中低有日志这张表里的“排错难度”是最容易被忽略的一栏。很多人只看上手门槛选了个双击即用的结果出了问题完全无从下手最后还是要回来学第二条路。3. 五种导出格式别急着全都要3.1 TXT最丑但最不会出错的那个TXT 是所有格式里兼容性最强的几乎没有之一。十几年前的 MP3、老式电子词典、现在的任何一台设备打开 TXT 都没问题。它的结构简单到极致——就是纯字节流没有任何元数据、目录、样式的概念。正因为简单它的问题也很明确。编码是第一道坎。Windows 上很多老工具默认写 GBK你拿到 Mac 或者手机上打开就是一片问号。解决办法是统一输出 UTF-8且不带 BOM——带 BOM 的 UTF-8 在部分阅读器里开头会多出一个看不见的字符导致首行标题错位。第二道坎是章节定位。TXT 没有目录结构所谓“目录”只是靠“第X章”这样的文本约定阅读器能不能识别全看它自己的正则写得怎么样。所以我导出 TXT 的时候会做一个约定章节标题单独占一行前后各留一个空行格式统一成“第X章 标题”这样绝大多数阅读器都能正确切分。还有一个实操细节换行符。Windows 是\r\n类 Unix 是\n。跨平台使用时统一成\n更稳妥Windows 上的现代编辑器也都能正确显示。句子之间的空行也别省一段一行读起来太挤段间加空行观感会好很多。注意TXT 里千万别把广告段落一起带进来。很多平台的正文页会插入“本章完请投推荐票”之类的尾巴一本书几百章攒下来能有好几万字垃圾。3.2 EPUB标准电子书排版和目录都靠它如果你只打算认真学一种格式学 EPUB。它是目前电子书领域事实上的标准本质是一个符合特定结构的 ZIP 压缩包里面装着 XHTML 页面、样式表、图片和一堆描述文件。结构上必须包含这几样东西根目录一个叫mimetype的文件内容固定是application/epubzip而且必须是压缩包里的第一个文件、且不能被压缩存储方式compression method 为 0。这一条是规范硬要求很多自己写打包脚本的人栽在这里——阅读器打开直接报“文件损坏”排查半天发现是 mimetype 被 deflate 了。接着是META-INF/container.xml它告诉阅读器去哪里找主描述文件。再往后是OEBPS/content.opf里面写书名、作者、语言、封面、章节清单和阅读顺序。目录方面EPUB 2 用toc.ncxEPUB 3 用nav.xhtml想兼容老设备就两个都放。我做 EPUB 有几个固定习惯。元数据一定要填全书名、作者、语言zh-CN、出版社可以留空、唯一标识UUID。语言这一项很多人不填结果在某些阅读器里中文排版会按日文规则处理标点位置全歪。每个章节单独一个 XHTML 文件别把整本书塞进一个文件里否则打开大文件时阅读器会卡死。样式表写得越简单越好就三条行高 1.6 到 1.8、段间距 0.5em、首行缩进 2em别搞花里胡哨的字体阅读器不一定支持。3.3 MOBI 与 AZW3给电纸书准备的这两个格式主要服务于电纸书生态。MOBI 是老格式兼容性广但对中文排版的支持比较粗糙字体嵌入也受限。AZW3 是它的继任者支持更丰富的 CSS 和字体同一个文件在设备上显示效果明显更好。如果你的设备两种都认优先选 AZW3别犹豫。这条路的现实做法是先做出 EPUB再用转换工具转过去。转换时最常遇到的问题有两个。一个是目录丢失原因是源 EPUB 的目录文件不规范转换器没识别出来所以要保证第 3.2 节说的toc.ncx和nav.xhtml都得有。另一个是中文断行错乱表现是一行字被莫名切成两截或者标点跑到行首。这通常是转换时的段落识别规则问题把源文件里段与段之间的空行补齐基本能缓解。顺便说一句转换这一步完全可以命令行批量做一条命令处理整个文件夹比手动一个个拖进图形界面快得多。3.4 PDF只在你需要“固定样子”的时候用PDF 的优势是所见即所得你在这台机器上看到的排版换十台设备打开都一样。适合的场景其实很窄打印装订、做长图分享、或者给完全不熟悉电子书格式的人看。它的劣势在阅读体验上非常明显。PDF 是固定页面尺寸屏幕小的时候要么字小得看不清要么得左右拖动。更麻烦的是中文字体嵌入——如果不嵌入字体换台没装对应字体的机器打开中文会变成方框或者宋体替代观感直接崩掉。转换时务必勾选字体嵌入文件会大一圈但这是必须付的代价。还有一个坑图片章节。有些书的某些章节是图片形式比如插图页、或者是纯图片排版的番外转 PDF 时如果处理不当这些页面会丢。我一般会在转换前先把图片全部下载到本地确认数量对得上再开始转。3.5 HTML 与 Markdown为二次加工准备的中间态如果你的目的不是“读”而是“用”——导入笔记软件、做摘录整理、跑文本分析——那这两种才是正解。HTML 的好处是保留了完整的结构标题是h2段落是p你后续想用任何工具解析都方便。Markdown 更轻纯文本、可读性极强扔进任何支持 MD 的笔记工具都能识别。我自己的习惯是每本书生成一个总的 Markdown章节用二级标题正文用普通段落。这样导入之后笔记软件会自动生成一个大纲跳转非常快。代价是格式信息会丢失。加粗、斜体、特殊的排版效果转换过程中多少会掉一些。如果你在意这些还是用 EPUB如果你只在意文字本身Markdown 就是最舒服的选择。3.6 五种格式横向对比格式排版能力目录支持阅读体验二次加工推荐场景TXT无靠文本约定一般弱快速备份、老设备EPUB强完整好中日常阅读首选AZW3强完整电纸书上最好弱电纸书用户PDF固定有书签屏幕适配差弱打印、分享Markdown弱标题层级编辑友好强笔记、分析看这张表你会发现没有一种格式是全能的。我自己的做法是“一次抓取多格式输出”原始章节数据存一份 JSON然后按需生成 EPUB 和 Markdown 两个版本。EPUB 用来读Markdown 用来搜。这样既不会重复抓取浪费流量也兼顾了两种用途。4. 完整实操从零把一本书落到本地4.1 环境准备与依赖安装先把环境搭起来。Python 建议装 3.9 到 3.11 之间太新的版本某些库还没跟上。虚拟环境按 2.2 节的方式建好之后装这几类依赖网络请求、HTML 解析、编码识别、电子书打包。pip install requests lxml chardet ebooklib beautifulsoup4为什么是这几个requests负责发请求比标准库的 urllib 好用太多会话保持、超时、重试都现成lxml解析 HTML 比正则靠谱正则处理嵌套标签迟早出事chardet用来猜编码碰上非 UTF-8 的页面能救急ebooklib专门处理 EPUB 打包能省掉手动拼 ZIP 的一堆细节beautifulsoup4在结构不规范的页面上更宽容。装完之后先跑个最简单的连通性测试别急着上主程序。这一步很多人跳过结果主程序报错时分不清是网络问题还是代码问题。测法就是请求一个页面打印状态码和长度import requests headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept-Language: zh-CN,zh;q0.9, Referer: https://example.com/ } r requests.get(https://example.com/book/123, headersheaders, timeout15) print(r.status_code, len(r.text), r.encoding)三个请求头的作用得说清楚。User-Agent是告诉对方“我是什么客户端”很多站点对空 UA 或明显的脚本 UA 会直接拒绝Accept-Language影响返回内容的语言版本Referer是来源页有些站点会校验它从站内跳过去才给内容。这三个不是玄学是实打实影响成功率的。4.2 请求层并发、限速、重试三件套这是整个流程里最容易出问题的地方也是决定你“是两小时下完还是两天下完”的关键。先说并发。并发数不是越大越好我实测下来的经验值是3 到 5。低于 3速度上不去高于 8被限流的概率急剧上升反而更慢。做个简单估算假设一本书 600 章单章平均响应 0.6 秒串行需要 360 秒并发 4 的情况下理论上是 90 秒但考虑到实际网络抖动和重试真实耗时大概在 150 到 200 秒之间。这个数字比盲目开到 20 并发然后被限流卡死要靠谱得多。再说限速。光限制并发还不够因为并发 4 意味着瞬时可能有 4 个请求同时打过去某些站点对“短时间窗口内的请求数”很敏感。稳妥的做法是加一个固定间隔每个请求发出后至少间隔 0.3 到 0.5 秒。这会让总耗时上升但成功率会明显提高。我一般把它做成可配置的先跑 50 章看看成功率再决定要不要调。重试策略这边建议用指数退避。第一次失败等 1 秒第二次等 2 秒第三次等 4 秒最多重试 3 次。这样做的逻辑是如果对方只是瞬时抖动短暂等待就能恢复如果是持续限流等待时间逐次拉长能给你留出“冷却”的窗口。常见的错误是固定间隔重试一秒一次连打十次等于主动告诉对方“我在刷”。import time, random def fetch(session, url, retries3): for i in range(retries): try: r session.get(url, timeout15) if r.status_code 200: return r.text if r.status_code in (429, 503): time.sleep((2 ** i) random.uniform(0, 0.5)) continue except Exception: time.sleep((2 ** i) random.uniform(0, 0.5)) return None这段里那个random.uniform(0, 0.5)是刻意的加一点随机抖动避免多个线程在同一时刻集体重试形成新的尖峰。4.3 解析层章节列表与正文清洗拿到页面之后要做两件事解析出章节列表、从每个章节页里抽出正文。章节列表这一关坑主要集中在分页和倒序上。有的书目录分了好几页只解析第一页会漏掉大半有的平台把最新章排在前面直接按顺序拼会得到一本倒着写的书。处理办法是先解析出总数再循环翻页最后按章节序号重新排序——注意是按序号排不是按页面上的出现顺序排。序号本身也要处理因为可能混着“第12章”“第十二章”“Chapter 12”等各种写法我的做法是统一转成阿拉伯数字转不了的保留原样但标记出来方便事后人工看一眼。正文抽取这边先用选择器定位到正文容器再逐段取文本。这里有个非常实用的原则宁可多留不要错杀。因为清洗规则写得太激进很容易把正文里的对话段落也删掉。我的流程是三段式先做白名单式提取只从明确的内容容器里取不碰页面其他区域这一步就把导航栏、推荐位、评论区的绝大部分噪音挡住了。然后做行级过滤删掉完全匹配某些固定模式的短行比如“本章未完”“点击下一页”“请记住本站”“手机用户请浏览”。这些模式要写得足够具体别用宽泛的关键词匹配否则正文里出现“下一页”这个词也会被误删。最后做去重有些站点会在章节末尾重复一遍开头的段落用正文的前后几十个字符做哈希比对重复的直接砍掉。提示清洗规则一定要用至少 20 章做回归测试。我见过一个案例规则里写了“删除包含‘推荐’的行”结果那本书里有个人物叫“推荐长老”一整段剧情被删得干干净净。4.4 合并与元数据目录、封面、编码章节数据都拿到之后先落一份原始 JSON再生成各种格式。这一步容易被跳过但它的价值在出问题的时候会体现出来——如果 EPUB 打包出错你不用重新抓一遍直接从 JSON 重新生成就行。JSON 的结构建议是这样一个对象包含书籍级的元信息书名、作者、简介、封面地址、来源标识、抓取时间加上一个章节数组每个章节有id、index、title、content纯文本、html可选。元信息里封面值得单独说。封面图要下载到本地并与书一起打包不要只存个远程链接——链接会失效而且很多阅读器在离线状态下不会去加载远程图片。下载之后检查一下文件头确认确实是图片格式有些站点在图片地址失效时会返回一张很小的占位图你不检查的话书库里就会多出一堆灰色方块封面。编码这一步统一转 UTF-8 是必须的。转换过程中顺手做两件事把全角空格替换成半角某些平台的缩进是用全角空格堆的转成 EPUB 后会被当成正文内容把连续三个以上的换行压成两个保持段落感又不至于空一大片。4.5 生成与校验EPUB 打包和入库命名用ebooklib打包的基本流程是创建 Book 对象、设置元数据、逐章添加 XHTML 项、设置目录、写文件。这里有两个必须注意的点。第一每个章节的 XHTML 必须是完整文档要有?xml version1.0 encodingutf-8?声明、有html根元素、有正确的命名空间。只写一个div片段塞进去部分严格的阅读器会直接报错。第二文件名的排序。阅读器有时候会按文件名排序如果你的章节文件名是chap1.xhtml、chap10.xhtml、chap2.xhtml这种顺序就乱了。解决办法是补零统一成chap0001.xhtml这种四位数格式。打包完之后三件事做校验。一验大小一本 600 章的中文小说纯文字 EPUB 一般在 1.5 到 3MB 之间如果只有 200KB大概率是章节没进去。二验目录用阅读器打开点目录看能不能跳到对应章节、跳过去内容对不对。三验乱码随机翻三五章确认没有问号方块。这三步加起来不到两分钟能挡住八成的问题。入库命名我用的是一套固定模板书库/ 作者名/ 书名 - 作者名.epub 书名 - 作者名.md meta.json用“作者/书名”两层目录是因为书多了之后按作者找比按书名找快得多。文件名里带作者名是为了防止同名书覆盖。meta.json里存抓取时间、章节数、来源标识以后做增量更新时直接读它不用再解析文件名。5. 常见问题与排查速查表5.1 抓取阶段的高频故障返回 403 或直接空内容。九成是请求头的问题。按可能性排序UA 缺失或被识别、Referer 不对、缺少必要的 Cookie。排查方法是先用浏览器正常打开同一页面把请求头逐个对照缺哪个补哪个。如果浏览器能开、脚本不能基本可以确定是请求头差异。章节列表只拿到一部分。先确认目录是不是分页的再确认是不是懒加载——有些页面的目录在初始 HTML 里只有前 20 章剩下的靠滚动触发接口加载。这种情况要去网络面板里找那个真实的数据接口直接请求它。部分章节正文是空的。可能是选择器写错了页面结构改版也可能是这一章本身是图片形式。判断方法是把原始 HTML 存下来看一眼如果是img标签而不是文字那就是图片章节得走下载图片再嵌入的流程。跑着跑着突然全部失败。典型的限流。表现是成功率高一阵子之后断崖式下跌。这时候别硬刚停十分钟再跑同时把并发降到 2、间隔加到 1 秒。5.2 转换与阅读阶段的坑EPUB 打开提示文件损坏。按可能性排查mimetype是不是第一个文件、是不是用了存储而非压缩、container.xml路径对不对。这三条占了绝大多数的损坏原因。目录能显示但点了跳不过去。检查content.opf里的 manifest 和 spine 是否一致——manifest 里声明了但 spine 里没列的文件阅读器不会加载反过来 spine 里列了但 manifest 里没声明的直接报错。中文显示成方块或问号。源文件编码没统一或者 XHTML 里声明的是iso-8859-1。统一在 XHTML 头部写meta charsetutf-8/并且确保写入文件时用的确实是 UTF-8。图片全部丢失。检查图片是不是只存了远程链接。EPUB 是离线格式远程图片在多数阅读器里不会加载必须下载到本地并加入 manifest。电纸书上翻页很卡。单章节文件太大或者 CSS 太复杂。把每章拆成独立文件、精简样式表能明显改善。5.3 稳定性与性能问题跑批量任务最容易遇到的是内存增长。原因是把整本书的所有章节内容都攒在内存里再统一写盘。600 章纯文本大概几十 MB倒也不至于爆但如果同时跑多本、或者正文里带大量图片就会出问题。解决办法是分阶段落盘抓完一章就追加写到一个临时文件最后再统一读回来组装。另一个是长任务中断。跑了两小时网络一抖脚本挂了前面的都白干。这个必须做断点续传——每完成一章就往一个进度文件里记一行重启时先读进度文件跳过已完成的。实现成本很低收益极高。还有一个隐性问题系统休眠导致任务假死。笔记本合盖之后网络断了脚本卡在某个请求上超时设得又长看起来就是“不动了”。把超时设成 15 秒、并且关掉休眠或者在计划任务里设置“唤醒执行”都能规避。现象最可能的原因处理方式403 / 空响应请求头不全对照浏览器补 UA、Referer、Cookie目录缺章分页或懒加载找真实数据接口循环翻页正文为空选择器失效或图片章存原始 HTML 检查结构中途全部失败触发限流降并发、加间隔、冷却十分钟EPUB 报损坏mimetype 不合规首个文件、存储不压缩目录跳转失效manifest/spine 不一致核对两处清单中文乱码编码未统一全链路 UTF-8去掉 BOM图片丢失只存了远程链接下载本地并注册进 manifest内存飙升全量攒内存分阶段落盘任务中断白跑无断点续传逐章记进度重启跳过6. 几条实操心法与边界6.1 先把边界想清楚再谈技术这部分我得说在前面因为它比任何代码都重要。这类工具的使用场景本质上是把你有权阅读的内容做一份本地副本用于自己的离线阅读和长期保存。它不应该被用来绕过付费、批量分发、或者搭建任何形式的对外分享服务。具体到操作上我的自我约束有这么几条。只处理自己已经能正常阅读的内容不去碰需要额外权限才能看的章节导出的文件只存本地不上传到任何公开位置书库里不放超出个人使用范围的数量如果某个内容明确标注了禁止下载那就不做。这些不是技术限制是使用者的自觉。还有一点值得提不要为了“完整”去抓取整站。技术上做得到但没有意义而且会给对方服务器带来不必要的负担。我的原则是“要哪本抓哪本”抓完就停不做全站扫描。6.2 书库的长期维护比抓取本身更费心书抓下来只是开始真正麻烦的是三年后你还能不能找到、能不能打开。我的做法是三层防护。第一层是命名规范前面说的“作者/书名 - 作者名.epub”这套规则一旦定下来就别改改一次全库都要重命名很痛苦。第二层是校验记录每本书生成时算一个文件哈希写进meta.json。以后怀疑文件损坏重新算一次对比就知道。第三层是定期抽查每隔几个月随机打开几本书翻两章确认还能正常读。硬盘损坏、同步盘冲突、误删这些问题都是悄无声息发生的不抽查你根本不知道。另外还有一个我踩过的坑增量更新时的章节错位。有本书中途改版原来的第 300 章被拆成了两章序号全往后错了一位。如果你的增量逻辑是“比对最大序号”就会漏掉内容。稳妥的比对方式是章节 ID 加标题加正文哈希三者结合任何一个变了就当作新章节重新抓。这样做成本高一点但不会漏。6.3 几个我用了很久的小技巧先跑 20 章再全量。这个习惯帮我省了大量时间。20 章能暴露九成的问题选择器对不对、编码有没有问题、清洗规则会不会误伤、限流会不会触发。确认没问题再放开跑比跑了一半发现全错要划算得多。保留原始 HTML。调试阶段把每个章节的原始页面存一份出了问题不用重新请求。跑通之后可以关掉这个开关节省空间。多格式输出但只抓一次。原始数据存 JSONEPUB 和 Markdown 都从 JSON 生成。这样你想换格式、想改排版、想重新打包都不用再走一遍网络。配置文件里加个 dry-run 开关。打开时只打印将要做什么不实际发请求、不写文件。改完参数先 dry-run 看一眼能避免很多低级错误比如把输出目录写成了根目录。给输出目录加个时间戳子目录比如2024-06-01/。这样每次全量重跑都是一个独立的快照出问题能回滚也不会覆盖掉之前的版本。这套流程我用了挺久从最早的手动一章章复制到现在的脚本化批处理中间踩的坑基本都写在上面的表里了。真正有价值的从来不是某个工具而是对“请求怎么发、内容怎么清洗、文件怎么组织”这几件事的理解——工具会过时这套思路不会。