简介这是一份面向Python爬虫初学者与数据分析入门者的实战项目包围绕新浪微博数据抓取展开帮助读者掌握从HTTP请求到数据落地的完整链路。资源共77个文件以44个py源码为核心辅以14个md说明文档、11个html页面、2个yml配置及json、txt、conf等辅助文件压缩包约106KB结构紧凑便于按模块查阅。内容覆盖requests发送请求、BeautifulSoup解析页面、动态User-Agent与代理IP池等反爬处理、验证码应对、异常捕获以及CSV、JSON、SQLite等数据存储方式并延伸至Scrapy框架的项目化管理思路。目录中spider、parser、writer、downloader等模块划分清晰配合cookie、settings、FAQ等文档可帮助读者理解爬虫工程的组织方式与调试路径。目前已有1187人学习下载适合希望以真实社交媒体场景练手、系统补齐爬虫知识点的开发者参考。1. 微博数据采集的工程化落地从零复现一套 Python 爬虫做社媒舆情分析、传播路径研究或者用户画像建模的团队几乎都绕不开一个数据源——微博。但真正动手去抓的时候很多人卡在第一步接口怎么找、登录态怎么维持、翻页什么时候停、抓下来的字段怎么对齐。这份「新浪微博爬虫用 python 爬取新浪微博数据.zip」就是冲着这些具体问题来的它把采集流程拆成了可运行的脚本模块适合需要批量获取公开博文、评论、用户基础信息的从业者。不管你是刚接触爬虫的新手还是想找一套能改改就用的采集框架的老手这份资源都能让你少走一段从「能跑」到「稳定跑」的弯路。下面我按实际拆包和复现的顺序把里面的技术点、参数配置和踩坑记录一条条讲清楚。2. 拆包先看结构这套爬虫的模块划分与数据流设计拿到一个压缩包我习惯先看目录树再动手跑。这套爬虫的工程结构不算复杂但模块边界划得比较清楚改起来不容易牵一发动全身。2.1 核心文件清单与职责划分解压后大致会看到这么几类文件入口脚本、请求封装模块、解析模块、存储模块、配置文件。入口脚本负责串联流程请求封装处理会话维持和重试解析模块把 HTML 或 JSON 响应转成结构化字段存储模块决定落库还是落文件。常见做法是把配置单独抽出来比如config.py或settings.json里面放请求头、Cookie、并发数、输出路径这些容易变的东西。我一般会先打开配置文件扫一眼确认哪些参数需要改成自己的。比如目标关键词、时间范围、最大翻页数、输出格式这些通常都在配置里。如果配置项写得比较散可以自己归拢一下后面调参的时候会省很多事。提示不要急着改代码逻辑先把配置项过一遍很多「跑不通」其实是配置没对上。2.2 请求链路从搜索入口到详情页的跳转逻辑微博的数据采集通常有两条路径一条走搜索接口按关键词拿博文列表另一条走用户主页按 UID 拿历史博文。这套爬虫大概率是前者为主因为搜索入口更适合按主题批量抓取。请求链路一般是构造搜索 URL → 携带 Cookie 和请求头发起请求 → 拿到 JSON 或 HTML → 解析出博文 ID 和基础字段 → 根据需要再请求详情页补全评论或转发数据。这里有个关键点搜索接口返回的字段往往不全正文可能被截断图片和视频链接也可能缺失。所以如果业务需要完整正文得在拿到博文 ID 后再发一次详情请求。这一步会增加请求量但字段完整度会高很多。我一般会在配置里加一个开关控制是否补全详情避免在只需要标题和互动量的时候浪费请求配额。2.3 数据落盘字段设计与存储格式的选择存储这块常见做法是先用 CSV 或 JSON Lines 落文件跑通之后再考虑入库。CSV 的好处是直观用 Excel 就能打开检查JSON Lines 的好处是字段可以嵌套适合存评论列表这种一对多的结构。这套爬虫大概率两种都支持或者至少留了扩展接口。字段设计上我建议至少保留这几列博文 ID、用户 ID、昵称、发布时间、正文、转发数、评论数、点赞数、来源终端。如果要做传播分析还得加上转发链的父节点 ID。这些字段在解析模块里应该都有对应但字段名可能和你的下游系统不一致落盘前最好做一层映射。# 字段映射示例把爬虫输出对齐到下游分析表 FIELD_MAP { mid: post_id, user_id: uid, screen_name: nickname, created_at: publish_time, text: content, reposts_count: repost_num, comments_count: comment_num, attitudes_count: like_num, source: device } def normalize_record(raw: dict) - dict: 把原始字段名转成下游统一字段名 return {FIELD_MAP.get(k, k): v for k, v in raw.items()}这段代码做的是字段名归一化。FIELD_MAP左边是爬虫原始字段右边是你下游系统用的字段。normalize_record函数遍历原始字典能映射的就换名映射不上的保留原名。这样后面换数据源或者改字段的时候只需要改映射表不用动解析逻辑。3. 环境准备与首次运行把脚本跑起来的最小闭环拆完结构下一步是让它跑起来。这一步的目标不是抓多少数据而是验证整条链路通不通。3.1 依赖安装与 Python 版本选择先看requirements.txt或者脚本头部的 import。常见的依赖包括requests、beautifulsoup4、lxml、pandas如果用了异步可能是aiohttp。Python 版本建议 3.8 以上3.10 更稳因为有些库对新版本的支持更好。安装依赖的时候我一般会建一个虚拟环境避免和系统里的包冲突。命令不复杂python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt如果requirements.txt里没锁版本建议手动锁一下主要库的大版本比如requests2.28,3.0避免以后重装环境时因为库升级跑不起来。3.2 Cookie 与请求头的配置方法微博的搜索接口对登录态有要求没有 Cookie 基本拿不到数据。配置 Cookie 的常见做法是浏览器登录后打开开发者工具在 Network 面板里找一条搜索请求把 Request Headers 里的 Cookie 整段复制出来粘贴到配置文件的对应字段。请求头里除了 Cookie还要注意User-Agent、Referer、X-Requested-With这几个。User-Agent建议用真实浏览器的不要用脚本默认的。Referer一般填搜索页的 URL。X-Requested-With填XMLHttpRequest有些接口会检查这个头。注意Cookie 是有有效期的通常几天到几周不等。跑批量任务前先手动测一条请求确认返回的是数据而不是登录页。3.3 跑通第一条请求参数含义与返回检查配置改好之后先别急着跑全量。我一般会写一个最小测试脚本只发一条请求把返回内容打印出来看看。import requests import json # 从配置文件读取这里用占位符示意 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..., Cookie: 你的Cookie字符串, Referer: https://weibo.com/, X-Requested-With: XMLHttpRequest } def test_one_request(keyword: str, page: int 1): 发一条搜索请求检查返回结构 url https://weibo.com/ajax/statuses/searchProfile params { q: keyword, page: page, count: 10 } resp requests.get(url, headersHEADERS, paramsparams, timeout10) print(状态码:, resp.status_code) data resp.json() # 检查关键字段是否存在 if data in data and list in data[data]: print(拿到博文数:, len(data[data][list])) print(第一条:, json.dumps(data[data][list][0], ensure_asciiFalse)[:200]) else: print(返回结构异常:, json.dumps(data, ensure_asciiFalse)[:300]) test_one_request(测试关键词)这段代码的作用是验证请求链路。params里的q是搜索词page是页码count是每页条数。返回的 JSON 里data.list通常是博文数组。如果这个结构对不上说明接口变了或者 Cookie 失效了。打印第一条数据是为了确认字段名和内容是否符合预期。跑通这一步之后再把逻辑接回主脚本批量翻页就有底了。4. 采集策略与参数调优翻页、去重与频率控制链路通了之后真正影响数据质量和账号安全的是采集策略。这部分调不好要么抓不全要么抓一半被限流。4.1 翻页终止条件的判断逻辑翻页什么时候停不能只看「返回为空」。微博搜索接口在翻到一定深度后可能返回重复数据或者空列表也可能直接返回错误码。我一般会设三个终止条件连续两页返回空、连续两页数据完全重复、达到配置的最大页数。这三个条件满足任意一个就停。另外搜索结果的排序方式也会影响翻页。按时间排序和按热度排序翻页深度限制不一样。按时间排序通常能翻得更深适合做历史数据回溯按热度排序翻几页就到底了适合抓热点。def should_stop(current_page_data: list, last_page_ids: set, max_pages: int, current_page: int) - bool: 判断是否停止翻页 if current_page max_pages: return True if not current_page_data: return True current_ids {item.get(mid) for item in current_page_data} if current_ids and current_ids.issubset(last_page_ids): return True return False这个函数接收当前页数据、上一页的 ID 集合、最大页数和当前页码。先判断是否到最大页数再判断是否空页最后判断是否和上一页完全重复。issubset用来检查当前页 ID 是否全部出现在上一页里如果是说明翻页没带来新数据可以停了。4.2 去重策略基于博文 ID 的集合维护去重这件事最稳的是用博文 ID 做唯一键。每抓一页把新出现的 ID 加进一个全局集合落盘前再过滤一遍。如果数据量很大集合放内存吃不消可以用布隆过滤器或者落库后做唯一索引。我一般会在存储模块里加一层去重而不是在解析模块做。因为解析模块只管把响应转成记录去重是跨页面的逻辑放在存储层更合适。具体做法是维护一个seen_ids集合每次写入前检查写完再更新集合。提示如果中途断了要续跑记得把seen_ids持久化到文件或数据库不然重启后会重复抓。4.3 请求频率与随机延迟的设置频率控制是保账号的关键。微博对高频请求比较敏感尤其是同一个 Cookie 短时间发大量请求。常见做法是每请求一次 sleep 一个随机区间比如 2 到 5 秒。如果用了并发并发数不要超过 3并且每个协程独立延迟。配置里如果有delay或sleep参数先按默认值跑观察返回状态。如果出现 418 或 403说明频率高了把延迟调大。如果跑得很稳可以适当缩小延迟但别低于 1 秒。import time import random def polite_delay(base: float 2.0, jitter: float 3.0): 随机延迟避免固定间隔被识别 time.sleep(base random.random() * jitter)base是最小延迟jitter是随机增量。这样每次 sleep 的时间在 2 到 5 秒之间浮动比固定 3 秒更自然。如果目标数据量不大可以把base调到 3 以上更稳妥。5. 避坑与排查跑微博爬虫最容易翻车的五个地方这套爬虫的代码逻辑不算复杂但微博侧的变动和反爬策略会让很多「看起来没问题」的配置突然失效。下面这几条是我实际跑的时候踩过的按现象、原因、解决三段来说。5.1 返回 200 但数据为空现象请求状态码是 200但data.list是空数组或者返回的 HTML 里没有博文节点。原因最常见的是 Cookie 过期登录态失效后接口返回的是空数据而不是 401。其次是搜索词被限流某些敏感词或高频词会返回空结果。还有一种可能是请求头里的Referer不对接口做了来源校验。解决先换一个新 Cookie 再试。如果换完还是空把搜索词换成更通用的词测试。再不行就检查Referer和X-Requested-With是否和浏览器一致。我一般会保留一个「测试模式」用固定关键词跑一条确认链路没问题再跑正式任务。5.2 翻页到第 N 页后返回重复数据现象前几页数据正常翻到第 5 页或第 10 页之后返回的博文 ID 和前面重复或者直接返回第一页的内容。原因微博搜索接口对未登录或低权重账号有翻页深度限制超过一定页数后不再返回新数据而是循环返回前面的结果。另外如果请求间隔太短也可能触发这个限制。解决在翻页逻辑里加去重判断发现连续两页 ID 重复就停。同时把请求延迟调大给账号「降速」。如果确实需要更深的历史数据可以改用按时间分段的方式把大范围拆成多个小时间段每个时间段单独翻页。5.3 Cookie 失效导致中途断抓现象任务跑到一半突然开始返回登录页或者空数据前面抓的都正常。原因Cookie 的有效期到了或者账号在别处登录导致当前会话失效。微博的 Cookie 有效期不固定有时候几小时就失效。解决在请求封装里加一个失效检测发现返回内容不符合预期就抛异常并记录当前页码。重新获取 Cookie 后从断点继续跑。如果任务时间长建议把大任务拆成小批次每批跑完就落盘减少单次依赖 Cookie 的时间窗口。5.4 字段缺失或类型不一致现象落盘后发现某些行的reposts_count是空值或者created_at格式和其他行不一样。原因微博返回的 JSON 里有些字段可能不存在或者在不同接口版本里类型不同。比如互动量有时候是数字有时候是字符串。时间格式也可能因为来源不同而有差异。解决在解析模块里加默认值和类型转换。数字字段用int(x or 0)兜底时间字段统一转成YYYY-MM-DD HH:MM:SS格式。落盘前跑一遍校验把异常行单独存一份方便排查。5.5 并发过高触发限流现象开了多线程或异步之后请求成功率骤降大量返回 418 或 403。原因微博对同一 IP 或同一 Cookie 的并发请求有阈值超过就限流。很多人为了快把并发开到 10 以上结果反而更慢。解决把并发降到 2 到 3并且每个并发任务独立延迟。如果还是被限就改成单线程加随机延迟。速度虽然慢一点但成功率会高很多。我一般会先单线程跑通再逐步加并发观察成功率变化找到那个「刚好不被限」的平衡点。6. 进阶技巧把采集结果接进分析流程的实用做法跑通采集只是第一步数据拿到之后怎么用才是这套资源真正发挥价值的地方。我一般会在爬虫和下游分析之间加一层轻量处理把原始数据转成分析友好的格式。6.1 用 Pandas 做快速清洗与字段衍生原始数据落成 CSV 之后用 Pandas 读进来做几件事时间字段转 datetime、互动量转数值、正文去 HTML 标签、按用户聚合统计发博频次。这些操作几行代码就能搞定但能省掉后面很多手工处理。import pandas as pd import re def clean_weibo_data(csv_path: str) - pd.DataFrame: 读取原始 CSV 并做基础清洗 df pd.read_csv(csv_path) # 时间转 datetime df[publish_time] pd.to_datetime(df[publish_time], errorscoerce) # 互动量转数值空值填 0 for col in [repost_num, comment_num, like_num]: df[col] pd.to_numeric(df[col], errorscoerce).fillna(0).astype(int) # 正文去 HTML 标签 df[content_clean] df[content].astype(str).apply( lambda x: re.sub(r[^], , x) ) # 衍生字段是否含链接、正文长度 df[has_link] df[content_clean].str.contains(http) df[content_len] df[content_clean].str.len() return df df clean_weibo_data(weibo_raw.csv) print(df[[publish_time, content_len, like_num]].describe())这段代码做了四件事时间转标准格式、互动量转整数、正文去标签、衍生链接标记和长度字段。errorscoerce的作用是遇到无法转换的值不报错直接变成NaT或NaN后面再统一处理。describe()用来快速看数值分布确认清洗结果合理。6.2 按时间窗口聚合做传播趋势分析清洗完之后按小时或按天聚合能看出话题的传播节奏。比如按小时统计发博量找到峰值时段按用户统计发博量找到关键传播节点。这些分析不需要复杂模型用 Pandas 的groupby就能做。我一般会先按小时聚合看整体趋势再按用户聚合看头部账号。如果要做传播路径还得把转发关系单独抽出来构建父子边列表。这部分数据如果爬虫没抓可以后续用博文 ID 单独补。6.3 采集任务的断点续跑与增量更新最后说一个实用习惯每次跑采集任务都把已抓的博文 ID 和最大时间戳存下来。下次跑的时候从最大时间戳往后增量抓避免重复。如果任务中断也能从断点继续不用从头再来。具体做法是在存储模块里加一个checkpoint.json记录last_max_time和seen_ids的持久化路径。每次落盘后更新这个文件启动时先读。这个习惯看起来简单但能省掉很多重复劳动。从那以后我每次跑批量采集都强制走一遍断点检查确认续跑逻辑没问题再开正式任务。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/17 17:59:47 · 阅读 1.2k Python爬虫实战：新浪微博数据采集与工程化落地
简介这是一份面向Python爬虫初学者与数据分析入门者的实战项目包围绕新浪微博数据抓取展开帮助读者掌握从HTTP请求到数据落地的完整链路。资源共77个文件以44个py源码为核心辅以14个md说明文档、11个html页面、2个yml配置及json、txt、conf等辅助文件压缩包约106KB结构紧凑便于按模块查阅。内容覆盖requests发送请求、BeautifulSoup解析页面、动态User-Agent与代理IP池等反爬处理、验证码应对、异常捕获以及CSV、JSON、SQLite等数据存储方式并延伸至Scrapy框架的项目化管理思路。目录中spider、parser、writer、downloader等模块划分清晰配合cookie、settings、FAQ等文档可帮助读者理解爬虫工程的组织方式与调试路径。目前已有1187人学习下载适合希望以真实社交媒体场景练手、系统补齐爬虫知识点的开发者参考。1. 微博数据采集的工程化落地从零复现一套 Python 爬虫做社媒舆情分析、传播路径研究或者用户画像建模的团队几乎都绕不开一个数据源——微博。但真正动手去抓的时候很多人卡在第一步接口怎么找、登录态怎么维持、翻页什么时候停、抓下来的字段怎么对齐。这份「新浪微博爬虫用 python 爬取新浪微博数据.zip」就是冲着这些具体问题来的它把采集流程拆成了可运行的脚本模块适合需要批量获取公开博文、评论、用户基础信息的从业者。不管你是刚接触爬虫的新手还是想找一套能改改就用的采集框架的老手这份资源都能让你少走一段从「能跑」到「稳定跑」的弯路。下面我按实际拆包和复现的顺序把里面的技术点、参数配置和踩坑记录一条条讲清楚。2. 拆包先看结构这套爬虫的模块划分与数据流设计拿到一个压缩包我习惯先看目录树再动手跑。这套爬虫的工程结构不算复杂但模块边界划得比较清楚改起来不容易牵一发动全身。2.1 核心文件清单与职责划分解压后大致会看到这么几类文件入口脚本、请求封装模块、解析模块、存储模块、配置文件。入口脚本负责串联流程请求封装处理会话维持和重试解析模块把 HTML 或 JSON 响应转成结构化字段存储模块决定落库还是落文件。常见做法是把配置单独抽出来比如config.py或settings.json里面放请求头、Cookie、并发数、输出路径这些容易变的东西。我一般会先打开配置文件扫一眼确认哪些参数需要改成自己的。比如目标关键词、时间范围、最大翻页数、输出格式这些通常都在配置里。如果配置项写得比较散可以自己归拢一下后面调参的时候会省很多事。提示不要急着改代码逻辑先把配置项过一遍很多「跑不通」其实是配置没对上。2.2 请求链路从搜索入口到详情页的跳转逻辑微博的数据采集通常有两条路径一条走搜索接口按关键词拿博文列表另一条走用户主页按 UID 拿历史博文。这套爬虫大概率是前者为主因为搜索入口更适合按主题批量抓取。请求链路一般是构造搜索 URL → 携带 Cookie 和请求头发起请求 → 拿到 JSON 或 HTML → 解析出博文 ID 和基础字段 → 根据需要再请求详情页补全评论或转发数据。这里有个关键点搜索接口返回的字段往往不全正文可能被截断图片和视频链接也可能缺失。所以如果业务需要完整正文得在拿到博文 ID 后再发一次详情请求。这一步会增加请求量但字段完整度会高很多。我一般会在配置里加一个开关控制是否补全详情避免在只需要标题和互动量的时候浪费请求配额。2.3 数据落盘字段设计与存储格式的选择存储这块常见做法是先用 CSV 或 JSON Lines 落文件跑通之后再考虑入库。CSV 的好处是直观用 Excel 就能打开检查JSON Lines 的好处是字段可以嵌套适合存评论列表这种一对多的结构。这套爬虫大概率两种都支持或者至少留了扩展接口。字段设计上我建议至少保留这几列博文 ID、用户 ID、昵称、发布时间、正文、转发数、评论数、点赞数、来源终端。如果要做传播分析还得加上转发链的父节点 ID。这些字段在解析模块里应该都有对应但字段名可能和你的下游系统不一致落盘前最好做一层映射。# 字段映射示例把爬虫输出对齐到下游分析表 FIELD_MAP { mid: post_id, user_id: uid, screen_name: nickname, created_at: publish_time, text: content, reposts_count: repost_num, comments_count: comment_num, attitudes_count: like_num, source: device } def normalize_record(raw: dict) - dict: 把原始字段名转成下游统一字段名 return {FIELD_MAP.get(k, k): v for k, v in raw.items()}这段代码做的是字段名归一化。FIELD_MAP左边是爬虫原始字段右边是你下游系统用的字段。normalize_record函数遍历原始字典能映射的就换名映射不上的保留原名。这样后面换数据源或者改字段的时候只需要改映射表不用动解析逻辑。3. 环境准备与首次运行把脚本跑起来的最小闭环拆完结构下一步是让它跑起来。这一步的目标不是抓多少数据而是验证整条链路通不通。3.1 依赖安装与 Python 版本选择先看requirements.txt或者脚本头部的 import。常见的依赖包括requests、beautifulsoup4、lxml、pandas如果用了异步可能是aiohttp。Python 版本建议 3.8 以上3.10 更稳因为有些库对新版本的支持更好。安装依赖的时候我一般会建一个虚拟环境避免和系统里的包冲突。命令不复杂python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt如果requirements.txt里没锁版本建议手动锁一下主要库的大版本比如requests2.28,3.0避免以后重装环境时因为库升级跑不起来。3.2 Cookie 与请求头的配置方法微博的搜索接口对登录态有要求没有 Cookie 基本拿不到数据。配置 Cookie 的常见做法是浏览器登录后打开开发者工具在 Network 面板里找一条搜索请求把 Request Headers 里的 Cookie 整段复制出来粘贴到配置文件的对应字段。请求头里除了 Cookie还要注意User-Agent、Referer、X-Requested-With这几个。User-Agent建议用真实浏览器的不要用脚本默认的。Referer一般填搜索页的 URL。X-Requested-With填XMLHttpRequest有些接口会检查这个头。注意Cookie 是有有效期的通常几天到几周不等。跑批量任务前先手动测一条请求确认返回的是数据而不是登录页。3.3 跑通第一条请求参数含义与返回检查配置改好之后先别急着跑全量。我一般会写一个最小测试脚本只发一条请求把返回内容打印出来看看。import requests import json # 从配置文件读取这里用占位符示意 HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..., Cookie: 你的Cookie字符串, Referer: https://weibo.com/, X-Requested-With: XMLHttpRequest } def test_one_request(keyword: str, page: int 1): 发一条搜索请求检查返回结构 url https://weibo.com/ajax/statuses/searchProfile params { q: keyword, page: page, count: 10 } resp requests.get(url, headersHEADERS, paramsparams, timeout10) print(状态码:, resp.status_code) data resp.json() # 检查关键字段是否存在 if data in data and list in data[data]: print(拿到博文数:, len(data[data][list])) print(第一条:, json.dumps(data[data][list][0], ensure_asciiFalse)[:200]) else: print(返回结构异常:, json.dumps(data, ensure_asciiFalse)[:300]) test_one_request(测试关键词)这段代码的作用是验证请求链路。params里的q是搜索词page是页码count是每页条数。返回的 JSON 里data.list通常是博文数组。如果这个结构对不上说明接口变了或者 Cookie 失效了。打印第一条数据是为了确认字段名和内容是否符合预期。跑通这一步之后再把逻辑接回主脚本批量翻页就有底了。4. 采集策略与参数调优翻页、去重与频率控制链路通了之后真正影响数据质量和账号安全的是采集策略。这部分调不好要么抓不全要么抓一半被限流。4.1 翻页终止条件的判断逻辑翻页什么时候停不能只看「返回为空」。微博搜索接口在翻到一定深度后可能返回重复数据或者空列表也可能直接返回错误码。我一般会设三个终止条件连续两页返回空、连续两页数据完全重复、达到配置的最大页数。这三个条件满足任意一个就停。另外搜索结果的排序方式也会影响翻页。按时间排序和按热度排序翻页深度限制不一样。按时间排序通常能翻得更深适合做历史数据回溯按热度排序翻几页就到底了适合抓热点。def should_stop(current_page_data: list, last_page_ids: set, max_pages: int, current_page: int) - bool: 判断是否停止翻页 if current_page max_pages: return True if not current_page_data: return True current_ids {item.get(mid) for item in current_page_data} if current_ids and current_ids.issubset(last_page_ids): return True return False这个函数接收当前页数据、上一页的 ID 集合、最大页数和当前页码。先判断是否到最大页数再判断是否空页最后判断是否和上一页完全重复。issubset用来检查当前页 ID 是否全部出现在上一页里如果是说明翻页没带来新数据可以停了。4.2 去重策略基于博文 ID 的集合维护去重这件事最稳的是用博文 ID 做唯一键。每抓一页把新出现的 ID 加进一个全局集合落盘前再过滤一遍。如果数据量很大集合放内存吃不消可以用布隆过滤器或者落库后做唯一索引。我一般会在存储模块里加一层去重而不是在解析模块做。因为解析模块只管把响应转成记录去重是跨页面的逻辑放在存储层更合适。具体做法是维护一个seen_ids集合每次写入前检查写完再更新集合。提示如果中途断了要续跑记得把seen_ids持久化到文件或数据库不然重启后会重复抓。4.3 请求频率与随机延迟的设置频率控制是保账号的关键。微博对高频请求比较敏感尤其是同一个 Cookie 短时间发大量请求。常见做法是每请求一次 sleep 一个随机区间比如 2 到 5 秒。如果用了并发并发数不要超过 3并且每个协程独立延迟。配置里如果有delay或sleep参数先按默认值跑观察返回状态。如果出现 418 或 403说明频率高了把延迟调大。如果跑得很稳可以适当缩小延迟但别低于 1 秒。import time import random def polite_delay(base: float 2.0, jitter: float 3.0): 随机延迟避免固定间隔被识别 time.sleep(base random.random() * jitter)base是最小延迟jitter是随机增量。这样每次 sleep 的时间在 2 到 5 秒之间浮动比固定 3 秒更自然。如果目标数据量不大可以把base调到 3 以上更稳妥。5. 避坑与排查跑微博爬虫最容易翻车的五个地方这套爬虫的代码逻辑不算复杂但微博侧的变动和反爬策略会让很多「看起来没问题」的配置突然失效。下面这几条是我实际跑的时候踩过的按现象、原因、解决三段来说。5.1 返回 200 但数据为空现象请求状态码是 200但data.list是空数组或者返回的 HTML 里没有博文节点。原因最常见的是 Cookie 过期登录态失效后接口返回的是空数据而不是 401。其次是搜索词被限流某些敏感词或高频词会返回空结果。还有一种可能是请求头里的Referer不对接口做了来源校验。解决先换一个新 Cookie 再试。如果换完还是空把搜索词换成更通用的词测试。再不行就检查Referer和X-Requested-With是否和浏览器一致。我一般会保留一个「测试模式」用固定关键词跑一条确认链路没问题再跑正式任务。5.2 翻页到第 N 页后返回重复数据现象前几页数据正常翻到第 5 页或第 10 页之后返回的博文 ID 和前面重复或者直接返回第一页的内容。原因微博搜索接口对未登录或低权重账号有翻页深度限制超过一定页数后不再返回新数据而是循环返回前面的结果。另外如果请求间隔太短也可能触发这个限制。解决在翻页逻辑里加去重判断发现连续两页 ID 重复就停。同时把请求延迟调大给账号「降速」。如果确实需要更深的历史数据可以改用按时间分段的方式把大范围拆成多个小时间段每个时间段单独翻页。5.3 Cookie 失效导致中途断抓现象任务跑到一半突然开始返回登录页或者空数据前面抓的都正常。原因Cookie 的有效期到了或者账号在别处登录导致当前会话失效。微博的 Cookie 有效期不固定有时候几小时就失效。解决在请求封装里加一个失效检测发现返回内容不符合预期就抛异常并记录当前页码。重新获取 Cookie 后从断点继续跑。如果任务时间长建议把大任务拆成小批次每批跑完就落盘减少单次依赖 Cookie 的时间窗口。5.4 字段缺失或类型不一致现象落盘后发现某些行的reposts_count是空值或者created_at格式和其他行不一样。原因微博返回的 JSON 里有些字段可能不存在或者在不同接口版本里类型不同。比如互动量有时候是数字有时候是字符串。时间格式也可能因为来源不同而有差异。解决在解析模块里加默认值和类型转换。数字字段用int(x or 0)兜底时间字段统一转成YYYY-MM-DD HH:MM:SS格式。落盘前跑一遍校验把异常行单独存一份方便排查。5.5 并发过高触发限流现象开了多线程或异步之后请求成功率骤降大量返回 418 或 403。原因微博对同一 IP 或同一 Cookie 的并发请求有阈值超过就限流。很多人为了快把并发开到 10 以上结果反而更慢。解决把并发降到 2 到 3并且每个并发任务独立延迟。如果还是被限就改成单线程加随机延迟。速度虽然慢一点但成功率会高很多。我一般会先单线程跑通再逐步加并发观察成功率变化找到那个「刚好不被限」的平衡点。6. 进阶技巧把采集结果接进分析流程的实用做法跑通采集只是第一步数据拿到之后怎么用才是这套资源真正发挥价值的地方。我一般会在爬虫和下游分析之间加一层轻量处理把原始数据转成分析友好的格式。6.1 用 Pandas 做快速清洗与字段衍生原始数据落成 CSV 之后用 Pandas 读进来做几件事时间字段转 datetime、互动量转数值、正文去 HTML 标签、按用户聚合统计发博频次。这些操作几行代码就能搞定但能省掉后面很多手工处理。import pandas as pd import re def clean_weibo_data(csv_path: str) - pd.DataFrame: 读取原始 CSV 并做基础清洗 df pd.read_csv(csv_path) # 时间转 datetime df[publish_time] pd.to_datetime(df[publish_time], errorscoerce) # 互动量转数值空值填 0 for col in [repost_num, comment_num, like_num]: df[col] pd.to_numeric(df[col], errorscoerce).fillna(0).astype(int) # 正文去 HTML 标签 df[content_clean] df[content].astype(str).apply( lambda x: re.sub(r[^], , x) ) # 衍生字段是否含链接、正文长度 df[has_link] df[content_clean].str.contains(http) df[content_len] df[content_clean].str.len() return df df clean_weibo_data(weibo_raw.csv) print(df[[publish_time, content_len, like_num]].describe())这段代码做了四件事时间转标准格式、互动量转整数、正文去标签、衍生链接标记和长度字段。errorscoerce的作用是遇到无法转换的值不报错直接变成NaT或NaN后面再统一处理。describe()用来快速看数值分布确认清洗结果合理。6.2 按时间窗口聚合做传播趋势分析清洗完之后按小时或按天聚合能看出话题的传播节奏。比如按小时统计发博量找到峰值时段按用户统计发博量找到关键传播节点。这些分析不需要复杂模型用 Pandas 的groupby就能做。我一般会先按小时聚合看整体趋势再按用户聚合看头部账号。如果要做传播路径还得把转发关系单独抽出来构建父子边列表。这部分数据如果爬虫没抓可以后续用博文 ID 单独补。6.3 采集任务的断点续跑与增量更新最后说一个实用习惯每次跑采集任务都把已抓的博文 ID 和最大时间戳存下来。下次跑的时候从最大时间戳往后增量抓避免重复。如果任务中断也能从断点继续不用从头再来。具体做法是在存储模块里加一个checkpoint.json记录last_max_time和seen_ids的持久化路径。每次落盘后更新这个文件启动时先读。这个习惯看起来简单但能省掉很多重复劳动。从那以后我每次跑批量采集都强制走一遍断点检查确认续跑逻辑没问题再开正式任务。希望帮到你。本文还有配套的精品资源点击获取