爬虫这东西做技术的人多少都动过念头想抓点数据练练手。但要真落地下来的多半是栽在网站结构复杂、登录校验、分页规则乱七八糟这些事上。前阵子我接了个需求要把某个小说站的全站书籍信息抓下来做内容分析大概几万本书的量级。当时选型的时候我直接定了Java生态里的WebMagic没多犹豫。WebMagic胜在轻量、组件化设计清晰四个核心组件各管一摊改起来非常顺手比用HttpClient手搓解析、再自己搞线程池要省太多事。这篇文章我把整个实战过程拆开揉碎讲一遍从选型、环境准备、核心代码思路到反爬应对和数据落地每一步都是稳的希望能帮你少踩几个坑。1. 项目整体设计与思路拆解1.1 核心需求解析说“爬取小说网站所有小说”听起来挺简单但真正落成工程实现其实包含三个层次全站书籍的URL收集包括书名、作者、分类、字数、状态连载/完结等元信息。每本小说的详情页数据补齐比如简介、封面图链接、最新章节。数据按可查询、可分析的结构化方式存储方便后续做搜索或统计。如果抓完只是一股脑存进文本文件里那基本等于没做。数据的结构化程度直接决定后续能不能用起来。另外虽然需求强调“所有小说”实践中不能真的一次性把所有URL全压进队列那样会触发对方服务器的防护容易被打回。合理的设计应该是分批调度断点续爬先跑通一个分类的一小部分验证解析规则无误后再扩大范围。1.2 为什么选WebMagic而非Scrapy或其他方案选型这事我简单说下当时的对比其实很能说明问题Python的Scrapy生态好文档多异步效率高但需要单独部署Python环境且Scrapy的组件定制对新手不太友好。如果团队本身就是Java栈引入Scrapy等于引入第二套语言体系。Java原生HttpClientJsoup灵活但所有逻辑都要自己编排。爬虫最怕什么不是抓不到数据是抓取过程中断后不知道从哪里继续。自己实现去重、调度、失败重试代码量会膨胀得很厉害。WebMagic本身就是Java写的和业务系统无缝集成。下载、解析、调度、持久化四层分离内置了URL去重、多线程抓取、代理支持。页面上提取数据用XPath和CSS选择器都行非常直观。所以选WebMagic是贴合团队技术栈和快速落地需求的合理决策。当然这不代表Scrapy不行完全看场景。1.3 全站抓取的整体架构下面是我实现时的整体模块划分模块职责关键技术点调度模块控制分类页、列表页、详情页的URL调度去重队列、抓取优先级下载模块获取页面内容模拟UA、代理切换、超时重试解析模块抽取页面中的字段XPath、CSS选择器、正则持久化模块存储到数据库MyBatis-Plus批量插入监控模块记录成功/失败数异常告警日志统计、失败重试队列可视化地理解整个系统像一条流水线调度模块管“零件排单”下载模块管“原料进货”解析模块管“加工质检”持久化模块管“成品入库”。每一条链路解耦任何一环挂了都能单独重启修复。2. 核心细节解析与实操要点2.1 WebMagic四大组件原理解析WebMagic的核心架构围绕以下四个组件展开这是要弄透彻的底层知识Downloader负责从网络抓取页面。默认的HtmlUnitDownloader或HttpClientDownloader都可配置。实际操作中我一般自定义Downloader设置请求头、cookie、代理池。尤其什么场景需要自定义当遇到某个站需要带特定Header返回JSON而不是HTML或者需要先访问首页种Cookie才能继续的时候。PageProcessor这是大家动手最多的部分。它负责解析页面、发现新URL并提交待抓取请求。WebMagic用轻量的XPath语法配合CSS选择器测试起来非常方便。切记PageProcessor不负责下载、不负责存储别把业务逻辑堆在这里会乱。Scheduler负责URL队列的管理。默认的QueueScheduler基于内存重启全丢。如果需要断点续爬就得自己实现基于Redis的Scheduler。这个我在后文实操中细讲。Pipeline负责结果持久化。可以输出到控制台、文件、数据库也可以把数据进行二次加工后发送给消息队列。Pipeline设计成独立模块后换存储方式的时候完全不用动PageProcessor里的逻辑。这四个组件之间的关系用一句话概括Scheduler给Downloader提供URLDownloader拉回HTMLPageProcessor从HTML里提取数据和链接提取出的数据交给Pipeline发现的新链接又交还Scheduler。循环往复直到队列为空。2.2 请求头与模拟浏览器行为爬虫第一课就是学会“伪装”成正经用户。门户小说站基本都有基本的安全校验——User-Agent检测、Referer检测、访问频率检测。实操时我用了一套比较稳定的请求头配置User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8 Accept-Language: zh-CN,zh;q0.8,en-US;q0.5,en;q0.3 Referer: 目标网站首页 Connection: keep-alive这里面最关键的是Referer。很多站点会校验请求的来源页面Referer不正确直接返回403。还有一种情况是后端返回压缩数据需要在请求头声明Accept-Encoding: gzip不然可能拿到乱码。2.3 线程数与请求频率控制爬虫写好了冲劲太大转眼就把对方服务器打挂了这种教训我见得太多。控制请求频率是必备的工程意识。WebMagic默认支持多线程通过Spider.thread(n)设定。但这个n不是越大越好得结合目标站点的响应速度和自身机器的带宽来确定。一个我常用的保守配置线程数4~8个。每个线程请求间隔200~500毫秒。抓取失败重试1次重试仍然失败就放弃并记录URL。为什么是这个范围简单算一笔账8线程每线程400毫秒间隔1秒约能发出20个请求一小时是72000个请求。对于中小型小说站这个频率已经在风控边缘了不能再快。如果你要抓的数据量特别大宁可拉长时间线分批跑也别追求一次性搞定。2.4 数据去重策略全站抓取最忌讳重复下载同一页面。既浪费带宽又容易触发反爬。WebMagic的Scheduler自带去重功能基于ConcurrentHashMap记录已访问的URL。但这个去重有局限它只认URL字符串。如果同一本书可以通过多个URL访问比如带不同参数那还是会重复。解决思路有两个在生成URL时统一规范化处理去掉utm_source这类统计参数保证同一资源只有一个URL。自定义Scheduler用BloomFilter判重。BloomFilter的优点是内存占用极小几十亿URL也只需要几百MB内存且不会爆。缺点是理论上存在微小误判率但这点误判丢掉的重复页面完全可接受。3. 实操过程与核心环节实现3.1 环境准备与依赖引入首先保证JDK版本不低于8我实际用的是JDK 11。创建Maven工程后引入WebMagic依赖dependency groupIdus.codecraft/groupId artifactIdwebmagic-core/artifactId version0.7.5/version /dependency dependency groupIdus.codecraft/groupId artifactIdwebmagic-extension/artifactId version0.7.5/version /dependency注意WebMagic早期版本对某些网站的TLS协议支持有些问题如果目标网站只支持TLS 1.2或更高建议在启动参数里加上-Dhttps.protocolsTLSv1.2另外引入一个JSON处理库fastjson或Jackson后面解析数据要用。3.2 实现自己的Downloader虽然WebMagic自带了HttpClientDownloader但实际应用里我几乎都会包一层自定义Downloader。原因可以统一埋点记录下载耗时、失败原因以及动态切换代理。public class CustomDownloader extends HttpClientDownloader { Override public Page download(Request request, Task task) { // 设置通用请求头 request.addHeader(User-Agent, Mozilla/5.0 ...); request.addHeader(Referer, https://example.com); // 统计下载耗时 long start System.currentTimeMillis(); Page page super.download(request, task); long cost System.currentTimeMillis() - start; log.info(下载URL: {}耗时: {}ms, request.getUrl(), cost); return page; } Override protected void onError(Request request, Task task) { // 单次下载失败时记录日志为后续重试提供凭证 log.error(下载失败: {}, request.getUrl()); } }这里有个细节值得说如果某个URL连续失败多次说明可能触发了封禁策略此时即使重试也是徒劳反而加重对方服务器压力。所以我会在外部维护一个失败计数Map达到阈值后干脆跳过这个URL最后统一人工检查。3.3 编写PageProcessor解析列表页我抓取的目标网站结构很典型分类页 → 列表页 → 详情页。分类页会把所有小说按玄幻、都市、历史等分成若干频道。列表页的解析代码如下public class NovelListProcessor implements PageProcessor { private Site site Site.me() .setRetryTimes(1) .setSleepTime(300) .setCharset(UTF-8); Override public void process(Page page) { // 解析当前列表页的小说条目 ListSelectable nodes page.getHtml() .xpath(//ul[classbook-list]/li).nodes(); for (Selectable node : nodes) { String title node.xpath(//a[classbookname]/text()).get(); String author node.xpath(//span[classauthor]/text()).get(); String detailUrl node.xpath(//a[classbookname]/href).get(); // 把详情页URL加入待抓取队列 page.addTargetRequest(detailUrl); // 也可以把列表页就有的信息直接存下来 page.putField(title, title); page.putField(author, author); page.putField(detailUrl, detailUrl); } // 翻页处理找到下一页URL String nextPageUrl page.getHtml() .xpath(//a[classnext]/href).get(); if (nextPageUrl ! null) { page.addTargetRequest(nextPageUrl); } } Override public Site getSite() { return site; } }解析过程中有两个容易踩的坑第一XPath写错导致字段为空。新手最容易犯可以先在浏览器Console里用$x()测试XPath确认能取到值再写进代码。第二下一页判断条件不对导致死循环或漏抓。有的网站下一页链接是“javascript:void(0)”有的到了最后一页仍然显示“下一页”但链接指向当前页。这里一定要判断获取到的URL和当前URL是否相同如果相同就不要再加入队列了。3.4 解析详情页并处理动态内容详情页的内容相对固定书名、作者、分类、简介、字数、状态、封面图、最新章节列表。解析代码可以直接复用上面的模式但小说详情页有时会用到JS渲染数据直接抓HTML是拿不到的。遇到这种情况我一般先用浏览器开发者工具刷新页面看网络请求里有没有返回JSON格式数据的XHR接口。如果有直接请求那个接口拿结构化数据比解析HTML省力一百倍。接口数据通常是如下格式{ bookId: 12345, title: 书名, author: 作者, description: 简介, category: 玄幻, words: 1234567, status: 连载中, lastChapter: 第100章 }在PageProcessor里收到这种JSON拿到JSON对象后按Key取值就行。WebMagic的Page对象里也能直接获得响应内容用page.getJson()去解析。讲道理会看XHR接口是爬虫进阶的第一课。很多时候页面数据显示出来了但不在HTML源码里如果不知道去看接口硬啃JS渲染逻辑会落后一大截。3.5 实现Pipeline持久化到数据库数据解析完就到了落库环节。Pipeline是WebMagic里干这事的标准位置。我的存储用了MySQL建了一张novel_info表核心字段如下字段名类型说明idbigint自增主键book_idvarchar(32)外部ID用于去重titlevarchar(128)书名authorvarchar(64)作者categoryvarchar(32)分类statustinyint1连载 2完结wordsint字数introtext简介cover_urlvarchar(512)封面链接last_chaptervarchar(128)最新章节create_timedatetime入库时间Pipeline里做批量插入核心点在于去重不同章节页面可能重复抽取到同一本书的信息如果每次都insert就会产生大量重复数据。简单方案是insert前先按book_id查一下但高并发下查询压力不小。我后来改用insert into ... on duplicate key update配合数据库对book_id的唯一索引天然解决了并发重复插入。public class NovelPipeline implements Pipeline { Override public void process(ResultItems resultItems, Task task) { String bookId resultItems.get(bookId); if (bookId null) { return; } NovelInfo novel new NovelInfo(); novel.setBookId(bookId); novel.setTitle(resultItems.get(title)); novel.setAuthor(resultItems.get(author)); novel.setCategory(resultItems.get(category)); // 省略其他字段赋值 saveOrUpdate(novel); } }3.6 支持断点续爬的Scheduler内存版Scheduler在爬虫跑了几万条后一旦程序挂掉记录全部丢失得从头再来。这种痛我经历过一次就长记性了。断点续爬的核心方案是把Scheduler里的队列和去重集合持久化到Redis。public class RedisScheduler implements Scheduler { private Jedis jedis; private static final String QUEUE_KEY spider:queue; private static final String SET_KEY spider:visited; Override public void push(Request request, Task task) { if (!jedis.sismember(SET_KEY, request.getUrl())) { jedis.rpush(QUEUE_KEY, request.getUrl()); } } Override public Request poll(Task task) { String url jedis.lpop(QUEUE_KEY); if (url ! null) { jedis.sadd(SET_KEY, url); return new Request(url); } return null; } }这个方案的效果Redis的List负责队列Set负责去重。程序重启后从Redis里接着消费未处理的URL不需要重头抓取。缺点是要额外维护一个Redis实例但对工程化项目来说这成本花得值。有一点要特别说明去重时机要设计准确。我上面的做法是poll出来就加入Set如果程序在处理时崩了这个URL就永远丢失了。更稳妥的做法是等数据成功入库后再加入Set但这又可能因为重复抓取产生重复入库。实际项目里我采用了折中方案——入库用唯一索引兜底Set去重允许有误差保证不漏数据就行。4. 常见问题与排查技巧实录4.1 请求超时与连接池耗尽小说站页面多单线程下载速度慢多线程又容易把连接池打满。默认HttpClient的连接池上限是有限额的一旦目标站响应慢大量请求堆积在池子里等待就会出现连接池耗尽报错。解决办法调大连接池的核心连接数设置setMaxConnections(100)每个路由的最大连接也调高一些。设置合理的socket超时时间比如5秒没响应就放弃别傻等。下载线程数量和连接池上限要匹配线程数高于连接池上限会直接卡死。4.2 反爬虫的常见手段与应对第一个是IP封禁。表现就是爬着爬着突然大量403或502。应对方案主要是代理IP池。WebMagic里可以设置代理Provider用的时候从池子里轮询取一个IP。但要注意免费代理的稳定性很差经常用了比不用还差。如果只是学习目标站的反爬强度通常不高控制频率就够用了。如果是真正跑大批量数据建议准备付费代理池并且做代理质量检测——每次拿到代理先发一个测试请求通了再正式用。第二个是验证码。这种一般是WebMagic网络层的极限了常规手段是接入打码平台或OCR识别。说实话如果目标站上了验证码建议评估下法律边界和成本是否值得继续。有些数据可能通过官方API拿更方便。4.3 数据解析结果为空的排查路径解析结果为空是爬虫开发中最高频的问题。我的排查顺序是确认页面内容是否真实下载成功在PageProcessor里打日志输出page.getHtml().toString()前200个字符看是不是意料中的HTML片段。确认页面是否属于JS渲染如果看到一堆script标签就是没有正文内容基本可以断定是JS渲染。此时需要找XHR接口或者用浏览器渲染工具。在浏览器调试控制台验证XPath用document.evaluate或$x指令跑一遍XPath能取到值说明路径没问题问题出在代码取不到说明路径写错。检查是否有iframe嵌套有些小说网站把正文放在iframe里页面HTML里只看到一个iframe标签。这时候得单独下载iframe的src属性指向的URL。4.4 抓取速度越来越慢的问题这通常不是网络问题而是程序内部出问题。最常见的是Scheduler队列越来越大内存占用膨胀GC频繁。如果用的是内存版Scheduler随着URL数量增加Set里去重数据越积越多内存压力会很明显。排查思路用jstat命令看GC情况如果Full GC频繁八成是内存不够了。检查是不是某类URL持续在入队但出队消费跟不上。可能是解析环节有问题走进了死循环抓取了一个无止境的翻页列表。如果确认逻辑没问题就切换到Redis版Scheduler把去重集合外置内存压力立刻缓解。4.5 常用命令与监控手段爬虫跑批任务我会用一个简单有效的监控面板辅助观察SQL实时统计每分钟select count(*) from novel_info观察数据增长速度是否符合预期。如果增速突然降为0赶紧去查日志。日志关键字告警写一个简单的日志扫描脚本对ERROR、download fail这些关键字做告警。不用太复杂Linux的grep配合crontab定时跑一下就够了。失败URL收集所有重试仍失败的URL统一写进一张fail_url表跑完之后人工看一下这些URL是解析规则的问题还是该页面确实有特殊结构针对性修复。5. 数据延展与规范化思考5.1 从“爬下来”到“用起来”的最后一公里数据入库只是第一步。小说数据最典型的价值场景是聚合检索和趋势分析按分类看作品数量分布、按作者看产量情况、按字数区间看完本率。这些查询都依赖落地时的数据质量。比如分类字段如果不同爬虫批次抓下来的分类名称不统一有的叫“玄幻”有的叫“玄幻奇幻”后面做统计就会很痛苦。所以入库前要做一层轻度清洗分类映射到统一枚举字数规范为整型状态字段区分连载和完结。这一步放数据库里做也行但影响查询性能。我推荐在Pipeline里做统一清洗Pipeline里拿到的数据是脏的洗完再交给DAO层。5.2 更新策略与增量抓取全站抓取完成后网站还在不断更新不可能每天全量跑一遍。增量更新策略很简单以“更新时间”为维度每天只抓取最近24小时内有变化的小说详情页。小说网站一般有更新时间排序的列表页爬那个列表页的URL即可。思路是每天定时任务启动一次增量爬虫。增量爬虫的起始URL指向“最近更新列表”页。更新列表页里的每本书都进详情页解析更新的字段直接更新入库。这样日常维护的成本很低服务器压力也小。5.3 合规使用的边界提醒做爬虫这行技术本身是中性的但运营时必须守住几条边界严格遵守目标网站的robots协议。请求频率控制到“不给服务器造成压力”的程度。抓取到的数据如果用于商业用途必须提前确认版权和数据授权。我见过太多人因为一时贪快、贪数据量大结果收到法务函甚至被起诉。技术能解决“能不能爬到”的问题但不能解决“该不该爬”的问题。这条底线希望大家一定守住。6. 进阶优化与踩坑经验总结6.1 自定义注解配合管道实现通用爬虫框架当爬的网站不只一个时每个站写一套PageProcessor代码重复度会很高。我尝试过的进阶方案是用注解定义页面模型把字段映射关系抽出来解析逻辑通用化。TargetSite(domain example.com, startUrl https://example.com/all) public class NovelPage { SelectByXPath(//h1[classbook-name]/text()) private String title; SelectByCss(.author) private String author; }反射读取注解自动生成XPath/CSS解析代码数据直接填充到对象里。这套框架在面对多站点采集时维护成本极低新增一个站点只需要写一个Java类。不过说实话如果只是临时跑一批数据没必要上这个复杂度手写PageProcessor就够了。6.2 定时任务管理与资源释放我用Spring框架托管爬虫生命周期。具体做法把爬虫定义成Spring Bean。用Scheduled注解启动定时任务。每次跑完关闭Spider对象释放线程池和HTTP连接池。这里有个容易忽略的点Spider内置的线程池和HTTP连接资源用完必须回收。如果不回收连续跑几次定时任务后可能因为连接没关闭导致句柄泄漏。我是用spider.close()来释放同时调httpClient.getConnectionManager().shutdown()关闭连接池。经验是写成一个后置销毁方法每次任务结束自动调用别靠人肉记。6.3 个人实操心得写代码抓数据这些年我总结下来最重要的一条经验先小后大先慢后快。别一上来就把整个网站塞进队列先用一两个分类跑通流程验证解析、入库全部正常后再扩大范围。跑大批量的时候定时看日志比盯着页面更有效尤其要看“解析成功率”这个指标。如果成功率从95%掉到80%大概率是触发了反爬或者页面结构发生了变化。这时候赶紧暂停查清楚再继续别硬跑。还有一点关于开发效率网页结构经常改最好把解析规则外置成配置文件或数据库不要硬编码在代码里。这样网站结构调整了改配置就能恢复不用改代码重新部署。我为这个吃过一次亏从此以后所有爬虫的XPath规则都放配置中心。WebMagic这个框架用好了等于手里握着一把趁手的工兵铲能稳稳当当地把数据挖出来。它不花哨但工程结构和可扩展性在同级别框架里算是很扎实的。如果你正在为全站数据采集发愁按着上面这套设计和流程来能省下不少自己试错的时间。最后再分享一个小技巧爬虫跑完一批后别急着删日志。找几个代表页面的HTML存下来留着以后网站改版时对照排查你会感谢自己这个习惯的。