用Playwright打造新闻热搜自动采集爬虫：从环境搭建到定时运行

我平时有收集新闻热搜做数据分析的习惯，早先靠手一个个复制粘贴，点一次页面就得停下整理一次，后来实在受不了这个重复劳动，就写了这个基于 Playwright 的自动化爬虫脚本。如果你也在做内容监测、竞品动态跟踪，或者单纯想攒一份属于自己的历史热搜数据集，这篇文章可以帮你把整个链路理顺：从环境搭建、页面解析，到数据落盘、定时运行，都有完整代码可以直接抄。

写这个脚本之前我也犹豫过用什么方案。一开始想用 requests 直接请求页面，结果返回的 HTML 里根本找不到热搜列表——因为现在的热搜榜普遍是 JavaScript 动态渲染的，直接请求等于拿到一张没有内容的空壳。后来转向 Playwright，问题一下解决了：它能真实打开浏览器、执行页面脚本、等待目标内容出现在 DOM 里，然后再把数据抓出来。下面我把从选型到上线的完整过程展开讲。

1. 为什么选 Playwright 做热搜抓取

1.1 requests 方案痛在哪里

如果你只是抓一个服务端渲染的静态网页，requests 当然又轻又方便。但今天的新闻热搜页基本都是前端异步渲染，热搜数据是页面加载完成后，脚本再向接口请求并渲染到 DOM 上的。我第一次用 requests 去拿某个资讯站点的热搜页，返回的 HTML 里只有一个骨架和一堆 JavaScript 文件引用，真正的榜单内容一个都看不到。

有朋友可能会说，那我顺着页面脚本去挖那个异步数据接口不就行了？这个思路理论上成立，但实践下来维护成本很高。接口地址、请求参数、返回结构随时可能调整，前端一改版，你的抓取逻辑就全线作废。我遇到过某平台连续几天更新接口逻辑，那几天排查成本比重新写爬虫还高。

浏览器自动化工具就没有这个问题。Playwright 模拟的是真实用户打开浏览器、等待页面渲染完成的完整过程，页面上能看到什么，脚本就能读到什么，完全不依赖后端接口的内部结构。从长期维护角度看，只要页面展示结构不调整，爬虫就能一直稳定运行，这是 requests 方案给不了的。

1.2 Playwright 的三个硬核优势

第一，天然支持 JavaScript 渲染。前面说过，浏览器自动化工具会完整执行页面脚本，等数据真正渲染出来再抓取，这就把动态页面抓取的第一大难题直接消掉了。

第二，自动等待机制做得很聪明。很多初学者写的时候习惯 time.sleep(3) 硬等几秒，但网络一波动，等够了还是不行。Playwright 的 wait_for_selector 会以极短间隔轮询 DOM，让 CSS 选择器能定位到目标元素后立刻往下执行。网络快就快跑，网络慢就多等一会，效率和稳定性都好很多。

第三，调试体验完整。Playwright 自带代码录制器、页面截图、trace 文件记录等功能。脚本跑挂的时候，直接打开 trace 就能回放当时的页面状态、Console 输出和网络请求，定位问题比 Selenium 那套额外配置省心太多了。

1.3 同类工具横评

决定用 Playwright 之前，我也简单横向比较过 Selenium 和 Puppeteer，这里给你一个参考。

Selenium 是老牌工具，生态大，但说实话配置 WebDriver 这件事在团队里经常轮番踩坑。Puppeteer 和 Playwright 同代，能力接近，只是语言生态上 Python 使用者更愿意用 Playwright。我自己在 Python 技术栈，所以选了 Playwright。

2. 环境准备与工程骨架

2.1 安装 Python 依赖

搭建环境其实就两条命令。我假设你已经装好了 Python 3.8 以上版本，建议顺手建一个虚拟环境，避免和系统里的其他包打架。

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install playwright playwright install chromium

playwright install 这个步骤很容易被忽略，但它是必须的。它会下载对应的浏览器二进制文件，如果漏掉这一步直接运行代码，会在启动浏览器时直接报错。

如果是部署在 Linux 服务器上，还可能需要操作系统的依赖库。保险起见可以直接跑下面的命令，它会自动安装缺失的系统动态库。

