Python爬虫实战：抓取百度新闻和今日头条到MySQL-北京尧图网络

简介一套基于 Java 实现的新闻爬虫程序面向有 Java 基础、希望掌握网页数据采集与入库流程的学习者可按关键字抓取百度新闻、今日头条相关内容并写入数据库。压缩包内共 20 个文件以 16 个 Java 源文件为核心涵盖爬取调度、解析与存储等模块另含 Maven 配置 pom.xml、属性配置文件及 README 说明便于导入工程后快速理解结构整体约 19KB适合作为轻量级练习或数据收集基础工具。已有 448 人浏览学习可见该主题在入门爬虫开发中具有一定参考价值。借助源码可学习 URL 管理、页面解析、数据持久化及反爬应对等常见环节同时项目带有完整的工程骨架便于在此基础上扩展关键字规则、存储策略或新闻源。需注意描述中提示程序运行或部署如遇问题可联系作者处理使用前请确认本机环境满足 Maven 与数据库配置要求。1. 用关键字把百度新闻和今日头条灌进 MySQL这套爬虫到底能解决什么问题做舆情监控的同事每天上班第一件事是在百度新闻和今日头条里逐个输入品牌词、行业词把结果复制到 Excel。一个人管五六个关键词还能忍管二十个以上一上午就没了而且手抄的新闻链接三个月后基本打不开。这个标题指向的爬虫方案就是用 Python 把「搜索关键词 → 获取新闻列表 → 抓取正文 → 写入数据库」这条链路自动化让你只维护一个关键词清单剩下的交给定时任务。我最早以为这就是个入门练手项目真正落地才发现难点根本不在 requests 怎么发请求而在三个地方百度新闻的跳转链接怎么处理、今日头条的正文字段为什么总抽不干净、以及数据进了 MySQL 之后怎么保证不越爬越多。这篇文章按我实际做过的方案拆开讲新手能照着跑通老手可以重点看翻页边界和去重设计。技术栈就是最常见的 Python requests lxml MySQL不引入分布式爬虫那套重武器单机定时跑完全够用。2. 选型与准备为什么抓这两个站用 requestslxml 就够存储为什么一定要 MySQL2.1 两个新闻源的技术差异决定了爬虫写法完全不同百度新闻的搜索结果页是服务端渲染的 HTML你怎么构造 URL它就怎么返回页面关键词和页码都直接体现在地址栏参数里。这种站点很适合 requests 直接抓然后用 lxml 的 XPath 解析。今日头条则完全相反搜索结果是 JSON 接口返回明文参数里带着 keyword、offset 这些字段反而比解析 HTML 更直白。但正文页两边都是 HTML而且今日头条的 HTML 结构变过很多次正文抽取必须做回退方案。所以这套项目统一用 requests.Session 来发请求好处是复用 TCP 连接抓了列表再进详情页效率比每次新建 requests.get 高不少。解析层用 lxmlXPath 定位标题、链接、时间和正文比正则表达式抗页面小改动的能力强。很多人学 python 爬虫入门时用 BeautifulSoup做新闻抓取其实 lxml 更合适速度和 XPath 的表达能力都更符合这个场景。先明确一点标题里写的「根据关键字爬取所有新闻」在实践中要定义边界。百度新闻的搜索结果有分页上限头条的搜索结果也会在翻到一定页数后返回空列表。我一般会做两个限制单个关键词最多翻 50 页抓不到新结果就提前退出。所谓「所有」是给定关键词在当前时间窗口内的所有可枚举结果而不是无限追溯历史。2.2 数据库选型和 news 表设计存储为什么不用 SQLite 而选 MySQL三个理由关键词多了之后你每天要按关键词、时间窗做统计查询MySQL 的 SQL 生态更顺手增量抓取时 INSERT IGNORE 配合唯一索引能直接在数据库层去重还有一点这个爬虫通常只是数据管道的第一环下游可能有报表、可视化MySQL 是团队里大多数人都能接手的东西。建表脚本如下字段设计和索引是这套方案的核心照着建就行CREATE TABLE IF NOT EXISTS news ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, keyword VARCHAR(64) NOT NULL COMMENT 搜索关键词, title VARCHAR(512) NOT NULL COMMENT 新闻标题, url VARCHAR(1024) NOT NULL COMMENT 原文链接, source VARCHAR(32) NOT NULL COMMENT 来源站点: baidu/toutiao, author VARCHAR(128) DEFAULT NULL COMMENT 发布媒体, publish_time DATETIME NULL COMMENT 发布时间, content MEDIUMTEXT COMMENT 正文全文, fetch_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 抓取时间, UNIQUE KEY uk_source_url (source, url(255)) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;关键参数说明url 字段设 1024 是因为百度跳转链接带一串参数短了会截断唯一索引 uk_source_url 是去重的最后一道防线source 加进去是因为百度新闻和今日头条可能抓到同一条稿子URL 不一样但来源必须区分url 只索引前 255 个字符避免超长索引影响写入性能。content 用 MEDIUMTEXT 而不是 TEXT因为 TEXT 上限只有 64KB遇到长文直接报 Data too long。2.3 初始化环境和数据库连接环境依赖很简单pip 安装这四个包就够了pip install requests lxml pymysql数据库连接我用 pymysql 直接管理不引入 ORM。对爬虫这种写入频率不高的场景ORM 反而碍事批量插入时还得处理映射关系。下面是连接函数和初始化表结构的代码。import pymysql from pymysql.cursors import DictCursor DB_CONFIG { host: 127.0.0.1, port: 3306, user: root, password: your_password, database: news_db, charset: utf8mb4, cursorclass: DictCursor, } def get_conn(): return pymysql.connect(**DB_CONFIG) def init_db(): conn get_conn() cur conn.cursor() cur.execute(open(schema.sql, encodingutf-8).read()) conn.commit() cur.close() conn.close()charset 必须写 utf8mb4不能写 utf8否则新闻标题里出现 emoji 或特殊符号时入库会报错。DictCursor 让查询结果以字典形式返回后面处理头条 JSON 字段时不用琢磨下标位置。init_db 直接读 schema.sql 文件执行比在代码里写一大段 CREATE TABLE 更干净。如果你本地还没建 news_db 这个库先执行一句CREATE DATABASE news_db DEFAULT CHARACTER SET utf8mb4再跑初始化。3. 百度新闻爬虫按关键字抓搜索结果翻页和去重是核心3.1 构造百度新闻搜索请求的正确姿势百度新闻的搜索 URL 比想象中简单核心参数就几个tn 固定为 newsword 是关键词pn 是页码偏移量rn 是每页条数。pn 从 0 开始每翻一页加 20这和百度网页搜索的翻页逻辑一致。请求头里必须带 User-Agent 和 Referer否则百度有时会返回安全验证页。import requests import time HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://news.baidu.com/, Accept: text/html,application/xhtmlxml, } def fetch_baidu_list(keyword, page): params { tn: news, word: keyword, pn: page * 20, rn: 20, cl: 2, ie: utf-8, } resp requests.get(https://www.baidu.com/s, paramsparams, headersHEADERS, timeout10) resp.encoding utf-8 return resp.text注意这一段里有个很容易翻车的细节requests 在响应头没有明确 charset 时会按 apparent_encoding 猜测编码百度新闻偶尔会返回 GBK 的旧页面猜错就是满屏乱码。这里直接指定 resp.encoding utf-8然后依赖下面的解析层做容错。timeout 必须设新闻页面偶尔会卡住不设超时整个爬虫会挂在一次请求上。页面上没有 rn 这个参数时你也可以不传默认每页返回 20 条。cl2 表示站内搜索ieutf-8 强制输入编码。如果你发现返回结果数不对检查 URL 里是否被百度加上了 wd 字段优先于 word这两个参数同时出现时以 wd 为准。3.2 解析百度新闻列表XPath 定位标题、链接和时间百度新闻的结果页结构这些年调过不少次但有一个规律没变过每条结果的标题都在带 class 的 div 里链接是带跳转参数的。用 XPath 提取时不能写死下标要用 contains 匹配 class 名称。from lxml import html def parse_baidu_list(html_text): doc html.fromstring(html_text) items [] for node in doc.xpath(//div[contains(class,result)]): title_node node.xpath(.//a[contains(class,news-title) or contains(class,title)]) if not title_node: continue title title_node[0].text_content().strip() link title_node[0].get(href, ).strip() time_node node.xpath(.//span[contains(class,time)]//text()) publish_time time_node[0].strip() if time_node else items.append({ title: title, url: normalize_url(link), publish_time: publish_time, summary: node.text_content()[:200] }) return itemstext_content() 会把节点下所有子节点的文本拼起来比直接取 text 属性可靠得多。标题里可能夹杂空格和换行strip 之后才是干净数据。百度新闻的链接有个特点href 往往是http://www.baidu.com/link?urlxxx这种跳转地址不是新闻原文地址。normalize_url 要做的是把这种链接原样保存不要试图解析出真实 URL因为你解析不出来的概率很高而且跳转链接会过期抓到后应该尽快请求正文。时间字段也有坑搜索结果页展示的是「2小时前」这种相对时间不是标准时间格式。处理方式是入库前判断如果匹配不到%Y-%m-%d %H:%M就取当前时间作为发布时间。这样做的代价是部分新闻的时间精度不准对于那些必须用搜索页时间做时间窗筛选的场景建议额外请求详情页去解析标准时间。3.3 正文抓取和批量入库一次解析批量写入进入详情页抓正文逻辑很简单但要注意写干净。新闻页面正文一般集中在 article 或 content 类名的 div 里正文段落都是 p 标签。直接取所有 p 标签的 text 拼起来比试图精确定位某个容器更抗页面结构变化。def fetch_article(session, url): try: resp session.get(url, headersHEADERS, timeout10) resp.encoding resp.apparent_encoding doc html.fromstring(resp.text) paragraphs doc.xpath(//div[contains(class,article) or contains(class,content)]//p//text()) paragraphs [p.strip() for p in paragraphs if p.strip()] return \n.join(paragraphs) except Exception: return 这里有一个细节值得单独说详情页的编码不能用 utf-8 死磕很多新闻源站是 GBK 或者 GB2312所以这一层我让 requests 用 apparent_encoding 自动判断和列表页强制 utf-8 正好相反。上一条请求如果失败了函数返回空字符串不应该从头抛出因为列表里几百条链接偶尔一条失败不应当让整个任务中断。入库用 executemany 批量插入配合 INSERT IGNORE。INSERT IGNORE 的意思是唯一索引冲突时直接跳过不报错。这样同一批数据里如果有重复 URL天然就被数据库过滤掉了。这是整个去重体系里最重要的一环比在 Python 里维护 seen set 可靠得多。def save_news(items): conn get_conn() cur conn.cursor() sql (INSERT IGNORE INTO news (keyword, title, url, source, publish_time, content, fetch_time) VALUES (%s, %s, %s, %s, %s, %s, NOW())) cur.executemany(sql, items) conn.commit() cur.close() conn.close() return cur.rowcountpublish_time 在入库前做一次统一格式化转换把搜索页和详情页里的各种时间字符串转成YYYY-MM-DD HH:MM:SS转换失败就填空值让 MySQL 存 NULL。executemany 的 items 必须是列表套元组不要传字典列表pymysql 对字典列表的兼容性在不同版本里不一致。到这里百度新闻这条链路已经通了。但光有列表和正文还不够——翻页必须有个终止条件我会在章节 5 里专门讲为什么会翻成死循环。先把头条爬完两个源统一进库后再看坑。4. 今日头条爬虫JSON 接口取列表正文抽取才是分水岭4.1 头条搜索 JSON 接口的请求参数和返回结构今日头条的网页搜索走的是一个 JSON 接口地址固定参数比百度新闻多但结构更可预测。请求时除了 keyword必须带上一组客户端标识参数否则会直接拒绝访问。这个接口是前后端分离架构的产物比抓 HTML 更省事但反爬逻辑也集中在这里。def fetch_toutiao_list(session, keyword, offset): params { aid: 24, app_name: web_search, offset: offset, format: json, keyword: keyword, autoload: true, count: 20, search_id: search_id, # 从第一次请求返回中获取 version: 2, } resp session.get( https://www.toutiao.com/api/search/content/, paramsparams, headersTOUTIAO_HEADERS, timeout10 ) return resp.json()TOUTIAO_HEADERS 里必须包含完整的浏览器 User-Agent 和 Refererhttps://www.toutiao.com/search/?keywordxxx缺了 Referer 很容易返回 403。search_id 是第一次请求接口返回的后续翻页最好带同一个 search_id模拟一次连续搜索过程。offset 从 0 开始每翻一页加 20。头条的这个接口有个特点返回 JSON 里 data 字段是一条条新闻对象但每条对象的字段名在不同时段可能不一样。常见的字段是 title、url、source、datetime有时还会有 group_id、item_id。解析时不能只取固定字段要做字段兜底。def parse_toutiao_list(json_data, keyword): items [] for item in json_data.get(data, []): if not item or title not in item: continue title html.unescape(item.get(title, )).strip() url item.get(url) or item.get(article_url) or source item.get(source, ) or item.get(media_name, ) ts item.get(datetime, 0) publish_time datetime.fromtimestamp(int(ts)) if ts.isdigit() else datetime.now() items.append({ keyword: keyword, title: title, url: url, source: source, publish_time: publish_time, content: , # 正文稍后单独抓 }) return items头条返回的 title 里经常带着 HTML 实体比如quot;这种必须用 html.unescape 还原。datetime 字段是一个字符串形式的时间戳isinstance 判断不靠谱用 isdigit 判断更稳妥。source 可能为空空了就把 author 留空别用 None 填充。这里要过滤掉两类内容一类是广告头条搜索结果里混着「广告」标签的推广内容来源名里直接带推广两个字过滤掉另一类是空链接数据group_id 没有、url 也不是 http 开头直接丢弃。正文长度为空的条目后续单独走正文抓取流程。4.2 头条正文抽取的 XPath 策略text() 拼接和结构回退头条的正文页面结构和百度新闻的详情页完全不是一个套路。百度系页面通常有统一的 class 命名头条的正文页经常是文章页和微头条混在一起。微头条没有传统意义的正文只有一段短文本需要另外处理。正文抽取我用的策略是三层回退def extract_article_content(doc): selectors [ //div[contains(class,article-content)]//p//text(), //div[contains(class,article)]//p//text(), //article//p//text(), //div[contains(id,article)]//p//text(), ] for selector in selectors: parts doc.xpath(selector) parts [p.strip() for p in parts if p.strip()] if len(parts) 3: return \n.join(parts) # 回退取整个 body 里 P 标签最长的连续块 all_parts [p.strip() for p in doc.xpath(//p//text()) if p.strip()] if len(all_parts) 3: return .join(all_parts) return \n.join(all_parts[:50])这里的核心是 XPath 的//p//text()配合双斜杠取到的是每个 p 标签内部的文本节点不会把 p 标签里的子标签重复计算。第一层选择器如果命中文章容器通常能拿到完整的段落如果拿到的结果不足 3 段大概率命中的是侧边栏或评论区就继续回退。最后回退到全页面所有 p 标签时做了长度限制最多 50 段防止把评论区的用户发言当正文灌进库。头条有些文章是图文混排正文里嵌着图片说明文字。图片说明通常不是 p 标签所以这个抽取方案会丢掉它们我觉得可以接受。如果你需要保留图片描述额外加一个选择器取//div[contains(class,image-desc)]//text()。还有一个常见情况是头条转发了微信公众号的文章正文容器不叫 article-content 而叫 rich_media_content需要把这个 class 也加进选择器列表。4.3 头条正文抓取时的反爬判断verify_cookie 不是无解的头条的正文页和搜索接口都会做流量控制。你连续抓了二十来篇正文之后再发请求返回的可能是一个验证页面内容特征是有verify字样或者 JS 异常。这时候的 html.fromstring 不会报错只是解析出来的内容为空。所以正文抓取函数里要加一个特征判断def fetch_toutiao_article(session, url): resp session.get(url, headersTOUTIAO_HEADERS, timeout10) resp.encoding utf-8 if verify in resp.text[:2000].lower(): return __VERIFY__ doc html.fromstring(resp.text) content extract_article_content(doc) return content if content else 爬虫函数里持续跟踪返回结果连续出现三次__VERIFY__就停止当前批次把未抓正文的 URL 记录到一个 txt 文件里下次任务开始时重试。不要在同一批次里反复重试越重试越容易被封。头条的 verify 机制过一段时间会自动失效下次定时任务再跑之前失败的链接大概率能成功。头条正文抓取是整套方案中最慢的一环每篇都要独立请求加上随机 sleep 2 到 5 秒一小时能抓几百篇已是上限。所以这个方向如果要扩大数据量正确的做法不是提高并发而是把抓正文也做成增量只对当天新增的 URL 抓正文老文章不再回源。5. 新闻爬虫避坑指南乱码、重复、截断、死循环、限流这五个坑我都踩过5.1 入库后标题全是乱码源头不是页面而是连接现象标题字段在 Python 里打印正常写进 MySQL 变成åŒ—äº¬或者???。原因有两层第一层是页面编码判断错误第二层是数据库连接字符集不对。百度新闻偶尔用 GBK 输出如果你在响应里强制 utf-8字符串在 Python 里就已经错了另一个更隐蔽的是 pymysql 连接没加 charset 参数默认 latin1 连接写中文必然乱码。解决请求响应里先判断页面 meta 标签的 charset不信任 HTTP 头pymysql 连接字符串里显式加 charsetutf8mb4表结构也要保证是 utf8mb4。MySQL 的库、表、字段三级字符集都可能各自继承出问题建表时全部显式指定。5.2 同一个关键词爬三次库里数据翻三倍现象每天定时跑跑完发现新闻总数在涨把同一篇新闻的抓取时间一对比发现库里存了三份。原因只在 Python 代码里用 seen url 集合做去重但每次任务重启后 seen 就没了旧的 URL 没查数据库直接当作新数据入库。解决数据库层面加 UNIQUE KEY uk_source_url (source, url(255))入库用 INSERT IGNORE让 MySQL 帮你挡重复。注意这里的坑是 url(255) 前缀索引如果 URL 前 255 个字符相同但后面不同唯一索引不生效。实践中百度跳转链接前 255 个字符基本能区分不要为了保险删掉前缀长度那会让索引变得太大。5.3 INSERT 时报 Data too long for column content现象跑着跑着突然报 MySQLdb 异常整个批次回滚日志里是 Data too long。原因有的新闻正文长度超过 64KB而建表时 content 用了 TEXT 类型还有一个原因是标题里带了被截断的 emojiutf8mb4 下每个字符占 4 字节字段长度要按字符算不是字节算。解决content 改成 MEDIUMTEXT上限 16MB绝大多数新闻正文都够用title 字段保留 512 字符长度入库前做title title[:500]兜底。另外正文清洗时要把连续空白字符压缩成单个空格这不仅省空间还让下游做文本分析时更干净。5.4 翻页翻到几千页不停或者第二页结果和第一页一样现象单关键词跑了几个小时没结束一看日志页数已经 600 多内容全是同一批新闻另一种情况是上一次任务翻到第 40 页就结束了。原因头条用 offset 翻页百度用 pn 翻页两家的参数语义不同你把 offset 当成页码乘 20要么永远重复第一页要么翻到超出边界返回空列表还有一种情况是没有页数上限。解决百度翻页用pn page * 20头条用offset 20两个函数彻底分开while 循环上加max_pages 50硬上限任何情况下不允许超过当一页解析出来的条目数为 0 时立刻 break不要继续请求。5.5 爬一会儿就 403停一会儿又能跑了现象前 200 条数据正常之后请求开始报 403或者头条返回 verify 页面。原因请求特征太明显请求头里没有浏览器特征两次请求之间间隔太短。解决User-Agent 用随机池每次请求换一个两个请求之间 sleep 随机 2 到 5 秒别用固定时间间隔超出重试三次仍失败把当前 URL 写进 failed_links 文件本轮任务结束下轮任务优先处理失败列表。这个方案不搞多线程并发单线程加合理的等待一天一万条以内完全够用也多亏了 MySQL 的唯一索引重跑任务不会产生脏数据。6. 把爬虫变成每天自动跑的新闻收集器增量、验证、调度6.1 增量抓取怎么设计时间窗我习惯把抓取范围控制在最近 24 小时核心不是爬虫代码而是搜索环节就做时间限定。百度新闻搜索结果页带 rtt 参数可以切换时间范围头条的搜索接口也支持按发布时间排序。两者都不完美所以最终依赖的是数据库侧去重同一篇文章的 URL 已经在库里INSERT IGNORE 会直接跳过新文章自动入库。这就是增量爬虫的本质——不靠精确的时间过滤靠唯一索引扛住重复请求。def build_keyword_list(pathkeywords.txt): with open(path, encodingutf-8) as f: return [line.strip() for line in f if line.strip() and not line.startswith(#)] def run_crawler(): keywords build_keyword_list() session requests.Session() for kw in keywords: for page in range(50): items parse_baidu_list(fetch_baidu_list(kw, page)) if not items: break for item in items: item[content] fetch_article(session, item[url]) save_news(items) time.sleep(random.uniform(2, 5))关键词文件里用#开头表示注释这样你可以在文件里维护多组关键词临时要停掉某个词不用删除直接注释掉。抓正文是串行的慢但可靠。6.2 用一条 SQL 验证抓取结果和重复率跑完一批数据之后我习惯先看一张汇总表而不是直接信日志。下面这条 SQL 能直接看出每个关键词的抓取量、来源分布和无效内容比例SELECT keyword, source, COUNT(*) AS total_cnt, COUNT(DISTINCT url) AS unique_cnt, SUM(CASE WHEN content OR content IS NULL THEN 1 ELSE 0 END) AS empty_cnt FROM news WHERE fetch_time NOW() - INTERVAL 1 DAY GROUP BY keyword, source ORDER BY total_cnt DESC;看到 total_cnt 明显大于 unique_cnt 说明唯一索引没兜住优先排查 URL 规范化empty_cnt 占比超过 10% 说明正文抽取失败太多去检查头条正文选择器是否又变了。再配合SELECT id, title FROM news ORDER BY fetch_time DESC LIMIT 20直接看抓到的标题是否符合预期基本能判断整个链路健康度。6.3 定时执行和失败重跑的习惯最后的调度我建议直接用系统 cron不引额外的调度框架。每天凌晨一点跑全量增量凌晨六点补跑失败列表。补跑时因为用 INSERT IGNORE重复请求不会产生副作用这是整套方案给你留的「后悔药」。我最早写这套爬虫时以为难点在解析后来发现真正让项目翻车的全是数据和工程问题URL 没规范导致重复灌库、编码搞错导致全库乱码、正文抽取器遇到新页面结构就静默失败。现在我每跑一批数据都会先执行上面那条验证 SQL确认数据可靠再交给下游使用。希望这套方案能帮你少踩几个坑让关键词到新闻库这条链路真正变成一天一次、数据干净的自动化管道。本文还有配套的精品资源点击获取

Python爬虫实战：抓取百度新闻和今日头条到MySQL

相关推荐

Unity全局音效管理器设计与实现

8款AI论文工具实测：继续教育学生高效写作指南

MoneyPrinterTurbo：自动化短视频生成工具的技术架构与实操部署

更多资讯

Strands Harness SDK：一行代码启动生产级Agent服务

数据科学实战：背面纸条数学的快速估算技巧

MilkShape 3D 1.8.2 安装与配置全指南：兼容性、OpenGL与插件排查

多模态决策模型落地指南：从Jev-Omni到AI声音合规

C语言测试程序分析与质量评估实践指南

微信输入法、Rime、豆包输入法怎么选？三套方案深度对比与选型指南

今日更新

猫狗目标检测数据集：VOC/COCO/YOLO三格式一体化实战包

HDU2017多校标程复现：算法竞赛工程化真题沙盒

Codex Sandbox 隔离环境拆解：AI Agent 的临时实验室如何运作

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？