简介针对微博平台的数据采集需求这份基于Python的完整实现覆盖了从网络请求、HTML/JSON解析、模拟登录到反爬处理、数据存储的全流程。资源以Python爬虫为核心兼顾requests、urllib、BeautifulSoup、json等库的实战用法并为学习者梳理了爬虫中的异常处理、异步提效、微博官方API以及合规边界适合有一定Python基础的开发者快速上手微博数据抓取。压缩包共包含18个文件以13个Python脚本为主辅以3个Markdown说明文档、1个说明压缩包和1个配置文件整体体积仅90KB。脚本按功能划分模块覆盖数据抓取、任务创建、用户搜索等场景说明文档可用于快速理解项目结构和运行逻辑。这份资源已吸引335人学习下载体量虽小但结构清晰提供了项目说明、工具脚本与运行配置等可直接参考的内容可帮助读者从代码层面掌握微博数据爬取的实现思路并在实际项目中快速复用或改造。1. Python 微博数据爬取这套资源包里到底有什么值不值得花时间拆做舆情监测、热点事件追踪或电商口碑分析的人大概率绕不开微博数据。很多人一上手就抓网页版 HTML结果 DOM 结构一改解析器全线崩盘每周修选择器都能修出心理阴影。我拆过这份 Python微博数据爬取.zip核心思路不是硬碰网页版而是绕到移动端接口用 cookie 维持登录态以 JSON 形式拉取搜索和用户时间线数据再统一落库。这套方案对 python 版本依赖轻、脚本结构清晰、可替换性高适合需要短周期采集公开数据的开发者和数据分析人员。下面把可直接复现的部分、参数含义和踩过的坑一次说清新手能跟步骤走熟手可以直接翻到避坑章节核对边界和补偿策略。2. 前置准备cookie 持久化、请求头与容器接口选型2.1 为什么绕开网页版 HTML 解析网页版的数据流是服务端渲染加前端异步混搭正文、转发数、时间戳分散在多个 DOM 节点里class 名还在不停加盐。用 BeautifulSoup 或 XPath 定位节点今天写好的选择器明天可能就全军覆没。移动端接口的返回是结构化 JSON字段命名相对稳定而且移动端流量在整个反爬体系里的限流阈值比桌面端宽松。这不是玄学是维护成本的现实考量——同样的采集任务走 HTML 解析每周要修一次脚本走移动端 JSON 基本可以一个月不动。资源包选定移动端接口还有一层原因搜索和用户时间线两个场景共用同一套分页协议容器和数据流的取数逻辑一致。这样可以只维护一个 fetch 函数、一个解析函数按场景传不同的 containerid 参数。对中小规模采集任务来说少一半代码就意味着少一半出错面。网页版 HTML 解析并非不能跑但它更适合低频单页抓取不适合规模化落库。2.2 登录态与 cookie 的获取和持久化微博的搜索接口和用户主页时间线都需要登录态。资源包的默认做法不依赖 Selenium而是手动登录一次移动端页面从浏览器开发者工具里复制 SUB 和 SUBP 两个 cookie 值写入独立配置文件。cookie 不写死在采集脚本里便于过期后快速替换也让代码可以直接分享而不会泄露凭据。# config.py COOKIE SUB你的SUB值; SUBP你的SUBP值 BASE_HEADERS { User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15, Accept: application/json, text/plain, */*, Referer: https://m.weibo.cn/, X-Requested-With: XMLHttpRequest, }COOKIE 字段用分号拼接多个键值对requests 的 Session 会自动解析成独立 cookie。Referer 必须指向移动端域名否则接口直接返回 403。User-Agent 选 iPhone 机型是移动端接口最常见的行为特征比桌面端 UA 的通过率高很多。这里有一个容易被忽略的细节SUBP 过期时间通常比 SUB 短只换 SUB 不换 SUBP接口照样会飘验证码。我一般会两个一起换省一次排查。2.3 请求头配置与容器接口选型实际操作里接口选型就是两个 URL 模板加一个 containerid 探测逻辑。搜索接口模板https://m.weibo.cn/api/container/getIndex?containerid100103type1q关键词page_typesearchallpage1用户时间线接口模板https://m.weibo.cn/api/container/getIndex?containerid230283{uid}_-_profile_-_weibopage1containerid 是移动端数据流的核心标识。搜索场景里先用一个不带关键词的请求拿到搜索页预设的 containerid再拼上关键词翻页。因为 containerid 偶尔会在版本更新后变动资源包的做法是启动时先热探测一次搜索页把返回的 containerid 缓存到本地文件而不是硬编码在脚本里。这个细节能少踩一半的坑后面避坑章节会再提。缓存文件建议用 JSON 存储包含 containerid 和探测时间每次启动前检查是否超过 24 小时超过则重新探测。探测量只有一次请求成本极低但对稳定性提升明显。搜索接口有时会返回多条 containerid 分组比如综合、实时、热门分别对应不同 id资源包默认取第一个如果需要分类型采集可以在配置里多加一个字段手动指定。提示cookie 里的 SUB 属于账号凭据不要提交到公开仓库。部署机建议用环境变量注入config.py 只留占位符。3. 核心采集搜索接口翻页与用户时间线游标抓取3.1 搜索接口的请求构造与翻页逻辑搜索接口返回的 JSON 结构是外层 code datadata 里是 cards 数组。每个 card 代表一条微博或一个内容块。真正的博文 card 的 card_type 是 9card_type 为 11 的是推荐位、38 是热搜词条都要过滤掉。资源包的核心采集函数是这样的import requests def fetch_search(session, keyword, page1): url https://m.weibo.cn/api/container/getIndex params { containerid: f100103type1q{keyword}, page_type: searchall, page: page, } resp session.get(url, paramsparams, timeout10) data resp.json() if data.get(code) ! 0: raise RuntimeError(f搜索接口返回异常: {data.get(msg, )}) cards data.get(data, {}).get(cards, []) results [] for card in cards: if card.get(card_type) ! 9: continue mblog card.get(mblog, {}) results.append(mblog) return results这个函数只做一件事按关键词和页码拉数据过滤非博文卡片返回 mblog 列表。session 由外部传入让多个请求复用同一套 cookie 和连接池避免每次请求重新握手。params 里 page_type 固定为 searchall表示综合搜索想看原创结果改成 search_orig想看热门改成 search_hot。timeout 设 10 秒平台响应慢时快速失败而不是让线程无限挂起。翻页逻辑的关键是判断是否真的到底。常见做法是循环请求直到返回空 cards但这里有个陷阱搜索接口有单页条数上限超过之后第 N 页和第 N1 页返回相同内容cards 不为空但全是重复。正确判断方式是记录本页第一条微博的 id和上一页最后一条对比一旦出现重复就停止翻页。资源包在循环里维护一个 last_id 变量每次迭代比对日后再加去重逻辑也能直接复用这个判断。3.2 用户时间线的游标翻页用户时间线同样走 containerid 分页但不用 page 数字而是用 since_id 游标。这个 uid 也不是用户主页 URL 里的数字串而是接口返回的 user.id 字段。很多新手在这里翻车把网页版 URL 里的数字当 uid请求直接 404。正确拼法是 containerid 为230283{uid}_-_profile_-_weibo。def fetch_user_timeline(session, uid, since_idNone): url https://m.weibo.cn/api/container/getIndex params {containerid: f230283{uid}_-_profile_-_weibo} if since_id: params[since_id] since_id resp session.get(url, paramsparams, timeout10) data resp.json() if data.get(code) ! 0: raise RuntimeError(f时间线接口异常: {data.get(msg, )}) info data.get(data, {}) cards info.get(cards, []) next_since info.get(cardlistInfo, {}).get(since_id) return cards, next_sincesince_id 是服务端生成的游标每次返回的 cardlistInfo.since_id 就是下一页入口。循环里把它传给下一次请求直到 since_id 为空。这个设计比数字页码抗数据变化用户在两次翻页之间新发微博也不会打乱游标顺序。资源包在这里做了双保险过滤 card_type 为 9 的博文之外还把 card_type 为 11 的置顶推荐一并滤掉避免把推广内容混进数据集。3.3 字段映射从平台命名到业务字段mblog 里的字段是平台内部命名直接落库不友好。资源包写了一个 mapper 函数统一转换把平台字段映射成业务字段名import json def map_mblog(mblog): user mblog.get(user) or {} return { id: mblog.get(id), bid: mblog.get(bid), text: mblog.get(text, ), created_at: mblog.get(created_at, ), reposts_count: mblog.get(reposts_count, 0), comments_count: mblog.get(comments_count, 0), attitudes_count: mblog.get(attitudes_count, 0), uid: user.get(id) or , screen_name: user.get(screen_name, ), raw: json.dumps(mblog, ensure_asciiFalse), }id 是平台内部唯一标识bid 是短链接里的字符串两者都能用来去重具体业务里 id 更可靠bid 适合做人肉核验。text 字段可能含 HTML 标签和表情转义清洗放下一步。raw 字段把原始 JSON 原样保存以后想补新字段就不用重新爬。这种整包存档 字段抽取的双层结构是长线采集项目的标准做法映射规则变了重跑解析函数即可网络请求一次都不用再发。字段映射顺序也有讲究先取 user 再取文本避免 user 缺失时整条报错。实际使用里text 字段往往还包含 video、url_struct 等附属信息如果做链接分析可以在 mapper 里额外加一项 urls把 url_struct 里的完整链接单独抽出来和 text 分开存储方便后续展开短链。4. 落地存储文本清洗、主键去重与增量游标4.1 文本清洗与字段规整微博正文里全是 HTML 标签、微博表情转义、提及和话题符。清洗规则取决于业务情感分析要保留 提及和话题符词频统计则全删。资源包默认提供一套中性清洗HTML 标签剥掉、实体转回字符、零宽空格移除import re import html def clean_text(raw_text): text html.unescape(raw_text) text re.sub(r[^], , text) text re.sub(rnbsp;, , text) text text.replace(\u200b, ) return text.strip()html.unescape 把 之类的实体先转回字符剥标签时才不会误伤。\u200b 是零宽空格肉眼看不见但进到分词阶段会把 tokenizer 折腾得够呛。清洗放在入库前而不是入库后是为了保住原始数据可追溯性。资源包的默认策略是 raw 字段存原始 JSONtext_clean 字段存清洗结果两者并列互不覆盖。后续换清洗规则改一版清洗函数批量重跑清洗列就行原始数据永远还在。时间字段的坑更多人踩。接口返回 created_at 是类似刚刚5分钟前昨天的相对时间直接存文本没法排序。资源包写了个时间转换函数先匹配刚刚和N分钟前再匹配N小时前最后匹配带日期的绝对格式转换成标准时间戳正则处理不了的兜底置为 None。处理规则宁缺毋滥——猜错时间比留空更伤数据质量。4.2 去重策略与入库采集任务跑上几轮重复是必然事件。去重键选 mblog.id平台内部 ID 稳定唯一。资源包在 SQLite 里给 id 建主键插入用 INSERT OR IGNORE数据库层面完成去重不依赖采集脚本的判断逻辑import sqlite3 import time DB_PATH weibo.db def init_db(): conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS weibo_posts ( id TEXT PRIMARY KEY, bid TEXT, uid TEXT, screen_name TEXT, text_clean TEXT, created_at TEXT, reposts_count INTEGER, comments_count INTEGER, attitudes_count INTEGER, raw_json TEXT, fetched_at TEXT ) ) conn.commit() return conn def save_posts(conn, posts): rows [( p[id], p[bid], str(p[uid]), p[screen_name], p[text_clean], p[created_at], p[reposts_count], p[comments_count], p[attitudes_count], p[raw], time.strftime(%Y-%m-%d %H:%M:%S) ) for p in posts] conn.executemany( INSERT OR IGNORE INTO weibo_posts VALUES (?,?,?,?,?,?,?,?,?,?,?), rows ) conn.commit()SQLite 单机处理几百万条毫无压力。fetched_at 记录采集时间和 created_at 放一起可以做采集时间 vs 发布时间的双维分析能发现平台是否存在内容回溯或补删。如果预期数据量过千万后期可以换 MySQL 或 ClickHouse但表结构和去重逻辑不用改——先定标准 Schema 的价值就在这里。4.3 增量采集的游标设计增量采集的核心是记住上次看到哪。搜索场景用 keyword 做 key 存最后一条微博 id用户时间线场景用 uid 存 last_since_id。资源包单独建了一张 meta 表def load_since_id(conn, uid): row conn.execute( SELECT since_id FROM user_meta WHERE uid ?, (str(uid),) ).fetchone() return row[0] if row else None def save_since_id(conn, uid, since_id): conn.execute( INSERT OR REPLACE INTO user_meta (uid, since_id, updated_at) VALUES (?, ?, ?), (str(uid), since_id, time.strftime(%Y-%m-%d %H:%M:%S)) ) conn.commit()meta 表和业务表分离好处是游标更新失败不会污染业务数据。每次采集流程读游标 → 拉新数据 → 入库 → 更新游标。这个顺序里入库和更新游标之间如果程序崩溃下一轮会重拉部分数据靠主键去重兜底。since_id 失效是常态如果返回空 cards 但 since_id 非空说明游标过期常见做法是回退用页面数字重扫最近 50 页做补偿。补偿逻辑放避坑章节细讲。5. 爬取避坑cookie 失效、限流回跳与数据异常排查5.1 cookie 失效与验证码跳转现象脚本跑着跑着接口开始连续返回 code 为 417 的响应或者返回的 cards 全是空列表日志没有报错但采集量断崖式下跌。原因SUB 值过期或账号被判定为异常登录接口悄悄切到验证码通道。移动端接口在 cookie 失效时不一定会返回 401更多时候返回空数据或引导页结构造成接口正常但没数据的假象。解决在 fetch 函数里加响应结构检测发现 code 不为 0 或 data 里缺 cards 字段时立即抛明确异常并停止采集别静默返回空列表。我在资源包基础上加了个健康检查每采集 100 条就主动请求一次用户主页接口返回码异常就写日志并休眠 10 分钟。cookie 过期没有捷径只能重新登录换新 cookie。把换 cookie 流程脚本化成半自动能省不少人工盯屏时间。5.2 限流与封禁现象请求频率稳定在每秒 1 次跑了半小时后部分接口随机返回 504 或空响应重试能恢复但恢复间隔越来越长。原因平台的限流不是简单按 IP QPS 封顶而是滑动窗口加行为特征的多重判定。固定频率请求反而容易被识别成脚本。另一个常见误用是多个任务共享一个 session 并发跑连接数一拉高风控阈值立刻被打满。解决把请求间隔从固定值改成随机区间比如 1.5 到 3.5 秒随机模拟人工浏览的抖动。并发严格控制在单 session 串行执行多线程扩并发是这条路上最典型的翻车姿势。我一般按 uid 分片每个分片独立进程跑进程之间用 meta 表协调游标而不是单进程内开线程抢带宽。被封禁后不要对抗停半小时再起连续被封三次就降每天总请求量优先保数据完整性而不是速度。5.3 数据内容异常与字段缺失现象采到的正文出现大量抱歉此微博已被作者删除类占位文本或者 user 字段缺失导致 uid 和 screen_name 为空。原因已删除或进入审核的微博在接口里保留 card 骨架但 mblog 内容被替换成占位符。历史微博的 user 字段会整体缺失这是接口兼容性问题不是请求参数写错。解决在 map_mblog 里加字段存在性检查。占位文本不能只判断 text 为空要匹配平台特定的删除提示句式。user 缺失时uid 用请求里的 uid 兜底screen_name 置 unknown保证每行数据都有主键和归属。这个判断要写进采集脚本而不是清洗脚本原始 JSON 一旦落库再发现缺字段就得重爬一遍成本太高。5.4 重复数据与游标回跳现象增量采集时同一个 id 的微博连续两轮跑到且时间线游标指向了比上一轮更早的位置老数据被反复重抓。原因since_id 是服务端生成的临时游标有有效期。如果单用户时间线拉取速度慢游标可能在下一次请求前失效服务端回退返回更早的数据。解决采集前记录当前最大 created_at 水位线本轮结束后检查最后一次写入的 created_at 是否早于水位线如果是则丢弃该批次并重试。另一个更稳的做法meta 表里同时存 last_since_id 和 max_since_id每轮取较大的一个更新。游标对比更精确建议作为默认方案水位判断简单但不适合按时间倒序回溯历史数据的场景。两种我都用过游标对比的误判率明显更低。6. 进阶采集结果核验与自动补采的两个习惯6.1 从被采集方视角核验字段每次改完字段映射函数抽 3 条采到的 bid直接在移动端打开对应微博页拿页面展示的转发数、评论数、点赞数和库里对比。字段映射错位是整条链路里最隐蔽的问题接口字段名和业务字段名没有一一对应关系不主动核验很难发现。我习惯把核验做成独立脚本输入 bid 列表输出库内值和接口实时值的差异表方便一眼定位。6.2 用双写日志做数据差异对比采集脚本每写一批数据同时把本批次的 id 集合追加到当日日志文件。隔天拉取时把前一天日志里的 id 集合和本轮新写入数据做差集。差集非空说明这段事件里微博被删除或隐藏——这在舆情分析里本身就是有价值的信号。我把差集单独存成 deleted_log 表跑了几周后发现某个话题的删除率达到 3%比正常值高一截顺着查下去是水军账号在集中删帖。6.3 增量推送与自动补采资源包本身不带调度器我习惯在外面包一层系统定时任务每天固定时间触发增量采集。采集完统计本批次新增数如果低于历史均值的 30%判定为异常触发一次全量补偿采集最多补偿三轮。从那以后我每次部署采集项目都会先写一个健康检查 异常补偿的壳再进入正常增量循环。数据采集最怕的不是跑得慢而是静默地少采了一个窗口还没人发现。回到最初拆这套 Python微博数据爬取 资源包的经验真正值钱的不是那几段请求代码而是这套核验、补偿、存档的闭环。希望帮到你。本文还有配套的精品资源点击获取