playwright install --with-deps chromium

如果网络不好，pip 可以换国内镜像源，浏览器二进制文件的下载也有镜像配置方式。不过这些都属于环境调试的细节，等遇到具体报错再按提示处理也行。

2.2 工程目录怎么摆

代码量不大，但目录结构一定要从一开始理清楚，后面跑历史增量、看日志、找截图都会方便很多。我常用的结构是这样：

hot_search_crawler/ ├── crawler.py # 爬虫主逻辑 ├── config.py # URL、UA、选择器等全局配置 ├── requirements.txt # 依赖清单 ├── data/ │ ├── hot_search.json # 最近一次抓取结果 │ ├── hot_search_history.csv # 历史数据累计 │ └── last_page.png # 每次抓取后的页面截图 └── logs/ └── run.log # 运行日志

把配置单独放到 config.py 里是个好习惯。热搜页的 DOM 结构会变，选择器和 URL 要改时，只动一个文件就行，不用在主脚本里到处翻。

2.3 关键启动参数的含义

先看一段最基础的浏览器启动代码：

with sync_playwright() as p: browser = p.chromium.launch( headless=True, args=["--disable-blink-features=AutomationControlled", "--no-sandbox"] )

headless=True 表示无头模式，即浏览器不弹出图形界面，适合服务器和定时任务。如果你在调试阶段，可以临时改成 headless=False，亲眼看看页面到底渲染成了什么样，排查定位问题特别有效。

--disable-blink-features=AutomationControlled 是个使用率极高的参数，主要用来关闭 Chromium 的自动化控制标记，从源头减少页面脚本检测到“这是机器人”的概率。--no-sandbox 是在 root 用户或部分容器环境里必须加的，不加的话浏览器可能直接崩溃。

3. 核心 API 与开发细节

3.1 配置浏览器实例的讲究

一个容易被忽略但很关键的思路是：让 Playwright 打开的浏览器尽量像一个真实用户在用。热搜站点不需要登录态，但 UA、视口大小、时区这些指纹信息会暴露自动化操作。我在配置里会这么写：

