简介：这是一份面向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里没锁版本，建议手动锁一下主要库的大版本，比如requests>=2.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, headers=HEADERS, params=params, timeout=10) 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_ascii=False)[:200]) else: print("返回结构异常:", json.dumps(data, ensure_ascii=False)[: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"], errors="coerce") # 互动量转数值，空值填 0 for col in ["repost_num", "comment_num", "like_num"]: df[col] = pd.to_numeric(df[col], errors="coerce").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())这段代码做了四件事：时间转标准格式、互动量转整数、正文去标签、衍生链接标记和长度字段。errors="coerce"的作用是遇到无法转换的值不报错，直接变成NaT或NaN，后面再统一处理。describe()用来快速看数值分布，确认清洗结果合理。
6.2 按时间窗口聚合做传播趋势分析
清洗完之后，按小时或按天聚合，能看出话题的传播节奏。比如按小时统计发博量，找到峰值时段；按用户统计发博量，找到关键传播节点。这些分析不需要复杂模型，用 Pandas 的groupby就能做。
我一般会先按小时聚合看整体趋势，再按用户聚合看头部账号。如果要做传播路径，还得把转发关系单独抽出来，构建父子边列表。这部分数据如果爬虫没抓，可以后续用博文 ID 单独补。
6.3 采集任务的断点续跑与增量更新
最后说一个实用习惯：每次跑采集任务，都把已抓的博文 ID 和最大时间戳存下来。下次跑的时候，从最大时间戳往后增量抓，避免重复。如果任务中断，也能从断点继续，不用从头再来。
具体做法是在存储模块里加一个checkpoint.json，记录last_max_time和seen_ids的持久化路径。每次落盘后更新这个文件，启动时先读。这个习惯看起来简单，但能省掉很多重复劳动。从那以后我每次跑批量采集，都强制走一遍断点检查，确认续跑逻辑没问题再开正式任务。希望帮到你。
本文还有配套的精品资源，点击获取
