简介：面向需要快速采集微博历史数据的Python学习者与爬虫开发者，围绕“微博辟谣”账号，展示了一套基于selenium的完整采集工程。项目同时覆盖移动版与PC网页版两种渠道，在单页面内采用多线程抓取内容，并以多线程异步方式处理多个页面，对理解动态网页渲染、页面解析和并发调度有直接参考价值。压缩包共15个文件，包含10个py源码、3个xlsx结果文件、1个md说明文档及1个gitignore，整体仅41KB，轻量易部署。py文件按main、crawl_handle、批量/单行爬取等模块拆分，xlsx为不同采集场景下的输出样例，md记录使用指引，结构清晰，适合快速定位学习重点。已有1072人学习下载。资料提供的不仅是可直接运行的案例，还配合作者博客专题中的源码分析，能帮助赶时间的同学快速还原环境配置、驱动安装、多线程调度等关键环节，减少从零摸索的成本。1. 微博数据采集离不开Python和Selenium：一个能自己跑完的采集管线我在模拟项目X里接过一个需求：每天把30个指定博主的微博正文、发布时间、转发量存档。最开始用requests直接请求页面，拿到的是半空壳，大量内容要靠接口二次签名，维护成本极高。最后落地的方案就是基于Python+Selenium的采集工程，也就是标题里这类WBCrawler.zip——用真实浏览器渲染页面，直接读DOM，绕开逆向接口签名的过程。这类工程解决的问题很具体：微博页面大量内容由JavaScript动态渲染，普通HTTP请求拿不全；页面还有登录校验和反自动化检测，脚本跑久了容易静默失败。Selenium的定位就是控制浏览器打开页面，模拟人的滚动、等待、点击，再把正文、时间、评论数按选择器摘下来。如果要做长期、结构化、可复现的微博数据采集，这套思路值得投入。下文从选型、登录态、采集循环到踩坑，按一个真实工程的顺序展开，每段都可以直接抄进你自己的WBCrawler。2. 登录态是采集的第一道关：Cookie注入与user-data-dir复用的取舍采集微博数据，遇到的第一个问题往往不是解析，而是能不能一直带着登录态。网页版不登录能看一部分内容，但评论数、完整正文、转发明细这类字段基本都要登录后才稳定出现。更麻烦的是登录态会在采集途中过期，脚本一旦没有感知，后半段全部采成登录页的同一份空数据。我的习惯是先把登录方案定死，再写解析逻辑。常见做法是两种：一种是把登录后的Cookie导出，程序启动时再注入；另一种是让Selenium复用浏览器用户数据目录。我两种都试过，最后长期用的是后者。下面先说清为什么Selenium更适合微博采集，再给一套可以直接跑的登录代码。2.1 为什么选Selenium而不拿requests硬啃直接请求HTML能不能拿到微博内容？能拿到一部分。微博信息流是典型的动态渲染页面，首屏HTML只有骨架和少量初始化数据，真正的微博正文、发布时间、转发数是由JavaScript在浏览器里异步请求接口后渲染出来的。直接用requests请求页面，得到的是半空壳；要拿全数据，要么去逆向接口签名，要么让浏览器替我们执行这些脚本。接口逆向这条路不是不能走，但维护成本很现实：微博接口的请求里带时间戳、随机参数和签名校验字段，某些字段的生成逻辑黑匣子一样，页面改版或参数规则调整后，爬取代码就要跟着返工。Selenium的做法是把“执行JavaScript”这件事交给真实浏览器，脚本只负责打开页面、滚动、等待元素出现、读取DOM。换来的是稳定性，代价是速度和资源占用。方案数据完整性维护成本适合场景requests直接抓HTML低，拿不到动态渲染内容低但数据残只抓静态元数据requests逆向接口高，但依赖签名算法高，规则一变就返工有专业逆向能力的小团队Selenium渲染页面高，跟随真实页面中，选择器有维护成本长期稳定采集如果你的需求是一次性抓几百条数据，用requests硬啃没有问题；但像WBCrawler这种要每天跑、要断点续采、要换账号的工程，Selenium的稳健性会省掉很多半夜被叫醒的麻烦。2.2 用user-data-dir留住登录态：第一次手动登录，以后自动复用Selenium登录方案有两条常见路线。一条是Cookie注入：手工登录后把Cookie导出成字符串，启动时通过driver.add_cookie灌进去。优点是可以把Cookie放在配置里，多台机器共用；缺点是一旦Cookie过期，脚本不会自己重新登录，而且微博的Cookie里带有校验用的字段，简单拷贝有时候会被拒绝。另一条是复用浏览器用户数据目录，也就是user-data-dir，我更推荐这条。user-data-dir的原理很直接：Selenium启动浏览器时指定一个本地目录，浏览器的Cookie、LocalStorage、会话数据都写进这个目录。第一次启动时你手动登录一次，之后每次启动都复用这份数据，不需要再把Cookie字符串塞进代码。对长期采集来说，这个方案比Cookie注入更省心，也避免了Cookie硬编码在配置文件里的泄露风险。from selenium import webdriver from selenium.webdriver.chrome.options import Options opts = Options() # 第一次先手动登录，之后复用这个目录里的登录态 opts.add_argument("user-data-dir=./wd_profile") # 固定窗口尺寸，避免页面响应式布局导致元素位移 opts.add_argument("window-size=1440,900") # 去掉“正在受自动化软件控制”的提示条 opts.add_experimental_option("excludeSwitches", ["enable-automation"]) driver = webdriver.Chrome(options=opts) driver.get("https://weibo.com") # 按实际登录页地址替换这段代码里，user-data-dir=./wd_profile最关键：目录不存在时浏览器会新建，登录后所有状态都留在这个目录里；window-size=1440,900是让页面按固定视口渲染，避免不同分辨率下元素坐标漂移；excludeSwitches参数去掉自动化横幅，减少一部分前端检测的触发概率。第一次运行时，浏览器窗口会弹出来，你手动登录一次，再关掉程序，后续启动就自带登录态了。2.3 登录态失效怎么发现：不能等到采完才察觉登录态是会过期的，而且过期后页面常常不报错，只是把内容区悄悄换成登录引导或者空白状态。如果你的采集循环里没有“登录态探测”，脚本会继续滚动、继续解析、继续写入，最后给你产出一堆没用的数据。我一般会在启动后先做一次轻量探测，用“是否还能看到登录入口”作为判断依据。from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def ensure_login(driver): wait = WebDriverWait(driver, 10) try: # 已登录页面通常看不到醒目的“登录”按钮 login_btn = wait.until( EC.visibility_of_element_located((By.XPATH, "//*[contains(text(),'登录')]")) ) print("登录态已失效，请在弹出的浏览器中手动登录") input("登录完成后按回车继续...") except Exception: print("登录态有效，开始采集")这段探测代码用的是“反向判断”：如果能在10秒内等到一个包含“登录”文本的可见元素，就说明当前是未登录状态；如果等不到，默认登录态还在。注意它只适合有人值守的第一版。无人值守跑过夜时，我会把input()改成“检测到失效就停止写数据并保留截图”，具体做法放到后面避坑章节里展开。3. 核心采集逻辑：滚动加载、字段解析与增量落盘登录打通之后，真正决定采集质量的是三个环节：页面滚动怎么驱动、DOM字段怎么稳定提取、数据怎么落盘才能断点续采。这三个环节分别对应微博信息流的懒加载机制、前端DOM的易变性和长时间任务的崩溃恢复需求。下面按顺序给出一套可复用的实现。3.1 滚动加载的驱动方式：小步滚动加耐心等待微博时间线的加载方式是“滚动到接近底部时异步加载下一页”，一次滚到底不会把内容全部加载出来，反而可能因为请求过快触发校验。我习惯把滚动拆成小步：每次向下滚动800到1000像素，然后固定等待1到2秒，同时检查页面是否还在变高。连续3次高度不变就认为已经到底。这里有两个容易翻车的细节。一个是等待时间不能太短：加载是异步的，元素先插入DOM、图片和评论数后补齐，等待时间不足会采到缺少字段的中间态。另一个是退出条件：有些页面底部有“加载更多”按钮，滚动到底后还要判断按钮是否可点击；有的则直接无限流，判断依据只有页面高度。下面这段先覆盖“无限流”的常见情况。import time def scroll_feed(driver, max_steps=60): unchanged = 0 last_height = driver.execute_script("return document.body.scrollHeight") for step in range(max_steps): # 每次只滚一小段，给异步加载留时间 driver.execute_script("window.scrollBy(0, 900);") time.sleep(1.5) new_height = driver.execute_script("return document.body.scrollHeight") if new_height == last_height: unchanged += 1 if unchanged >= 3: break else: unchanged = 0 last_height = new_height return last_height这段代码里，max_steps=60是保险丝，防止页面异常时无限循环；900是单次滚动像素，可以按屏幕高度调整，2K屏可以调到1200；1.5秒是等待间隔，网络差时建议加到2秒；连续3次高度不变才退出，避免网络抖动导致误判。注意unchanged计数器在高度变化时要归零，否则容易提前退出。3.2 字段提取：选择器要集中配置，别赌死一个类名字段定位是整个工程里最脆的一环。微博前端类名经常带混淆前缀，还时不时调整。直接依赖class全名等于把鸡蛋放在一个篮子里。我一般优先用相对稳定的位置关系：先按文本或者固定属性找到微博容器，再在容器内部定位正文、时间和作者。容器级别的选择器会写成一个常量，集中放在配置区，方便失效时一次替换。from selenium.webdriver.common.by import By import hashlib # 选择器集中配置，页面改版时只改这里 ITEM_SELECTOR = (By.XPATH, "//section[contains(@class,'feed')]") TEXT_SELECTOR = (By.XPATH, ".//div[contains(@class,'content')]") TIME_SELECTOR = (By.XPATH, ".//time") def extract_weibo(item): data = {} try: data["text"] = item.find_element(*TEXT_SELECTOR).text.strip() except Exception: data["text"] = "" try: data["created_at"] = item.find_element(*TIME_SELECTOR).get_attribute("datetime") or "" except Exception: data["created_at"] = "" # 唯一标识优先取 mid，缺失时用正文前32字做备用键 data["mid"] = item.get_attribute("mid") or "" if not data["mid"]: data["mid"] = hashlib.md5(data["text"][:32].encode("utf-8")).hexdigest() return data这段代码核心是“容器内相对查找”：item是上一步拿到的单条微博根节点，TEXT_SELECTOR和TIME_SELECTOR都以.开头，限定只在这个节点内部找，避免采到旁边推荐位的内容。get_attribute("mid")比文本更适合作去重键，因为文本可能重复；万一微博容器没有mid属性，再用正文前32字的MD5兜底。这里的选择器是按微博常见DOM结构写的，真实使用前一定要打开开发者工具核对，类名以当天页面为准。字段来源处理要点text正文容器text属性首尾清洗，去掉多余换行created_attime元素datetime属性统一存ISO格式，便于排序mid容器mid属性去重主键，缺失时用正文哈希3.3 增量落盘与断点续采：JSONL写入加历史去重采集不是一次性任务，跑一半挂掉很正常。如果最后一次性写文件，一旦进程崩溃，前面几小时的数据全丢。我习惯用JSONL：每采完一条就追加写入一行，同时调用flush()把缓冲落到磁盘。下次启动时把历史文件里的mid读进一个set，新数据先判重再写，等于天然断点续采。import json import os def load_seen(fp): seen = set() if not os.path.exists(fp): return seen with open(fp, encoding="utf-8") as f: for line in f: try: obj = json.loads(line) if obj.get("mid"): seen.add(obj["mid"]) except json.JSONDecodeError: continue return seen def save_weibo(driver, out_fp, seen, max_steps=60): scroll_feed(driver, max_steps) with open(out_fp, "a", encoding="utf-8") as f: for item in driver.find_elements(*ITEM_SELECTOR): item_data = extract_weibo(item) # 正文为空说明这条没解析成功，直接跳过 if not item_data["text"]: continue if item_data["mid"] in seen: continue seen.add(item_data["mid"]) f.write(json.dumps(item_data, ensure_ascii=False) + "\n") f.flush()load_seen在启动时把历史文件里的mid全部读进内存，作为去重基线；save_weibo每写入一条就flush()一次，虽然牺牲了一点IO性能，但换来的是进程被kill后最多丢一条数据。注意flush()也可以改成每攒够10条调一次，数据量特别大时性能更好，代价是异常崩溃时最多丢一舍批次。还有一个隐藏坑：历史文件如果已经几十万行，启动扫描会很慢，这种情况建议按天拆分数据文件，只加载最近三天的去重基线。4. 微博Selenium采集的5个高频坑：从翻车现场到解决方案这章是血泪经验汇总。我在不同项目里用Selenium采微博，翻来覆去遇到的坑基本就这五类。每一条都按“现象、原因、解决”写清楚，你可以直接对照排查自己的WBCrawler。4.1 滚动太快导致数据漏采，页面高度却不长了现象：采集跑得很顺，速度也快，但最后核对数量时发现只采到了预期的一半。回看页面高度，滚动到某个位置后就不再增加，脚本误以为到底了，提前退出。原因：微博信息流是懒加载，滚动的速度超过异步请求的速度时，浏览器会跳过部分加载步骤；如果此时连续多次判断高度不变，脚本就认为加载结束。实际是页面还在等网络响应，高度暂时没变而已。解决：把滚动步长从1200改回800到900，等待时间加到1.5秒以上。同时不要只看高度，还要统计当前已解析的卡片数量，连续N轮卡片数不增加才算结束。监控里加上每小时采集条数，如果数量突然掉到正常值一半以下，基本就是提前退出了。4.2 登录静默失效，采回来一堆“请登录”现象：采集任务跑了一晚上，第二天打开数据文件，发现后半部分是重复的“登录”“开通微博”之类文本，mid全是同一个哈希值，去重完全失效。原因：登录态过期后，信息流区域被替换成登录引导页。因为页面仍然能滚动、DOM仍在，脚本以为一切正常，把引导文案当正文采了进来。有的登录失效页面还会反复输出相同内容，导致去重也失去作用。解决：在采集循环里加校验：如果每条正文为空或命中“登录”特征词，就认为是登录态失效信号，立刻停止写入并检测登录框元素。建议每采完50条做一次轻量检测，不要等任务全部跑完。无人值守时把“登录失效”当成最高优先级异常，直接触发截图和日志，第二天人工登录后断点续采。4.3 选择器今天还能用，明天全体失效现象：昨天跑得好好的工程，今天启动后items列表为空，或者extract_weibo拿到的text全是空字符串，打开浏览器一看页面结构变了。原因：前端发布新版本后类名或DOM层级调整，固定写死的class路径失效。微博页面迭代频繁，尤其活动期间会临时插入各种推荐模块，导致选择器匹配到错误节点。解决：选择器收敛到少数几个配置项，优先使用带业务语义的稳定属性或固定按钮文本，少依赖混淆过的类名。失效后先看浏览器控制台确认当前结构，把新选择器更新进配置再重启。有条件的话保留一份当天页面快照，回头对比DOM差异，能省很多排查时间。4.4 内存去重集合越滚越大，进程被杀现象：长时间采集后，seen集合里存了几十万个字符串，内存占用持续上升，最终进程被系统杀掉，之前的进度也丢了。原因：所有mid都放在Python的set里，字符串占用的内存比想象中大得多。一天几万条还没事，连续跑一周、几百万条之后内存就成了瓶颈。加上很多采集脚本为了省事不重启，一个进程跑好几天，内存自然撑不住。解决：去重集合不要一直驻留内存。可以每采完一批就把新mid追加到一个独立的去重文件，并定期清理内存set的前半段；或者只保留当天的mid在内存，跨天去重交给历史文件扫描。我更倾向于“单次任务跑完就退出，重启用历史文件恢复”，让每次进程生命周期控制在几个小时以内。4.5 被识别成自动化脚本，页面开始弹验证现象：开启自动化后，页面偶尔打不开内容区，或弹出一个验证组件，脚本卡在等待元素超时，然后整轮失败。原因：Selenium启动的浏览器默认带一些自动化标记，比如navigator.webdriver属性为true，被前端检测到后就会走验证流程。加长等待、重试可以缓解，但根源在这些标记上。解决：启动浏览器前通过DevTools协议注入一段脚本，把这些标记改掉；再加随机的滚动节奏和等待时间，避免每次都是固定间隔。注意这类反检测手段是持续的，不能指望一套参数永久有效。关键是要给脚本留出被验证时的人工接管入口：检测到验证组件超过一定时间未消失，就停表、截图、告警，而不是默默重试。5. 进阶：让WBCrawler自己跑过夜：异常重试、日志取证与多账号限速把单轮采集跑通只是开始。真正要投入使用的微博采集工程，至少要能自己跑过夜：中途遇到网络抖动能恢复，遇到登录失效能停下来等人，跑完还能留下足够排查的证据。这一章讲我常用的三个进阶手段。5.1 异常重试不中断：采集循环加护栏采集脚本最常见的死法不是逻辑错，而是网络抖动、元素短暂缺失、页面弹窗打断滚动。一个异常就让整个任务退出，跑过夜基本不可能。我给采集主循环加了一个包装函数：捕获常规异常，记录日志后sleep一段时间再继续；连续失败次数超过阈值才彻底退出。class TooManyFails(Exception): pass def crawl_with_retry(driver, out_fp, seen, max_retry=5): fails = 0 while fails < max_retry: try: save_weibo(driver, out_fp, seen, max_steps=60) fails = 0 time.sleep(2) except TooManyFails: raise except Exception as e: fails += 1 logger.error("crawl round failed: %s", e) if fails >= max_retry: raise TooManyFails("连续失败过多，停止任务") # 按失败次数递增等待，避免快速重试继续踩坑 time.sleep(5 * fails)这里的关键是异常粒度。元素缺失、超时这类可恢复异常，适合重试；登录失效这类异常不能重试，必须直接抛出让上层处理，否则重试多少次都是空采。time.sleep(5 * fails)是指数退避的简化版，第一次失败等5秒，第二次等10秒，给页面留出自我恢复的时间。5.2 日志分级加异常截屏：第二天起来先看证据跑过夜的脚本，第二天早上最怕的是只留下“任务结束”四个字，不知道中间发生了什么。我习惯把运行日志和错误日志分开，同时异常发生时截屏存证据。截图能把当时的页面状态记下来，事后定位是登录失效还是反爬弹窗，比看堆栈快得多。import logging from datetime import datetime logging.basicConfig( level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s", handlers=[ logging.FileHandler("crawler.log", encoding="utf-8"), logging.StreamHandler(), ], ) logger = logging.getLogger("wbcrawler") def snapshot_on_error(driver, tag=""): name = f"error_{datetime.now().strftime('%Y%m%d_%H%M%S')}_{tag}.png" driver.save_screenshot(name) logger.info("snapshot saved: %s", name)日志格式里第一项是UTC时间戳，跨天跑的时候能清楚看到任务在哪个阶段出了状况。FileHandler把日志持久化到本地，StreamHandler让终端也能看到实时输出。截图文件名带时间戳和tag，同一轮任务多次报错也不会互相覆盖。这个组合起来以后，早上只需要看日志尾部加几张截图，就能判断晚上发生了什么。5.3 多账号轮换与限速：稳定比速度重要单个账号长时间高频跑，触发验证的概率会明显上升。更稳的做法是准备两三个账号，用各自的user-data-dir，在一个采集周期里按顺序切换；每切换一次账号，停一段时间再继续。不要试图把速度拉满，微博数据采集的瓶颈在稳定性，不在单次速度。我一般会写一个简单的账号轮换器：一个列表放着多个user-data-dir路径，跑完一轮就切换到下一个目录重启driver；每个账号单轮采集控制在几百条左右，然后sleep随机60到120秒。至于定时启动，用操作系统自带的任务计划程序就能实现，没必要在程序里再做一套调度。跑过夜的关键是“慢且稳”，一条数据都不漏比一小时多采几百条更有价值。6. 收尾技巧：用最小字段校验脚本给结果验尸采集工程写完、数据落盘之后，不要急着交付。我习惯先拿一个小脚本给结果“验尸”：逐行解析JSONL，检查必填字段是否完整、文本是否为空、时间是否存在、mid是否重复。这一条检查能快速暴露登录失效、选择器失效、去重失效三类最典型的问题。import json def validate(fp): total = 0 bad = 0 required = {"mid", "text", "created_at"} with open(fp, encoding="utf-8") as f: for line in f: total += 1 try: obj = json.loads(line) if not required.issubset(obj): bad += 1 elif not obj["text"] or not obj["created_at"]: bad += 1 except json.JSONDecodeError: bad += 1 return total, bad if __name__ == "__main__": total, bad = validate("weibo_data.jsonl") print(f"total={total}, bad={bad}, bad_rate={bad / total:.2%}" if total else "empty file")这个脚本应该成为每次采集后的固定动作。如果bad_rate超过2%，基本可以判断采集过程中出了问题，要么登录态掉了，要么选择器失效了，不要拿这批数据直接跑分析。跑完之后，我还会人工抽3到5个博主的最近一条微博去和页面核对，数量和内容对上了才认为这轮任务有效。这个习惯救过我一次：某个版本采集时遇到置顶内容，置顶文案覆盖了正常正文，字段校验全过，人工抽样才发现。如果在WBCrawler这类工程上让我说一条最值得提前做的事，那一定是在第一天就把字段校验和抽样回放写好，而不是等到数据用了半天之后才发现是坏的。希望这个习惯对你也有用。本文还有配套的精品资源，点击获取
简介：面向需要快速采集微博历史数据的Python学习者与爬虫开发者，围绕“微博辟谣”账号，展示了一套基于selenium的完整采集工程。项目同时覆盖移动版与PC网页版两种渠道，在单页面内采用多线程抓取内容，并以多线程异步方式处理多个页面，对理解动态网页渲染、页面解析和并发调度有直接参考价值。压缩包共15个文件，包含10个py源码、3个xlsx结果文件、1个md说明文档及1个gitignore，整体仅41KB，轻量易部署。py文件按main、crawl_handle、批量/单行爬取等模块拆分，xlsx为不同采集场景下的输出样例，md记录使用指引，结构清晰，适合快速定位学习重点。已有1072人学习下载。资料提供的不仅是可直接运行的案例，还配合作者博客专题中的源码分析，能帮助赶时间的同学快速还原环境配置、驱动安装、多线程调度等关键环节，减少从零摸索的成本。1. 微博数据采集离不开Python和Selenium：一个能自己跑完的采集管线我在模拟项目X里接过一个需求：每天把30个指定博主的微博正文、发布时间、转发量存档。最开始用requests直接请求页面，拿到的是半空壳，大量内容要靠接口二次签名，维护成本极高。最后落地的方案就是基于Python+Selenium的采集工程，也就是标题里这类WBCrawler.zip——用真实浏览器渲染页面，直接读DOM，绕开逆向接口签名的过程。这类工程解决的问题很具体：微博页面大量内容由JavaScript动态渲染，普通HTTP请求拿不全；页面还有登录校验和反自动化检测，脚本跑久了容易静默失败。Selenium的定位就是控制浏览器打开页面，模拟人的滚动、等待、点击，再把正文、时间、评论数按选择器摘下来。如果要做长期、结构化、可复现的微博数据采集，这套思路值得投入。下文从选型、登录态、采集循环到踩坑，按一个真实工程的顺序展开，每段都可以直接抄进你自己的WBCrawler。2. 登录态是采集的第一道关：Cookie注入与user-data-dir复用的取舍采集微博数据，遇到的第一个问题往往不是解析，而是能不能一直带着登录态。网页版不登录能看一部分内容，但评论数、完整正文、转发明细这类字段基本都要登录后才稳定出现。更麻烦的是登录态会在采集途中过期，脚本一旦没有感知，后半段全部采成登录页的同一份空数据。我的习惯是先把登录方案定死，再写解析逻辑。常见做法是两种：一种是把登录后的Cookie导出，程序启动时再注入；另一种是让Selenium复用浏览器用户数据目录。我两种都试过，最后长期用的是后者。下面先说清为什么Selenium更适合微博采集，再给一套可以直接跑的登录代码。2.1 为什么选Selenium而不拿requests硬啃直接请求HTML能不能拿到微博内容？能拿到一部分。微博信息流是典型的动态渲染页面，首屏HTML只有骨架和少量初始化数据，真正的微博正文、发布时间、转发数是由JavaScript在浏览器里异步请求接口后渲染出来的。直接用requests请求页面，得到的是半空壳；要拿全数据，要么去逆向接口签名，要么让浏览器替我们执行这些脚本。接口逆向这条路不是不能走，但维护成本很现实：微博接口的请求里带时间戳、随机参数和签名校验字段，某些字段的生成逻辑黑匣子一样，页面改版或参数规则调整后，爬取代码就要跟着返工。Selenium的做法是把“执行JavaScript”这件事交给真实浏览器，脚本只负责打开页面、滚动、等待元素出现、读取DOM。换来的是稳定性，代价是速度和资源占用。方案数据完整性维护成本适合场景requests直接抓HTML低，拿不到动态渲染内容低但数据残只抓静态元数据requests逆向接口高，但依赖签名算法高，规则一变就返工有专业逆向能力的小团队Selenium渲染页面高，跟随真实页面中，选择器有维护成本长期稳定采集如果你的需求是一次性抓几百条数据，用requests硬啃没有问题；但像WBCrawler这种要每天跑、要断点续采、要换账号的工程，Selenium的稳健性会省掉很多半夜被叫醒的麻烦。2.2 用user-data-dir留住登录态：第一次手动登录，以后自动复用Selenium登录方案有两条常见路线。一条是Cookie注入：手工登录后把Cookie导出成字符串，启动时通过driver.add_cookie灌进去。优点是可以把Cookie放在配置里，多台机器共用；缺点是一旦Cookie过期，脚本不会自己重新登录，而且微博的Cookie里带有校验用的字段，简单拷贝有时候会被拒绝。另一条是复用浏览器用户数据目录，也就是user-data-dir，我更推荐这条。user-data-dir的原理很直接：Selenium启动浏览器时指定一个本地目录，浏览器的Cookie、LocalStorage、会话数据都写进这个目录。第一次启动时你手动登录一次，之后每次启动都复用这份数据，不需要再把Cookie字符串塞进代码。对长期采集来说，这个方案比Cookie注入更省心，也避免了Cookie硬编码在配置文件里的泄露风险。from selenium import webdriver from selenium.webdriver.chrome.options import Options opts = Options() # 第一次先手动登录，之后复用这个目录里的登录态 opts.add_argument("user-data-dir=./wd_profile") # 固定窗口尺寸，避免页面响应式布局导致元素位移 opts.add_argument("window-size=1440,900") # 去掉“正在受自动化软件控制”的提示条 opts.add_experimental_option("excludeSwitches", ["enable-automation"]) driver = webdriver.Chrome(options=opts) driver.get("https://weibo.com") # 按实际登录页地址替换这段代码里，user-data-dir=./wd_profile最关键：目录不存在时浏览器会新建，登录后所有状态都留在这个目录里；window-size=1440,900是让页面按固定视口渲染，避免不同分辨率下元素坐标漂移；excludeSwitches参数去掉自动化横幅，减少一部分前端检测的触发概率。第一次运行时，浏览器窗口会弹出来，你手动登录一次，再关掉程序，后续启动就自带登录态了。2.3 登录态失效怎么发现：不能等到采完才察觉登录态是会过期的，而且过期后页面常常不报错，只是把内容区悄悄换成登录引导或者空白状态。如果你的采集循环里没有“登录态探测”，脚本会继续滚动、继续解析、继续写入，最后给你产出一堆没用的数据。我一般会在启动后先做一次轻量探测，用“是否还能看到登录入口”作为判断依据。from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def ensure_login(driver): wait = WebDriverWait(driver, 10) try: # 已登录页面通常看不到醒目的“登录”按钮 login_btn = wait.until( EC.visibility_of_element_located((By.XPATH, "//*[contains(text(),'登录')]")) ) print("登录态已失效，请在弹出的浏览器中手动登录") input("登录完成后按回车继续...") except Exception: print("登录态有效，开始采集")这段探测代码用的是“反向判断”：如果能在10秒内等到一个包含“登录”文本的可见元素，就说明当前是未登录状态；如果等不到，默认登录态还在。注意它只适合有人值守的第一版。无人值守跑过夜时，我会把input()改成“检测到失效就停止写数据并保留截图”，具体做法放到后面避坑章节里展开。3. 核心采集逻辑：滚动加载、字段解析与增量落盘登录打通之后，真正决定采集质量的是三个环节：页面滚动怎么驱动、DOM字段怎么稳定提取、数据怎么落盘才能断点续采。这三个环节分别对应微博信息流的懒加载机制、前端DOM的易变性和长时间任务的崩溃恢复需求。下面按顺序给出一套可复用的实现。3.1 滚动加载的驱动方式：小步滚动加耐心等待微博时间线的加载方式是“滚动到接近底部时异步加载下一页”，一次滚到底不会把内容全部加载出来，反而可能因为请求过快触发校验。我习惯把滚动拆成小步：每次向下滚动800到1000像素，然后固定等待1到2秒，同时检查页面是否还在变高。连续3次高度不变就认为已经到底。这里有两个容易翻车的细节。一个是等待时间不能太短：加载是异步的，元素先插入DOM、图片和评论数后补齐，等待时间不足会采到缺少字段的中间态。另一个是退出条件：有些页面底部有“加载更多”按钮，滚动到底后还要判断按钮是否可点击；有的则直接无限流，判断依据只有页面高度。下面这段先覆盖“无限流”的常见情况。import time def scroll_feed(driver, max_steps=60): unchanged = 0 last_height = driver.execute_script("return document.body.scrollHeight") for step in range(max_steps): # 每次只滚一小段，给异步加载留时间 driver.execute_script("window.scrollBy(0, 900);") time.sleep(1.5) new_height = driver.execute_script("return document.body.scrollHeight") if new_height == last_height: unchanged += 1 if unchanged >= 3: break else: unchanged = 0 last_height = new_height return last_height这段代码里，max_steps=60是保险丝，防止页面异常时无限循环；900是单次滚动像素，可以按屏幕高度调整，2K屏可以调到1200；1.5秒是等待间隔，网络差时建议加到2秒；连续3次高度不变才退出，避免网络抖动导致误判。注意unchanged计数器在高度变化时要归零，否则容易提前退出。3.2 字段提取：选择器要集中配置，别赌死一个类名字段定位是整个工程里最脆的一环。微博前端类名经常带混淆前缀，还时不时调整。直接依赖class全名等于把鸡蛋放在一个篮子里。我一般优先用相对稳定的位置关系：先按文本或者固定属性找到微博容器，再在容器内部定位正文、时间和作者。容器级别的选择器会写成一个常量，集中放在配置区，方便失效时一次替换。from selenium.webdriver.common.by import By import hashlib # 选择器集中配置，页面改版时只改这里 ITEM_SELECTOR = (By.XPATH, "//section[contains(@class,'feed')]") TEXT_SELECTOR = (By.XPATH, ".//div[contains(@class,'content')]") TIME_SELECTOR = (By.XPATH, ".//time") def extract_weibo(item): data = {} try: data["text"] = item.find_element(*TEXT_SELECTOR).text.strip() except Exception: data["text"] = "" try: data["created_at"] = item.find_element(*TIME_SELECTOR).get_attribute("datetime") or "" except Exception: data["created_at"] = "" # 唯一标识优先取 mid，缺失时用正文前32字做备用键 data["mid"] = item.get_attribute("mid") or "" if not data["mid"]: data["mid"] = hashlib.md5(data["text"][:32].encode("utf-8")).hexdigest() return data这段代码核心是“容器内相对查找”：item是上一步拿到的单条微博根节点，TEXT_SELECTOR和TIME_SELECTOR都以.开头，限定只在这个节点内部找，避免采到旁边推荐位的内容。get_attribute("mid")比文本更适合作去重键，因为文本可能重复；万一微博容器没有mid属性，再用正文前32字的MD5兜底。这里的选择器是按微博常见DOM结构写的，真实使用前一定要打开开发者工具核对，类名以当天页面为准。字段来源处理要点text正文容器text属性首尾清洗，去掉多余换行created_attime元素datetime属性统一存ISO格式，便于排序mid容器mid属性去重主键，缺失时用正文哈希3.3 增量落盘与断点续采：JSONL写入加历史去重采集不是一次性任务，跑一半挂掉很正常。如果最后一次性写文件，一旦进程崩溃，前面几小时的数据全丢。我习惯用JSONL：每采完一条就追加写入一行，同时调用flush()把缓冲落到磁盘。下次启动时把历史文件里的mid读进一个set，新数据先判重再写，等于天然断点续采。import json import os def load_seen(fp): seen = set() if not os.path.exists(fp): return seen with open(fp, encoding="utf-8") as f: for line in f: try: obj = json.loads(line) if obj.get("mid"): seen.add(obj["mid"]) except json.JSONDecodeError: continue return seen def save_weibo(driver, out_fp, seen, max_steps=60): scroll_feed(driver, max_steps) with open(out_fp, "a", encoding="utf-8") as f: for item in driver.find_elements(*ITEM_SELECTOR): item_data = extract_weibo(item) # 正文为空说明这条没解析成功，直接跳过 if not item_data["text"]: continue if item_data["mid"] in seen: continue seen.add(item_data["mid"]) f.write(json.dumps(item_data, ensure_ascii=False) + "\n") f.flush()load_seen在启动时把历史文件里的mid全部读进内存，作为去重基线；save_weibo每写入一条就flush()一次，虽然牺牲了一点IO性能，但换来的是进程被kill后最多丢一条数据。注意flush()也可以改成每攒够10条调一次，数据量特别大时性能更好，代价是异常崩溃时最多丢一舍批次。还有一个隐藏坑：历史文件如果已经几十万行，启动扫描会很慢，这种情况建议按天拆分数据文件，只加载最近三天的去重基线。4. 微博Selenium采集的5个高频坑：从翻车现场到解决方案这章是血泪经验汇总。我在不同项目里用Selenium采微博，翻来覆去遇到的坑基本就这五类。每一条都按“现象、原因、解决”写清楚，你可以直接对照排查自己的WBCrawler。4.1 滚动太快导致数据漏采，页面高度却不长了现象：采集跑得很顺，速度也快，但最后核对数量时发现只采到了预期的一半。回看页面高度，滚动到某个位置后就不再增加，脚本误以为到底了，提前退出。原因：微博信息流是懒加载，滚动的速度超过异步请求的速度时，浏览器会跳过部分加载步骤；如果此时连续多次判断高度不变，脚本就认为加载结束。实际是页面还在等网络响应，高度暂时没变而已。解决：把滚动步长从1200改回800到900，等待时间加到1.5秒以上。同时不要只看高度，还要统计当前已解析的卡片数量，连续N轮卡片数不增加才算结束。监控里加上每小时采集条数，如果数量突然掉到正常值一半以下，基本就是提前退出了。4.2 登录静默失效，采回来一堆“请登录”现象：采集任务跑了一晚上，第二天打开数据文件，发现后半部分是重复的“登录”“开通微博”之类文本，mid全是同一个哈希值，去重完全失效。原因：登录态过期后，信息流区域被替换成登录引导页。因为页面仍然能滚动、DOM仍在，脚本以为一切正常，把引导文案当正文采了进来。有的登录失效页面还会反复输出相同内容，导致去重也失去作用。解决：在采集循环里加校验：如果每条正文为空或命中“登录”特征词，就认为是登录态失效信号，立刻停止写入并检测登录框元素。建议每采完50条做一次轻量检测，不要等任务全部跑完。无人值守时把“登录失效”当成最高优先级异常，直接触发截图和日志，第二天人工登录后断点续采。4.3 选择器今天还能用，明天全体失效现象：昨天跑得好好的工程，今天启动后items列表为空，或者extract_weibo拿到的text全是空字符串，打开浏览器一看页面结构变了。原因：前端发布新版本后类名或DOM层级调整，固定写死的class路径失效。微博页面迭代频繁，尤其活动期间会临时插入各种推荐模块，导致选择器匹配到错误节点。解决：选择器收敛到少数几个配置项，优先使用带业务语义的稳定属性或固定按钮文本，少依赖混淆过的类名。失效后先看浏览器控制台确认当前结构，把新选择器更新进配置再重启。有条件的话保留一份当天页面快照，回头对比DOM差异，能省很多排查时间。4.4 内存去重集合越滚越大，进程被杀现象：长时间采集后，seen集合里存了几十万个字符串，内存占用持续上升，最终进程被系统杀掉，之前的进度也丢了。原因：所有mid都放在Python的set里，字符串占用的内存比想象中大得多。一天几万条还没事，连续跑一周、几百万条之后内存就成了瓶颈。加上很多采集脚本为了省事不重启，一个进程跑好几天，内存自然撑不住。解决：去重集合不要一直驻留内存。可以每采完一批就把新mid追加到一个独立的去重文件，并定期清理内存set的前半段；或者只保留当天的mid在内存，跨天去重交给历史文件扫描。我更倾向于“单次任务跑完就退出，重启用历史文件恢复”，让每次进程生命周期控制在几个小时以内。4.5 被识别成自动化脚本，页面开始弹验证现象：开启自动化后，页面偶尔打不开内容区，或弹出一个验证组件，脚本卡在等待元素超时，然后整轮失败。原因：Selenium启动的浏览器默认带一些自动化标记，比如navigator.webdriver属性为true，被前端检测到后就会走验证流程。加长等待、重试可以缓解，但根源在这些标记上。解决：启动浏览器前通过DevTools协议注入一段脚本，把这些标记改掉；再加随机的滚动节奏和等待时间，避免每次都是固定间隔。注意这类反检测手段是持续的，不能指望一套参数永久有效。关键是要给脚本留出被验证时的人工接管入口：检测到验证组件超过一定时间未消失，就停表、截图、告警，而不是默默重试。5. 进阶：让WBCrawler自己跑过夜：异常重试、日志取证与多账号限速把单轮采集跑通只是开始。真正要投入使用的微博采集工程，至少要能自己跑过夜：中途遇到网络抖动能恢复，遇到登录失效能停下来等人，跑完还能留下足够排查的证据。这一章讲我常用的三个进阶手段。5.1 异常重试不中断：采集循环加护栏采集脚本最常见的死法不是逻辑错，而是网络抖动、元素短暂缺失、页面弹窗打断滚动。一个异常就让整个任务退出，跑过夜基本不可能。我给采集主循环加了一个包装函数：捕获常规异常，记录日志后sleep一段时间再继续；连续失败次数超过阈值才彻底退出。class TooManyFails(Exception): pass def crawl_with_retry(driver, out_fp, seen, max_retry=5): fails = 0 while fails < max_retry: try: save_weibo(driver, out_fp, seen, max_steps=60) fails = 0 time.sleep(2) except TooManyFails: raise except Exception as e: fails += 1 logger.error("crawl round failed: %s", e) if fails >= max_retry: raise TooManyFails("连续失败过多，停止任务") # 按失败次数递增等待，避免快速重试继续踩坑 time.sleep(5 * fails)这里的关键是异常粒度。元素缺失、超时这类可恢复异常，适合重试；登录失效这类异常不能重试，必须直接抛出让上层处理，否则重试多少次都是空采。time.sleep(5 * fails)是指数退避的简化版，第一次失败等5秒，第二次等10秒，给页面留出自我恢复的时间。5.2 日志分级加异常截屏：第二天起来先看证据跑过夜的脚本，第二天早上最怕的是只留下“任务结束”四个字，不知道中间发生了什么。我习惯把运行日志和错误日志分开，同时异常发生时截屏存证据。截图能把当时的页面状态记下来，事后定位是登录失效还是反爬弹窗，比看堆栈快得多。import logging from datetime import datetime logging.basicConfig( level=logging.INFO, format="%(asctime)s %(levelname)s %(message)s", handlers=[ logging.FileHandler("crawler.log", encoding="utf-8"), logging.StreamHandler(), ], ) logger = logging.getLogger("wbcrawler") def snapshot_on_error(driver, tag=""): name = f"error_{datetime.now().strftime('%Y%m%d_%H%M%S')}_{tag}.png" driver.save_screenshot(name) logger.info("snapshot saved: %s", name)日志格式里第一项是UTC时间戳，跨天跑的时候能清楚看到任务在哪个阶段出了状况。FileHandler把日志持久化到本地，StreamHandler让终端也能看到实时输出。截图文件名带时间戳和tag，同一轮任务多次报错也不会互相覆盖。这个组合起来以后，早上只需要看日志尾部加几张截图，就能判断晚上发生了什么。5.3 多账号轮换与限速：稳定比速度重要单个账号长时间高频跑，触发验证的概率会明显上升。更稳的做法是准备两三个账号，用各自的user-data-dir，在一个采集周期里按顺序切换；每切换一次账号，停一段时间再继续。不要试图把速度拉满，微博数据采集的瓶颈在稳定性，不在单次速度。我一般会写一个简单的账号轮换器：一个列表放着多个user-data-dir路径，跑完一轮就切换到下一个目录重启driver；每个账号单轮采集控制在几百条左右，然后sleep随机60到120秒。至于定时启动，用操作系统自带的任务计划程序就能实现，没必要在程序里再做一套调度。跑过夜的关键是“慢且稳”，一条数据都不漏比一小时多采几百条更有价值。6. 收尾技巧：用最小字段校验脚本给结果验尸采集工程写完、数据落盘之后，不要急着交付。我习惯先拿一个小脚本给结果“验尸”：逐行解析JSONL，检查必填字段是否完整、文本是否为空、时间是否存在、mid是否重复。这一条检查能快速暴露登录失效、选择器失效、去重失效三类最典型的问题。import json def validate(fp): total = 0 bad = 0 required = {"mid", "text", "created_at"} with open(fp, encoding="utf-8") as f: for line in f: total += 1 try: obj = json.loads(line) if not required.issubset(obj): bad += 1 elif not obj["text"] or not obj["created_at"]: bad += 1 except json.JSONDecodeError: bad += 1 return total, bad if __name__ == "__main__": total, bad = validate("weibo_data.jsonl") print(f"total={total}, bad={bad}, bad_rate={bad / total:.2%}" if total else "empty file")这个脚本应该成为每次采集后的固定动作。如果bad_rate超过2%，基本可以判断采集过程中出了问题，要么登录态掉了，要么选择器失效了，不要拿这批数据直接跑分析。跑完之后，我还会人工抽3到5个博主的最近一条微博去和页面核对，数量和内容对上了才认为这轮任务有效。这个习惯救过我一次：某个版本采集时遇到置顶内容，置顶文案覆盖了正常正文，字段校验全过，人工抽样才发现。如果在WBCrawler这类工程上让我说一条最值得提前做的事，那一定是在第一天就把字段校验和抽样回放写好，而不是等到数据用了半天之后才发现是坏的。希望这个习惯对你也有用。本文还有配套的精品资源，点击获取