context = browser.new_context( user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36", viewport={"width": 1440, "height": 900}, locale="zh-CN", timezone_id="Asia/Shanghai" )

locale 和 timezone_id 主要是让页面按照中国的习惯返回语言格式和时区信息，同时让指纹更像本地用户。viewport 设为 1440x900 是大多数普通用户的屏幕尺寸，能避免某些页面在窄视口下触发移动端布局，影响选择器稳定性。

还有一个细节：现代模板渲染引擎经常使用无头浏览器的 UA 做差异处理，默认的 HeadlessChrome UA 会暴露自动化特征，所以显式设置一个正常 Chrome UA 非常有必要。

3.2 页面跳转与等待策略

跳转页面时，wait_until 的取值决定了页面要到什么状态才继续执行。我一般推荐 domcontentloaded 而不是 networkidle，原因很实在：很多新闻页有持续的数据埋点、轮询刷新、广告请求，网络永远不会完全“空闲”，如果你死等 networkidle，脚本超时是家常便饭。

page.goto(HOT_URL, wait_until="domcontentloaded", timeout=30000) page.wait_for_selector("div.hot-list li.hot-item", timeout=15000)

wait_for_selector 是 Playwright 里我使用频率最高的 API。它会在循环中反复检查页面里是否出现了指定的 CSS 选择器，出现了立刻往下走，超时则抛出异常。比起 time.sleep 硬等 5 秒再看，效率能提升好几倍，而且不会因为某次网络慢导致漏抓。

处理动态加载榜单时还有一个小技巧：页面首屏往往只渲染前十几条数据，更多热搜需要滚动页面才会继续加载。遇到这种情况可以在等待首屏内容后模拟几次滚轮操作：

for _ in range(3): page.mouse.wheel(0, 1200) page.wait_for_timeout(300)

滚动之后，等待新元素出现，再批量读取。这个操作能让脚本拿到更完整的数据，尤其是页面做了懒加载的情况下，效果非常明显。

3.3 热搜元素的定位与解析

定位策略直接影响脚本的稳定性。我的建议是尽量避开那种动态生成的 class 类名，因为前端每次构建都可能变化。优先用稳定的语义属性、data 属性或者结构层级。比如这样：

items = page.locator("div.hot-list li.hot-item") count = items.count() for i in range(count): item = items.nth(i) rank = item.locator(".rank").inner_text() title = item.locator(".title").inner_text() heat = item.locator(".heat").inner_text()

.locator() 返回的是一个元素句柄，调用 .count() 可以获得匹配数量，再用 .nth(i) 逐个拿元素，这样的写法比一次性 all_text_contents() 更灵活，因为每个热搜条目还要分别提取序号、标题和热度三个字段。

解析时常见的坑是元素隐藏或不可见。Playwright 默认会检查元素的可操作性，有些隐藏节点通过 inner_text 拿出来的可能是空字符串。真遇到这种情况，可以配合 is_visible() 做过滤，只保留真实展示出来的条目。

3.4 数据清洗与落盘

从页面上拿到的原始文本通常带有大量空白字符和广告角标，直接存 MySQL 或 CSV 都显得很脏。我常用的清洗手段是先把字符串做规范化处理，把换行和多余空格全部去掉，再用正则把序号、标题、热度值分开。

热度数值也常出现“万”“亿”这类中文单位，入库前建议统一转成纯数字，便于后续的排序和统计。处理方式可以简单封装一个函数：以“万”结尾就乘以一万，以“亿”结尾就乘以一亿。这个细节在做历史趋势分析时会省下很多力气。

数据存成什么格式，看你的下游需求。预览最近一次抓取结果用 JSON 就行，结构清楚，随手能打开看；需要积累历史数据做趋势曲线，CSV 追加写入是最省事的选择。两者不冲突，我现在的脚本就是同时维护两份。

4. 完整实战代码与运行流程

4.1 核心脚本逐行解析

下面是一份可以直接复用的核心脚本（注意：示例中的 URL 和 DOM 结构是通用占位，实际部署时替换成你目标站点的真实值即可）。代码整体分四个模块：配置、清洗、抓取、保存。

import csv import json import os import random import re import time from datetime import datetime from playwright.sync_api import sync_playwright # ====================== 配置区 ====================== HOT_URL = "https://sample-news-site.example/hot-list" UA_LIST = [ "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36", ] JSON_PATH = "data/hot_search.json" CSV_PATH = "data/hot_search_history.csv" # ====================== 清洗函数 ====================== def clean_text(raw: str) -> str: """去掉多余空白字符，以及标题左侧可能残留的排名数字""" text = re.sub(r"\s+", "", raw) text = re.sub(r"^\d+", "", text) return text.strip() def parse_heat(raw: str) -> int: """把带万/亿的中文热度值统一转成可排序的整数""" text = re.sub(r"\s+", "", raw).replace("热度", "") if text.endswith("亿") and text[:-1].replace(".", "").isdigit(): return int(float(text[:-1]) * 100000000) if text.endswith("万") and text[:-1].replace(".", "").isdigit(): return int(float(text[:-1]) * 10000) return int(text) if text.isdigit() else 0 # ====================== 核心抓取 ====================== def crawl_once(): with sync_playwright() as p: browser = p.chromium.launch( headless=True, args=["--disable-blink-features=AutomationControlled", "--no-sandbox"] ) context = browser.new_context( user_agent=random.choice(UA_LIST), viewport={"width": 1440, "height": 900}, locale="zh-CN", timezone_id="Asia/Shanghai", ) page = context.new_page() # 访问热搜页，等待核心列表出现 page.goto(HOT_URL, wait_until="domcontentloaded", timeout=30000) page.wait_for_selector("div.hot-list li.hot-item", timeout=15000) # 页面懒加载时模拟滚动，让更多数据渲染出来 for _ in range(3): page.mouse.wheel(0, 1200) page.wait_for_timeout(300) # 逐个解析条目 items = page.locator("div.hot-list li.hot-item") count = items.count() results = [] for i in range(count): item = items.nth(i) rank = item.locator(".rank").inner_text() title = item.locator(".title").inner_text() heat = item.locator(".heat").inner_text() results.append({ "rank": int(clean_text(rank)), "title": clean_text(title), "heat": parse_heat(heat), "crawled_at": datetime.now().strftime("%Y-%m-%d %H:%M:%S"), }) # 按排名顺序整理 results.sort(key=lambda x: x["rank"]) # 保存 JSON 快照 os.makedirs("data", exist_ok=True) with open(JSON_PATH, "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) # 截图留档，方便人工核对 page.screenshot(path="data/last_page.png") browser.close() print(f"[OK] 本次抓到 {len(results)} 条数据") return results # ====================== CSV 增量存储 ====================== def load_existing_keys(path: str) -> set: """读取历史 CSV，返回 (日期, 标题) 的集合用于去重""" if not os.path.exists(path): return set() with open(path, newline="", encoding="utf-8-sig") as f: reader = csv.DictReader(f) return {(row["crawled_at"][:10], row["title"]) for row in reader} def append_to_csv(results: list, path: str = CSV_PATH) -> int: """增量写入 CSV，避免重复数据堆积""" existing = load_existing_keys(path) fieldnames = ["rank", "title", "heat", "crawled_at"] new_rows = [] for row in results: key = (row["crawled_at"][:10], row["title"]) if key not in existing: new_rows.append(row) if not new_rows: return 0 is_new_file = not os.path.exists(path) or os.path.getsize(path) == 0 with open(path, "a", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=fieldnames) if is_new_file: writer.writeheader() writer.writerows(new_rows) return len(new_rows) if __name__ == "__main__": data = crawl_once() added = append_to_csv(data) print(f"[CSV] 新增 {added} 条历史记录")

这份代码我实际跑过的路径是：启动无头浏览器、加载动态列表、滚动触发懒加载、解析条目、存 JSON、增量存 CSV，全程没有问题。第一次运行建议先打开可视化模式，确保选择器真实匹配你的目标页面，再切到 headless 模式跑定时任务。

4.2 CSV 增量去重与历史留存

append_to_csv 函数解决了一个实际问题：CSV 文件越攒越多，重复抓取数据会导致历史记录迅速膨胀，最后的统计图全是噪声。

去重逻辑其实很简单，用“日期 + 标题”拼接成一个唯一键，把历史 CSV 里的所有键加载到内存，然后筛选新抓结果里不存在的记录追加写入。一天之内同一个标题再次出现在榜单上时，不会重复入库；第二天又出现，又能按新日期正常记录下来。这样既保留了历史变化，又不会让数据冗余失控。

编码上选择 utf-8-sig 是刻意的。直接用 utf-8 写 CSV，再用 Excel 打开很容易中文乱码，utf-8-sig 带 BOM，Excel 识别编码更稳定。如果你下游是 Pandas 做分析，utf-8-sig 也没问题，read_csv 默认能处理。

4.3 定时运行任务

爬虫写好之后，手动执行显然不合适，热搜榜白天变化快，但也不需要分钟级跟踪，保持耐心反而是更稳妥的策略。我采用了简单的定时策略：每隔 4 小时跑一次，每次自动抓取并写入 CSV。

最简单的定时方式是在主脚本里加一个循环：

import schedule import time schedule.every(4).hours.do(run_task) while True: schedule.run_pending() time.sleep(60)

schedule 是轻量级调度库，如果说你不想引入这个依赖，直接用 time.sleep(14400) 包一个 while 循环也能达到效果。不过 schedule 的优势在于可以同时注册多个任务，以后如果想扩展别的采集逻辑，扩展起来方便很多。

服务器上长期跑定时任务还有一个建议：输出日志统一重定向到 logs/run.log，这样哪天数据断了，可以先看日志确认是网络问题、选择器问题还是调度问题，排查效率会高很多。

5. 常见问题与排查技巧实录

5.1 定位不到热搜元素

这是 Playwright 爬虫里出现频率最高的问题，每次报错基本都是 TimeoutError 或者找不到元素。排查时我一般按顺序检查：

• 等待时间是否够长：把 wait_for_selector 的 timeout 调大，比如 15000 毫秒，别用默认值。热搜榜数据量大时，渲染时间可能超过 5 秒。
• 选择器是否写对：很多前端框架会生成动态 class 名，比如 .hot-item-a1b2c3，下次构建就变了。优先选稳定属性，比如>