简介针对百度新闻与今日头条的Java新闻爬虫项目资源围绕“按关键词抓取新闻并落库”的真实场景设计面向Java初、中级开发者可帮助学习网络数据采集与存储的完整链路。压缩包共20个文件其中16个为Java源码覆盖URL收集、网页请求、内容解析、数据入库等爬虫核心模块另含pom.xml及properties配置文件便于通过Maven快速还原构建与运行环境README则提供项目说明与使用指引。整体仅19KB代码结构精简适合直接导入Java工程阅读、调试或二次改造。通过关键词配置可以灵活抓取不同主题的新闻并将结构化结果写入数据库便于后续检索或分析。目前已有448人学习下载尤其适合希望从零搭建新闻聚合爬虫、理解反爬与访问频率控制思路的开发者。资源中对无法运行或部署场景给出了退款与付费协助说明既能作为入门阶段的练习素材也可为实战项目中的异常处理提供参考。1. 一个能跑通的关键字新闻爬虫百度新闻、今日头条与数据库落地的完整链路拿到这个名为“百度新闻今日头条爬虫根据关键字爬取所有新闻并存如数据库”的压缩包时我的第一反应是“又一个只贴代码不保证跑通的仓库货”。解压之后发现结构比我预想的干净SJT-code 目录下是完整的 Maven 工程pom.xml、src/main、README.md 都在不是零散片段。按 README 把数据库和关键字配好打包运行它能按关键字从百度新闻和今日头条抓取标题、链接、来源、发布时间和正文写进 MySQL。对想省掉造轮子时间的后端工程师、数据采集需求方、做新闻聚合或舆情监控的人来说这份资源最值钱的地方在于它把“关键字 → 新闻源 → 解析 → 数据库入库”这条完整链路串了起来而不是只教你怎么发一个 HTTP 请求。适合动手前想先看到全貌的人下载复现也适合给团队做数据底座的初版原型。2. 先把项目拆开看SJT-code 目录结构与运行前提2.1 Maven 工程与入口类定位解压后你会看到这样一份顶层结构SJT-code ├── pom.xml ├── README.md └── src └── main ├── java └── resources这是个标准 Maven 工程不是 IDE 向导生成的花架子。我一般先看 pom.xml 确认 JDK 级别和依赖再看 src/main/java 下找入口类。爬虫工程的入口类通常命名带 Application 或 Main 后缀main 方法里做的事一般分三段读配置文件、初始化数据库连接池、启动关键字队列。对照 README 能找到启动参数格式比如java -jar sjt-code.jar 关键字1 关键字2也有工程把关键字写在配置文件里启动时不传参。这份资源的 README 写得不长但运行前提写清楚了需要有 MySQL 实例、Maven 环境和 JDK。如果 pom 里编译级别是 1.8我建议就用 JDK 8 或 11 跑别直接上 17老版本依赖在模块化环境里经常报非法反射访问警告。先跑一次编译把依赖拉齐mvn clean package -DskipTests逻辑说明clean清掉旧编译产物package完成编译、跳过测试、打包三步。-DskipTests表示跳过测试用例因为这类爬虫工程绝大多数不写测试硬跑测试反而会因连不上外网失败。参数说明如果本地 Maven 仓库缺依赖可以加-U强制刷新 snapshot 与远程索引首次构建会慢一些但能避免拉到损坏的半成品依赖。2.2 数据库连接配置与初始表准备数据库配置集中在 resources 下的配置文件里常见做法是 properties 或 yml。核心配置项就四个JDBC URL、用户名、密码、驱动类名。我在拆包时重点看连接串的编码参数很多运行不了的问题都出在这一行。jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://127.0.0.1:3306/crawler_news?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.passwordyour_password逻辑说明useUnicodetrue和characterEncodingutf8是中文新闻落库的关键少了它标题进库后基本是???。serverTimezoneAsia/Shanghai解决 MySQL 8 驱动和本地时区不一致导致的报错。参数说明useSSLfalse仅用于本地开发环境如果数据库服务器强制 SSL需要换成对应证书配置rewriteBatchedStatementstrue也可以提前加上后面讲批量入库时会用到。初始化 URL 队列时这个工程会根据关键字拼接新闻源搜索地址而不是只爬固定首页。这种设计的合理性在于新闻网站首页内容每天变但搜索接口的 URL 格式相对稳定换成任意关键字都能跑。队列初始化时还会做一次去重把相同关键字组合过滤掉避免同一批 URL 重复消费。2.3 依赖选型JSOUP 加 JDBC够用且抗折腾打开 pom.xml 主要看三个依赖HTTP 客户端、HTML 解析器、数据库驱动。这个工程没有引入重量级框架走的是轻量路线。dependency groupIdorg.jsoup/groupId artifactIdjsoup/artifactId !-- 版本建议对齐你自己的 JDK 环境1.15 以上均可 -- /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId !-- 8.0 系驱动连 MySQL 5.7 和 8.x 都兼容 -- /dependency选择 Jsoup 而不是 HttpClient 加正则是因为新闻页面结构普遍规整Jsoup 的 CSS Selector 能直接按 class 或标签层级取节点比正则逐条匹配快得多也抗页面微调。MySQL 驱动版本尽量和数据库大版本对应老驱动连 MySQL 8 会报认证插件错误。这个选型说明作者目标明确快速跑通不整花活。我在拆解时还注意到如果 pom 里再引入commons-lang3说明字符串清洗走了工具类而不是手写正则这类工程在标题去空格、去换行符上通常更稳。依赖不在多够用就好这份资源的选型明显是奔着“生产可用”去的。3. 关键字驱动抓取主流程URL 拼接、请求调度与解析兜底3.1 百度新闻与今日头条的搜索 URL 构造差异从 URL 构造就能看出这个工程对两个新闻源做了差异化处理。百度新闻的搜索地址简单直接把关键字放进查询参数再按分页偏移量翻页今日头条则要同时处理接口来源和页面来源。public static String buildBaiduNewsUrl(String keyword, int page) { String encodedKeyword; try { encodedKeyword URLEncoder.encode(keyword, StandardCharsets.UTF_8.name()); } catch (UnsupportedEncodingException e) { throw new RuntimeException(关键字编码失败, e); } return https://www.baidu.com/s?tnnewsword encodedKeyword pn (page * 10); }逻辑说明tnnews是百度新闻搜索的固定参数word是关键字pn是结果的偏移量。百度新闻每页固定 10 条所以第 2 页的 pn 是 10第 3 页是 20这个分页算法写死到代码里反而最不容易错。参数说明URLEncoder.encode必须显式指定字符集不指定的单参方法已过时且在不同 JDK 版本下默认字符集不同中文关键字最容易被坑在这。今日头条的搜索入口长这样public static String buildToutiaoSearchUrl(String keyword) { String encodedKeyword URLEncoder.encode(keyword, StandardCharsets.UTF_8.name()); return https://so.toutiao.com/search?dvpfpcsourceinputkeyword encodedKeyword; }逻辑说明头条搜索支持sourceinput表示用户手动输入关键字服务端对这个参数的校验比纯程序化请求宽松一些dvpfpc指定 PC 端页面。这个入口是网页版搜索不是内部接口稳定性比内部接口好因为内部接口随时加签名。我一般会在请求头里加Referer: https://so.toutiao.com/和Accept: application/json这两个值能显著降低被拦的概率。头条页面的特殊性在于搜索结果列表里能拿到标题和文章 ID但正文经常是异步加载的直接抓 HTML 拿不到完整正文。所以工程里对头条的处理比百度多一步先分析返回的 JSON 片段拼出详情页 URL再二次请求补正文。这也是为什么同一套代码里两个新闻源的请求方法不能完全复用——不是不想复用是目标站点的数据结构和渲染方式本来就不一样。3.2 请求执行、超时重试与访问节奏爬虫跑不稳的绝大多数原因是请求调度没做好。这个工程在调度层做了三件事固定延迟、超时重试、已处理 URL 过滤。这部分是网络爬虫原理里最经典的处理顺序URL 收集、请求网页、解析内容、数据存储每一步都要考虑失败的情况。public String fetch(String url) { int retryTimes 0; while (retryTimes 3) { try { Connection.Response resp Jsoup.connect(url) .userAgent(Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36) .timeout(10000) .ignoreContentType(true) .execute(); if (resp.statusCode() 200) { return resp.body(); } } catch (IOException e) { retryTimes; try { Thread.sleep(2000L * retryTimes); } catch (InterruptedException ignored) { Thread.currentThread().interrupt(); break; } } } return null; }逻辑说明retryTimes控制在 3 次以内每次失败后延时从 2 秒起步递增避免服务器把连续快速重试当作攻击。ignoreContentType(true)很关键因为新闻接口返回的 Content-Type 经常不规范不加这个会报UnsupportedMimeTypeException。参数说明timeout(10000)是连接加读取的总超时设 10 秒比较合适新闻站点响应慢设 5 秒容易误伤正常页面。请求节奏上我拆的时候发现工程里用的是固定 500ms 延迟。百度新闻对这个频率能接受今日头条偶尔会返回验证码页面。血泪经验是头条源建议把延迟调到 1 秒以上单轮抓取量控制在 200 条以内否则后半程全是验证码页。这个参数对任何搜索引擎都适用跑得慢一点比跑一半断掉强。启动前还应该看一眼目标站的 robots.txtDisallow列出的路径直接跳过。这不是形式主义而是爬虫工程的基本边界感——你抓新闻是去聚合公开内容不是去挑战对方的服务底线。项目正文里也专门强调了遵守 robots.txt 和限制访问频率这份资源在这一点上比很多同类代码自觉。3.3 列表页解析与正文兜底策略列表页解析的样板代码在工程里长这样Document doc Jsoup.parse(html); Elements items doc.select(div.result-op, div.new-panel); for (Element item : items) { Element titleEl item.selectFirst(h3 a); Element sourceEl item.selectFirst(span.c-color-gray); Element timeEl item.selectFirst(span.c-color-gray2); String title titleEl ! null ? titleEl.text().trim() : ; String link titleEl ! null ? titleEl.absUrl(href) : ; }逻辑说明div.result-op和div.new-panel是百度新闻搜索结果里两种历史版本的结果容器两个都匹配是为了兼容老页面。h3 a是标题链接span.c-color-gray是来源span.c-color-gray2是时间。选择器带容错是这套代码能长期跑的基础只写一个选择器页面一改版整条链路就废了。参数说明absUrl(href)会把相对路径拼成绝对 URL比手动拼接安全得多尤其处理//baidu.com/link?urlxxx这种无协议地址时不会丢前缀。正文解析比列表页更依赖站点结构。百度新闻详情页正文一般集中在div.article-text今日头条正文在article.article-content。工程里的通用做法是先尝试多个已知正文选择器全部选不中时回退到取p标签全文拼接把页面上所有段落按顺序连起来。这个兜底策略保证了即使站点改版至少还有一份正文可用不至于整条记录只有标题没有内容。4. 新闻解析与数据库落地字段映射、清洗规则与批量入库4.1 字段映射与来源差异处理百度新闻和今日头条在字段映射上有明显区别。百度新闻搜索结果天然包含来源和时间而且来源是纯文本今日头条则经常返回相对时间比如“3小时前”或“昨天”在字段映射阶段不能直接塞进数据库时间列。来源字段的污染问题也很常见。从百度新闻抓到的来源经常是“新浪(作者:xxx)”这种带括号注解的文本如果直接入库后期按来源做媒体统计时会被括号内容干扰。我在拆包时看到工程里有一段专门处理这个用正则把中英文括号以及里面的内容整体去掉只保留媒体主名称。这类清洗代码看起来不起眼但恰恰是数据可用性的分水岭。如果你之前写 Python 爬虫喜欢用requests加xpath加text()函数来抽文本看这份 Java 工程会觉得思路相似只是 API 换了Jsoup 的select对应 XPathtext()方法对应 Python 里text()函数absUrl对应urljoin。技术栈不同但抓取、解析、入库的骨架是一致的。4.2 表结构设计与字段清洗规则新闻表结构是这份资源里数据库落地的核心。拆包时我看了 SQL 建表语句字段设计基本符合新闻聚合业务的最小需求标题、链接、来源、发布时间、正文、抓取时间、关键字。CREATE TABLE news_article ( id BIGINT NOT NULL AUTO_INCREMENT, keyword VARCHAR(64) NOT NULL COMMENT 抓取时使用的关键字, title VARCHAR(512) NOT NULL COMMENT 新闻标题, url VARCHAR(1024) DEFAULT NULL COMMENT 原始链接, source VARCHAR(128) DEFAULT NULL COMMENT 来源媒体名称, publish_time DATETIME DEFAULT NULL COMMENT 发布时间, content MEDIUMTEXT COMMENT 正文, crawl_time DATETIME NOT NULL COMMENT 抓取时间, PRIMARY KEY (id), KEY idx_keyword (keyword), KEY idx_publish_time (publish_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT关键字新闻抓取表;逻辑说明keyword单独建索引因为按关键字查询是后续分析最常见的维度publish_time建索引是为了按时间段聚合。content用MEDIUMTEXT而不是TEXT因为新闻正文动辄几万字节TEXT上限 64KB 够用但遇到深度报道长文会截断。url字段不建唯一索引是故意的同一篇新闻会被不同关键字重复抓到查询时靠程序层去重而不是数据库报错。入库前清洗是另一个关键环节。清洗逻辑主要处理标题里的换行、制表符、连续空格以及来源字段的括号污染title title.replaceAll([\\r\\n\\t], ).replaceAll(\\s, ).trim(); source source.replaceAll([\\[(].*?[\\])], ).trim();逻辑说明第一行把所有不可见字符统一成单空格防止标题在客户端换行错位。第二行去掉来源名里的“转载”“综合”等括号注解让source字段保持纯媒体名。这类规则看着糙但对后续媒体统计有很大帮助存一堆“新浪(作者:xxx)”比存“新浪”难聚合得多。4.3 批量入库与增量去重入库用批量插入还是单条插入决定了 500 条新闻的抓取耗时差多少。工程里用PreparedStatement的addBatch配合自动提交关闭一次性把一批新闻写进库里。这是数据库增删改查四类操作里最值得优化的一环。conn.setAutoCommit(false); String sql INSERT INTO news_article (keyword,title,url,source,publish_time,content,crawl_time) VALUES (?,?,?,?,?,?,?); PreparedStatement ps conn.prepareStatement(sql); for (NewsItem item : list) { ps.setString(1, item.getKeyword()); ps.setString(2, item.getTitle()); ps.setString(3, item.getUrl()); ps.setString(4, item.getSource()); ps.setTimestamp(5, item.getPublishTime()); ps.setString(6, item.getContent()); ps.setTimestamp(7, item.getCrawlTime()); ps.addBatch(); if (batchCount % 50 0) { ps.executeBatch(); } } ps.executeBatch(); conn.commit();逻辑说明setAutoCommit(false)意味着所有批量语句在同一个事务里要么全成功要么全回滚避免抓了 300 条但库里只落了其中一部分的“半批次状态”。batchCount模 50 的写法是每 50 条刷一次既控制 PreparedStatement 内部缓冲又让单事务不持有过多行锁。参数说明JDBC URL 里建议加rewriteBatchedStatementstrue不加这个参数时 MySQL 驱动会把批量操作拆成单条执行性能至少差一倍。增量去重的逻辑比较简单插入前先按 URL 查一次库有记录就跳过。这依赖列表页能拿到稳定 URL如果抓到的链接是带时效签名的就只能退而求其次按标题前 30 个字符做去重键。注意这个 30 字符的选择不是拍脑袋标题前 30 个字足够区分两条不同新闻又不会因为标题太短误杀同题报道。5. 避坑笔记爬虫跑不起来或抓不到数据时的排查清单5.1 启动报错NoClassDefFoundError 和数据库连不上现象执行java -jar后秒退或报NoClassDefFoundError: org/jsoup/Jsoup。 原因直接mvn package打出的 jar 默认不包含依赖运行时找不到 Jsoup、MySQL 驱动这些第三方类。另一种高发问题是 JDBC 报Communications link failure多半是 MySQL 没开远程访问、密码带#号没在连接串中转义、或者serverTimezone没配。 解决在 pom 里引入maven-assembly-plugin打 fat jar如果不想改 pom用mvn package dependency:copy-dependencies把依赖拷到 target 后再用java -cp target/classes:target/dependency/* 入口类启动。数据库问题先删掉连接串里的特殊字符再逐项核对 IP、端口、库名。5.2 程序启动正常但一个新闻都抓不到现象日志显示请求发出去了返回 200但解析结果为空数组。 原因大部分情况是搜索页改版Jsoup 选择器匹配不到节点少部分是返回了验证码页或安全验证页HTML 里根本没有新闻标签。 解决第一步打印返回 HTML 的前 3000 个字符看是不是验证码页。第二步用浏览器开发者工具手动搜一次关键字找到当前生效的结果节点 class 名更新选择器。如果是验证码页十有八九是请求频率太高把延迟调到 1 秒以上并补全浏览器 User-Agent 和 Referer。不要想着硬刚验证码新闻聚合的场景下低频率加等待页面往往是性价比最高的方案。5.3 中文关键字生成的 URL 乱码导致结果为空现象换成中文关键字后一条结果都没有英文关键字正常。 原因URLEncoder.encode用了默认字符集编码换了 JDK 版本后默认字符集从 UTF-8 变成了别的或者编码后号没有被目标服务端正确解析。 解决指定StandardCharsets.UTF_8.name()编码编码后把替换为%20。更保险的写法是关键字进入 URL 构造方法前统一先new String(keyword.getBytes(UTF-8), UTF-8)过一遍把可能的乱码字符串提前暴露出来。这个坑专坑从 Windows 开发切到 Linux 部署的人IDE 里正常jar 包里乱码。5.4 抓取几十条后速度骤降后续请求全是 403现象前 50 条秒抓之后每条都超时最终日志里全是一连串 403。 原因触发对端的频率控制。百度新闻对同一 IP 的短时请求次数有硬限制今日头条的防护更敏感同一关键字翻页到第 4、5 页基本就是高危区。 解决把固定延迟改为随机延迟比如Thread.sleep(800 new Random().nextInt(800))让请求间隔不是固定节拍。同时限制单关键字抓 3 页以内多个关键字之间轮换而不是逐个清空。给每个请求设置不同的Cookie值也能缓解但不是根治办法。真正稳妥的做法是放慢节奏把单轮任务拆成多次执行。5.5 数据库有数据但时间字段是 0000-00-00 或标题乱码现象入库成功发布时间显示0000-00-00 00:00:00新闻标题乱码。 原因时间字段乱多半是页面时间是相对时间代码没做相对时间转换乱码多半是 JDBC 连接串少了characterEncodingutf8或者表字符集还是latin1。 解决相对时间要先解析成绝对时间匹配“刚刚”“n分钟前”“n小时前”“昨天”等文本后用LocalDateTime.now().minus换算成标准时间。表字符集用ALTER TABLE news_article CONVERT TO CHARACTER SET utf8mb4做一次整体转换再检查连接串参数。乱码的隐蔽危害在于它会把所有基于 title 的统计都带偏比如按标题去重时永远无法命中。6. 扩展实战把单源爬虫改造成多源聚合工具的落地要点6.1 新增一个新闻源的最小改动量想加入腾讯新闻或网易新闻不需要动调度和入库代码。只需要新增一个 URL 构造方法、一个列表解析方法、一个正文解析方法再在工厂里按来源名注册进去。改动量集中在三处搜索 URL 模板、列表页解析选择器、详情页正文选择器。队列、去重、入库全部复用。我一般会在工程里加一张source_type字段来区分来源抓取时用同一个调度线程跑结果入库后按来源统计影响力。新增来源后先跑单关键字单页验证打印解析结果和预期字段做对比确认字段对得上再放开并发量。不要一上来就批量跑十个关键字最容易把刚接的源跑崩。6.2 验证抓取结果正确性的三个方法落地之后如何判断机器抓的数据可信我会做三件事第一从库里随机抽 20 条标题和源站手动搜索结果比对重点看标题是否被截断、来源是否错位第二把同一关键字连续跑两轮对比url字段的重复率正常应该在 60% 以上重复率太低说明列表页返回内容不稳定第三检查publish_time的分布如果大量集中在当前小时说明相对时间没转换对。这三个验证方法不需要写代码用几条 SQL 就能完成手工比对几十条记录比任何测试框架都直接。6.3 定时任务与增量抓取建议把 main 方法里的单次执行包成一个CrawlJob用ScheduledExecutorService每 30 分钟触发一次就是最轻量的定时方案。增量抓取的核心是维护一张crawl_keyword表记录每个关键字的最后抓取页和最后抓取时间下次启动从记录页继续而不是从头抓一遍。从那以后我每次部署这类新闻爬虫都会在启动前先用命令行连一次数据库查一遍表字符集和连接串编码再跑单关键字冒烟测试。这个习惯帮我挡掉了至少三次线上乱码事故。希望帮到你。本文还有配套的精品资源点击获取