1. 项目缘起与整体设计思路1.1 为什么盯上了雪球网的股票情绪数据做量化或者做投资研究的朋友都知道股价短期波动很大程度上受市场情绪驱动。雪球网作为国内活跃的投资者社区每天产生大量关于个股的讨论帖、评论和转发这些文本里藏着非常真实的散户与机构情绪。如果能把这些数据稳定地采集下来做情感分析、热度排名、异动预警价值是相当直接的。但问题在于雪球网的数据并不是静态躺在HTML里的。它的帖子列表、评论、热度指标大量依赖前端异步渲染很多内容要等JavaScript执行完才出现在DOM里。早期我用传统的requests BeautifulSoup去抓拿到的往往是一个空壳页面关键数据一个都取不到。后来换成Selenium能跑通但速度慢、资源占用高跑几百个页面机器就开始发烫而且稳定性堪忧动不动就超时。最终我把方案锁定在Playwright上。它原生支持现代浏览器内核能真实执行页面JS等待机制比Selenium更聪明还自带请求监听能力可以顺手把接口返回的JSON数据截下来。这套组合下来采集效率和稳定性都上了一个台阶。这篇文章就把我完整的实战过程拆开讲包括框架选型、页面结构分析、采集脚本编写、反爬应对、数据清洗入库以及我踩过的那些坑。1.2 整体架构从采集到落库的完整链路在动手写代码之前我习惯先把整条链路画清楚不然写到一半容易返工。这个项目的整体设计分成四层采集层Playwright驱动浏览器负责打开雪球个股页面、滚动加载、等待渲染、抓取DOM文本同时监听网络请求截获接口数据。解析层对抓到的原始内容做结构化处理提取股票代码、帖子标题、正文、发布时间、点赞数、评论数、作者等字段。清洗层去重、去广告、去表情符号、统一时间格式、过滤无效短文本。存储层先落本地CSV或SQLite做缓冲再批量写入MySQL或直接喂给后续的情感分析模块。这样分层的好处是每一层职责单一出问题好定位。比如某天发现数据变少了我可以先看采集层日志确认是页面没加载出来还是解析规则失效还是清洗时被误过滤了。1.3 为什么是Playwright而不是Scrapy或纯接口逆向这里得说清楚选型逻辑因为很多人第一反应是直接逆向接口不香吗。纯接口逆向确实快找到雪球的API构造请求参数直接拿JSON。但雪球的接口通常带签名参数和时效性token这些参数由前端JS动态生成逆向成本高而且一旦对方调整算法你的脚本立刻报废维护成本极高。Scrapy本身是优秀的爬虫框架但它对动态渲染的支持要靠scrapy-playwright中间件配置链路长调试起来不够直观。而且Scrapy的异步模型和Playwright的浏览器上下文管理结合时容易出现上下文泄漏。Playwright的优势在于所见即所得。浏览器里能看到什么你就能抓到什么。它的wait_for_selector、wait_for_load_state等API让等待逻辑非常自然。更重要的是Playwright可以监听response事件把页面加载过程中所有XHR/fetch请求的响应体拿到手。这意味着我可以DOM抓一份 接口截一份双保险哪条路通走哪条。提示如果你的目标站点接口签名极其复杂优先考虑Playwright的请求监听方案而不是硬啃JS逆向。监听拿到的响应体往往就是干净的JSON省去大量解析工作。2. 环境搭建与核心工具选型细节2.1 Python环境与Playwright安装我用的Python版本是3.10这个版本对异步支持和类型提示都比较友好。虚拟环境用venv就行没必要上conda轻量。安装Playwright分两步很多人只做了第一步就报错pip install playwright playwright install chromium第一行装的是Python库第二行才是下载浏览器内核。如果你只装库不装内核运行时会提示找不到浏览器可执行文件。我一般只装chromium因为项目不需要Firefox和WebKit省磁盘空间。如果你在国内网络环境下下载内核慢可以设置镜像环境变量后再执行playwright install速度会明显改善。2.2 依赖清单与版本锁定这个项目除了Playwright还需要几个辅助库库名用途备注playwright浏览器自动化核心版本锁定1.40pandas数据清洗与落盘处理表格数据极方便jieba中文分词后续情感分析预处理sqlalchemy数据库ORM批量入库loguru日志记录比logging好用太多我强烈建议用requirements.txt锁版本。Playwright的API在不同大版本间偶有变动比如早期wait_for_timeout的用法和现在就有差异。锁版本能避免昨天还能跑今天更新完就崩的尴尬。2.3 浏览器启动参数的关键配置启动浏览器时参数配置直接决定采集的稳定性和隐蔽性。我常用的配置是这样的from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch( headlessTrue, args[ --disable-blink-featuresAutomationControlled, --no-sandbox, --disable-dev-shm-usage, ] ) context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, viewport{width: 1920, height: 1080}, localezh-CN, )这里几个点值得展开说。--disable-blink-featuresAutomationControlled是为了抹掉navigator.webdriver这个自动化特征很多站点的风控会检测它。--disable-dev-shm-usage在容器环境里能避免共享内存不足导致的崩溃。user_agent和viewport要设置得像真实用户默认的Playwright UA一眼就能被识别。注意headless模式虽然快但部分站点的风控对无头浏览器更敏感。如果发现采集频繁被拦可以临时切到headlessFalse观察确认是渲染问题还是风控问题。2.4 请求监听把接口数据顺手截下来这是Playwright相比Selenium最让我惊喜的能力。通过监听response事件我可以在页面加载过程中捕获所有网络响应captured [] def handle_response(response): if /status/list in response.url or /comment/list in response.url: try: captured.append(response.json()) except Exception: pass page.on(response, handle_response) page.goto(target_url, wait_untilnetworkidle)networkidle表示等网络请求基本停止后再继续这样能确保异步接口都返回了。捕获到的JSON往往比DOM解析更干净字段完整、没有HTML标签污染。我实测下来雪球的帖子列表接口返回的数据结构非常规整直接就能映射成表格。3. 雪球页面结构分析与采集策略3.1 目标页面拆解个股讨论区我以某只个股的讨论区页面为例。页面主要包含几块内容顶部是股票基本信息和实时行情中间是帖子流每条帖子有作者、发布时间、正文摘要、点赞数、评论数底部是加载更多按钮或无限滚动触发点。关键难点在于帖子流是懒加载的初始只渲染十几条必须滚动到底部才会触发下一批。而且部分帖子的正文是折叠的需要点击展开全文才能拿到完整内容。我的策略是先滚动加载到目标数量再统一解析。滚动时用page.mouse.wheel模拟真实滚轮比直接改scrollTop更不容易被识别。3.2 选择器定位稳比快重要选择器我踩过最大的坑就是用了带随机hash的class名。雪球的前端框架会给元素生成类似_3xK9a这样的动态类名今天能用明天改版就废。我的原则是优先用语义化的属性、文本内容、层级关系定位。比如帖子容器可以用>posts page.query_selector_all(div[class*timeline__item]) for post in posts: title_el post.query_selector(h3) content_el post.query_selector(div[class*content]) author_el post.query_selector(a[href*/u/])用class*做模糊匹配比精确匹配抗改版能力强很多。3.3 滚动加载的节奏控制无限滚动的节奏很关键。滚太快页面还没加载完就滚走了数据丢失滚太慢效率低下。我的做法是每滚一屏等待一个固定的短时间再检查帖子数量是否增加last_count 0 while True: page.mouse.wheel(0, 2000) page.wait_for_timeout(1500) current_count len(page.query_selector_all(div[class*timeline__item])) if current_count last_count: break last_count current_count if current_count 200: breakwait_for_timeout虽然被一些人诟病为硬等待但在滚动场景下它比wait_for_selector更实用因为新内容出现的位置不固定。1500毫秒是我实测下来比较稳的值太快容易漏太慢浪费时间。4. 完整采集脚本实现与关键环节4.1 主流程骨架整个采集脚本的主流程我拆成几个函数每个函数只干一件事def collect_stock_posts(stock_code, max_posts200): with sync_playwright() as p: browser p.chromium.launch(headlessTrue, args[...]) context browser.new_context(...) page context.new_page() captured [] page.on(response, lambda r: handle_response(r, captured)) url fhttps://xueqiu.com/S/{stock_code} page.goto(url, wait_untilnetworkidle) scroll_to_load(page, max_posts) dom_data parse_dom(page) api_data parse_api(captured) merged merge_data(dom_data, api_data) browser.close() return mergedDOM和接口两路数据合并时我用帖子ID或发布时间作者作为联合主键去重。实测下来两路数据重合度大概七成合并后能补全不少字段。4.2 数据解析与字段映射解析出来的原始数据需要映射成统一结构。我定义的字段包括stock_code、post_id、title、content、author、publish_time、like_count、comment_count、source标记来自DOM还是API。时间字段特别要注意雪球显示的是3分钟前2小时前这种相对时间需要转换成绝对时间戳。我写了个转换函数def parse_relative_time(text): now datetime.now() if 分钟前 in text: m int(re.search(r(\d), text).group(1)) return now - timedelta(minutesm) if 小时前 in text: h int(re.search(r(\d), text).group(1)) return now - timedelta(hoursh) if 天前 in text: d int(re.search(r(\d), text).group(1)) return now - timedelta(daysd) return now这个函数看着简单但如果不处理后续做时间序列分析时全是字符串根本没法用。4.3 数据清洗与落库清洗环节我做了几件事去掉正文里的HTML标签、过滤纯表情和纯符号的帖子、去除重复内容、把点赞数1.2万这种格式转成数字12000。def clean_content(text): text re.sub(r[^], , text) text re.sub(r\s, , text).strip() if len(text) 5: return None return text落库我用SQLAlchemy批量插入每500条提交一次。单条插入在数据量大时性能极差批量提交能把入库时间压缩到十分之一。5. 反爬应对与稳定性优化5.1 请求频率与行为模拟雪球对高频访问是有风控的。我的策略是单只股票采集完成后随机休眠3到8秒再采下一只。同一会话内不要连续快速翻页滚动节奏也要有随机性。import random time.sleep(random.uniform(3, 8))随机休眠比固定休眠更自然。固定间隔的请求模式很容易被识别为机器行为。5.2 会话与Cookie管理Playwright的context天然隔离Cookie。我一般一个context采一只股票采完就关避免Cookie累积触发风控。如果需要登录态可以手动登录一次后保存storage_state后续复用context.storage_state(pathstate.json) # 下次 context browser.new_context(storage_statestate.json)这样既保留了登录态又不用每次重新登录。5.3 异常重试与断点续采网络抖动、页面超时是常态。我给每个采集任务包了重试逻辑最多重试3次每次重试前换一个contextfor attempt in range(3): try: data collect_stock_posts(code) break except Exception as e: logger.warning(f第{attempt1}次失败: {e}) time.sleep(5)同时记录已采集的股票代码到本地文件重启脚本时跳过已完成的实现断点续采。这个细节在采几百只股票时能省大量时间。6. 常见问题与排查技巧实录6.1 页面加载了但抓不到数据这是最常见的问题。原因通常是等待时机不对。networkidle有时会因为页面有长轮询请求而一直不触发。我的解决办法是改用domcontentloaded加显式等待关键元素page.goto(url, wait_untildomcontentloaded) page.wait_for_selector(div[class*timeline__item], timeout15000)6.2 采集到一半被拦截如果发现前几十条正常后面突然返回空或跳验证页基本是触发风控了。排查顺序先看是不是频率太高降低速度再看UA和指纹是否暴露检查navigator.webdriver最后考虑是否需要登录态。6.3 常见问题速查表问题现象可能原因解决方向抓到空壳页面JS未执行完改用显式等待元素数据重复滚动触发多次加载用post_id去重时间字段混乱相对时间未转换统一转绝对时间戳脚本跑久崩溃内存泄漏定期重启context接口监听不到URL匹配规则错打印所有response.url排查提示调试接口监听时先把所有response的URL打印出来找到真正的数据接口再写匹配规则别凭猜测写。7. 数据应用与后续扩展方向采下来的数据我主要用在两个地方。一是做个股情绪热度排名统计每只股票在单位时间内的讨论量变化讨论量突增往往对应着消息面异动。二是做文本情感分析用jieba分词后接一个情感分类模型把帖子分成正面、中性、负面再算情绪指数。后续还可以扩展的方向不少。比如把采集频率提高到分钟级做实时情绪监控比如把多只股票的数据聚合做板块级别的情绪对比再比如结合行情数据验证情绪指标和股价的相关性。这些都属于数据采完之后的下游应用前提是采集这一环足够稳。我个人在实际操作中的体会是Playwright这套方案最大的价值不在于能抓到而在于抓得稳、好维护。选择器基于语义、接口监听做兜底、异常重试加断点续采这几点做到位一个采集脚本能稳定跑几个月不用大改。真正费时间的从来不是写第一版而是后续的维护所以前期在稳定性上的投入绝对值得。