1. 项目缘起与整体设计思路雪球网作为国内活跃的投资交流社区每天产生海量的用户发帖、评论和讨论。这些文本里藏着大量关于个股的情绪信号——看多、看空、犹豫、恐慌、狂热如果能把这些情绪数据系统性地采集下来对量化研究、舆情监控、投资辅助决策都有实际价值。但问题在于雪球的内容是典型的动态渲染页面传统的requests加BeautifulSoup那一套直接抓 HTML 的做法基本拿不到有效数据页面骨架加载完之后真正的帖子列表、评论内容都是靠 JavaScript 异步填充的。我最初也试过用Selenium来做毕竟老牌工具资料多。但实际跑下来速度慢、资源占用高、稳定性也一般尤其是需要长时间批量采集的时候浏览器实例动不动就崩。后来换到Playwright情况明显好转。Playwright 是微软开源的浏览器自动化框架支持 Chromium、Firefox、WebKit 三大内核API 设计比 Selenium 更现代自带等待机制、网络请求监听、多标签页管理最关键的是它对动态内容的处理非常顺手。这个项目的核心目标很明确给定一批股票代码自动打开雪球网对应的个股讨论页滚动加载帖子列表逐条提取发帖时间、用户名、正文内容、互动数据点赞、评论、转发然后对正文做情绪打分最终输出结构化的 CSV 或存入数据库。整套流程要能稳定跑批不能跑十分钟就挂。为什么选 Playwright 而不是继续用 Selenium除了上面说的速度和稳定性还有一个很实际的原因Playwright 的page.wait_for_selector和page.wait_for_load_state在处理雪球这种“滚动加载 异步请求”的页面时控制粒度更细。你可以精确等待某个元素出现也可以等网络请求空闲下来再操作不用像 Selenium 那样到处写time.sleep。另外 Playwright 默认以无头模式运行资源消耗比带界面的 Selenium 低不少适合放在服务器上长期跑。整个项目的架构我分成四层采集层负责用 Playwright 打开页面、滚动加载、提取原始数据解析层负责把原始 HTML 或文本清洗成结构化字段情绪分析层负责对文本做情绪打分存储层负责落盘和去重。四层之间通过队列或中间文件解耦方便单独调试和替换。注意雪球网有反爬机制包括请求频率限制、部分接口的签名校验等。本文的重点是技术实现思路实际采集时务必控制频率、遵守目标网站的 robots 协议和相关法律法规仅用于个人学习研究不要用于商业用途或大规模抓取。2. 环境搭建与核心工具选型2.1 Playwright 安装与浏览器驱动配置Playwright 的安装本身不复杂但有几个坑我踩过这里直接说清楚。首先 Python 版本建议 3.9 以上太低会有些 API 不支持。安装命令就一行pip install playwright装完之后还没完需要下载浏览器驱动playwright install chromium这里有个常见问题国内网络环境下下载 Chromium 驱动可能会很慢甚至超时。我的做法是设置镜像源或者手动下载后放到指定目录。Playwright 的浏览器默认存在~/.cache/ms-playwright目录下Linux/MacWindows 则在%USERPROFILE%\AppData\Local\ms-playwright。如果你在公司内网或者网络受限环境可以先用playwright install --dry-run看一下它会下载什么然后手动处理。另一个坑是如果你同时装了多个 Python 环境playwright install可能会装到错误的解释器下面。建议用虚拟环境先python -m venv venv激活后再装这样驱动路径和包路径一致不会出现“明明装了却找不到浏览器”的情况。除了 Playwright 本身我还装了pandas做数据处理jieba做中文分词snownlp做基础情绪打分。如果你想要更准的情绪分析可以换成transformers加载中文预训练模型但那个对机器性能要求高一些初期用snownlp足够跑通流程。2.2 为什么不用 Scrapy 加 Playwright 的组合网上有不少教程讲scrapy-playwright的集成方案我也试过。那个方案适合大规模分布式采集但对我这个项目来说有点重。Scrapy 的调度器、中间件、管道那一套配置起来繁琐而且和 Playwright 的集成需要额外装scrapy-playwright包版本兼容性时不时出问题。更关键的是雪球网的页面结构不算特别复杂不需要 Scrapy 那种级别的并发调度直接用 Playwright 的异步 API 配合asyncio就能达到不错的效率。我的做法是用async_playwright开多个页面上下文每个上下文负责一只股票并发数控制在 3 到 5 个太高容易被封。这样既利用了异步的并发优势又不会因为请求太密集触发风控。2.3 依赖清单与版本锁定实际跑下来我用的依赖版本如下建议锁定避免自动升级后 API 变动包名版本用途playwright1.40浏览器自动化核心pandas2.0数据清洗与导出jieba0.42中文分词snownlp0.12基础情绪打分asyncio内置异步并发控制csv内置数据落盘提示Playwright 的版本更新比较快新版本可能会调整某些 API 的默认行为。如果你发现代码跑不通先检查是不是版本差异导致的必要时回退到稳定版本。3. 雪球网页面结构与数据定位3.1 个股讨论页的 DOM 结构分析打开雪球网某只股票的讨论页比如https://xueqiu.com/S/SH600519对应的讨论区你会看到帖子列表是无限滚动的。每一条帖子在 DOM 里通常是一个article或div容器里面包含用户头像、昵称、发帖时间、正文、点赞数、评论数等。但这里有个关键点雪球的 class 名是动态生成的今天叫timeline__item明天可能就变了。所以不能硬编码 class 选择器得用更稳定的属性比如>import asyncio from playwright.async_api import async_playwright async def scrape_stock(browser, stock_code, max_posts200): context await browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) ..., viewport{width: 1280, height: 800} ) page await context.new_page() url fhttps://xueqiu.com/S/{stock_code} await page.goto(url, wait_untildomcontentloaded) # 后续滚动和提取逻辑 ... await context.close() async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessTrue) tasks [scrape_stock(browser, code) for code in stock_list] await asyncio.gather(*tasks) await browser.close() asyncio.run(main())这里headlessTrue是无头模式跑在服务器上不显示界面。调试阶段可以设成False方便看页面实际长什么样。4.2 帖子列表的滚动与提取滚动加载的核心逻辑是一个while循环每次滚动后等待新内容出现然后提取当前可见的所有帖子。为了避免重复提取我用一个集合记录已经处理过的帖子 ID可以从 DOM 的>def parse_relative_time(text): if 分钟前 in text: minutes int(re.search(r(\d), text).group(1)) return datetime.now() - timedelta(minutesminutes) elif 小时前 in text: hours int(re.search(r(\d), text).group(1)) return datetime.now() - timedelta(hourshours) # 其他情况省略4.3 情绪打分与数据落盘拿到正文后用snownlp做情绪打分返回一个 0 到 1 之间的分数越接近 1 表示越正面越接近 0 表示越负面。我一般把 0.6 以上算看多0.4 以下算看空中间算中性。这个阈值可以根据实际数据分布调整不是固定的。打分完之后把股票代码、帖子 ID、用户名、时间、正文、情绪分数、点赞数等字段写进一个列表最后用pandas导出 CSV。为了避免重复我在写入前会检查帖子 ID 是否已经存在。df pd.DataFrame(all_posts) df.drop_duplicates(subset[post_id], inplaceTrue) df.to_csv(fxueqiu_{stock_code}.csv, indexFalse, encodingutf-8-sig)utf-8-sig是为了 Excel 打开不乱码这个细节很多人会忽略。5. 常见问题与排查技巧实录5.1 页面加载超时或元素找不到最常见的问题是page.goto超时或者wait_for_selector等不到元素。原因通常是网络慢或者页面结构变了。我的处理方式是设置合理的超时时间默认 30 秒如果超时就重试一次。重试时换一个用户代理有时候能绕过临时的风控。另一个技巧是用wait_for_load_state(networkidle)等网络请求空闲下来但雪球页面可能有长轮询或者心跳请求导致永远不空闲。所以这个要慎用我一般用domcontentloaded加自定义等待条件。5.2 被风控拦截的应对策略雪球的风控主要表现为返回验证码页面、限制访问频率、封禁 IP。我的应对策略是第一控制并发数不要超过 5 个上下文同时跑第二每次请求之间加随机延迟1 到 3 秒不等第三如果发现页面标题变成“验证”之类的关键词立即停止当前任务等一段时间再试。还有一个办法是使用 Playwright 的storage_state保存登录后的 cookie下次直接加载避免重复登录。但雪球的登录本身也有风控所以这个方案适合已经有账号且能正常登录的情况。5.3 数据去重与增量采集长时间跑批会产生大量重复数据我的做法是在数据库层面做唯一索引或者在 CSV 写入前用pandas的drop_duplicates去重。增量采集的话记录上次采集到的最新帖子时间下次只采集比这个时间新的帖子。问题类型表现排查思路解决方案超时goto 报 TimeoutError检查网络、目标站是否可达增加超时时间、重试元素找不到wait_for_selector 超时检查选择器是否失效更新选择器、用更稳定的属性风控页面出现验证码检查请求频率降低并发、加延迟、换 UA数据重复CSV 里有重复帖子检查去重逻辑用 post_id 去重乱码CSV 打开中文乱码检查编码用 utf-8-sig提示如果连续多次被风控建议停几个小时再跑不要硬刚。风控策略是动态调整的硬刚只会让情况更糟。5.4 情绪打分的准确性优化snownlp是通用情感模型对股票领域的特定表达可能不准。比如“割肉”在通用语境下是负面但在股票语境下也是负面这个没问题但“抄底”有时候是正面觉得机会来了有时候是负面觉得还要跌模型可能分不清。我的做法是维护一个股票领域的自定义词典对特定词汇做加权或修正。如果要求更高可以微调一个 BERT 模型但那个成本就上去了。6. 实操心得与后续扩展方向跑这个采集器有一段时间了最大的体会是稳定性比速度重要。一开始我追求高并发结果频繁被风控反而效率更低。后来把并发降到 3加了随机延迟反而能连续跑几个小时不出问题。另外日志一定要打全每次请求的 URL、状态码、耗时都记下来出问题的时候方便回溯。后续如果想扩展有几个方向一是把数据存到数据库比如 SQLite 或 PostgreSQL方便做时间序列分析二是接入可视化用matplotlib或pyecharts画情绪走势图三是把情绪打分换成更准的模型比如用transformers加载中文金融领域的预训练模型。但这些都是后话先把采集跑通、跑稳再考虑上层应用。最后分享一个小技巧Playwright 的page.pause()在调试时非常有用它会让浏览器暂停你可以手动检查页面状态。虽然无头模式下用不了但调试阶段开有头模式配合pause()能省很多排查时间。