DrissionPage浏览器抓包实战：告别前端加密，轻松搞定每日数据采集

写爬虫的人都知道，最痛苦的环节往往不是写代码，而是怎么把数据拿到手。日常用 requests 直接请求接口，动不动被签名、加密参数、风控逻辑卡住；换成 Selenium 控制浏览器，又得跟 webdriver 版本死磕，页面渲染慢的时候等得人发慌。今天分享的这个案例，是用 Python 爬虫圈里越来越常见的 DrissionPage 实现浏览器抓包操作——它把控制浏览器和获取网络请求这两件事合并到一套代码里，实测下来能省掉大量排查前端加密的功夫，特别适合做每日定时数据采集、页面自动化、接口逆向这类活。

这个案例适合谁？正在写 spider 的爬虫工程师、需要定期从网页上采集数据的运营或分析人员、以及想给自己自动化脚本加一层"浏览器级抓包"能力的朋友。只要你的电脑上有 Chrome 或 Edge，跟着下面的步骤走，基本能跑通一套完整的"浏览器启动 → 监听请求 → 触发翻页 → 提取接口数据 → 落地保存"的链路。先把结论放在前面：DrissionPage 不是替代 requests，而是帮你解决"浏览器里能看到的请求，代码里却拿不到"这个尴尬问题。

1. 案例背景与整体设计思路

1.1 为什么抓包成了每日爬虫任务里绕不开的环节

现在的网页应用，跟前几年完全不是一个量级。以前很多数据是直接渲染在 HTML 里的，requests 一把梭就行。现在前端框架普及之后，数据基本都走异步接口，页面上看到的内容是 JavaScript 动态渲染出来的，DOM 结构里是一堆空壳。更麻烦的是，很多站点会在接口层做签名校验、时间戳拼接、加密参数混淆，你光看 Network 面板能看明白请求长什么样，但用代码复刻出来几乎不可能。

这时候最稳妥的思路就变成了：既然浏览器能正常把请求发出去并拿到数据，那就让浏览器替我们发请求。这也就是"浏览器抓包"的核心思路。DrissionPage 做的正是这件事，它基于 Chrome DevTools Protocol（CDP）跟浏览器内核直接通信，既不需要额外安装 chromedriver，也不需要单独挂一个代理抓包工具，直接在代码层面就能把页面里每个请求和响应截获下来。

1.2 三种方案对比：requests、Selenium、DrissionPage

很多新手容易陷入一个误区：觉得能用 requests 解决就别上浏览器，效率高又不吃资源。这个判断在接口完全公开、无加密的场景下是对的，但一旦遇到前端加密、登录态校验、验证码验证，requests 方案的维护成本会直线上升。Selenium 能解决渲染问题，但它的定位是"模拟用户操作"，抓包能力很弱，想拿接口数据还得再配合 Fiddler、Charles 一类的工具，链路长、配置繁琐。

我整理了一张对比表，方便你根据自己的场景选型：

这个案例选择 DrissionPage，核心原因就是它把"自动化"和"抓包"合并到了一起。你不需要在浏览器和工具之间来回切换，也不用关心目标接口到底做了多少层加密——只要浏览器能正常访问，代码就能拿到完整请求和响应。

1.3 这个案例适合什么人、解决什么问题

如果你每天都要从几个固定网站上拉数据，比如行情报价、榜单排行、政策文件、商品价格，而且这些网站的数据都是动态加载的，那这个案例对你来说非常实用。我在实际项目中用这套方案处理过不少场景：自动登录后台导出报表、定时刷新监控页面抓取告警数据、从查询类站点批量获取信息。核心价值就一句话：用浏览器身份拿到最干净的数据，避免跟加密逻辑死磕。

2. 环境准备与 DrissionPage 快速上手

2.1 安装与版本选择

安装非常简单，一条命令搞定：

bash复制pip install DrissionPage

这里有一点要提醒：DrissionPage 的版本迭代比较快，4.x 版本之前和之后 API 差别比较大。早期 3.x 版本主要提供 session 和 mix 模式，4.x 之后引入了基于 CDP 的 ChromiumPage，抓包相关的 listen 监听器也是在这个阶段逐步完善的。建议优先安装最新版，代码写法以你自己安装版本的官方文档为准。我下面的示例基于 4.x 版本语法。

这个库的底层工作原理可以简单理解为：启动一个真实的 Chrome/Edge 浏览器实例，通过调试端口跟浏览器内核通信，所以你不需要额外安装任何浏览器驱动。只要本机有 Chrome、Edge 或者 Chromium 内核的浏览器就能跑。

2.2 三种常用的浏览器启动方式

第一种是直接接管系统默认浏览器。如果 Chrome 安装在默认路径，直接初始化即可：

python复制from DrissionPage import ChromiumPage

page = ChromiumPage()
page.get('https://www.baidu.com')
print(page.title)

第二种是手动指定浏览器路径。这个场景经常出现在浏览器装在非默认位置、或者你想用 Edge 的情况下：

python复制from DrissionPage import ChromiumOptions, ChromiumPage

co = ChromiumOptions()
co.set_browser_path(r'C:\Program Files\Microsoft\Edge\Application\msedge.exe')
page = ChromiumPage(addr_or_opts=co)
page.get('https://www.baidu.com')

第三种是复用用户数据目录。这对需要保持登录态的场景特别有意义。第一次启动时可以手动登录目标站点，之后每次启动都读取同一个 user-data-dir，登录态就一直在：

python复制co = ChromiumOptions()
co.set_user_data_path(r'D:\chrome_data\my_profile')
page = ChromiumPage(addr_or_opts=co)

需要注意，同一个用户数据目录不能同时被多个浏览器实例占用，否则会报错或者互相踢登录态。这也是后面我们聊多账号并发时要用多个独立目录的原因。

2.3 设置语言与用户数据目录

有一个很常见的需求是设置浏览器语言。比如你想让页面以中文环境加载，或者想模拟某个地区的用户，最直接的方式是加启动参数：

python复制co = ChromiumOptions()
co.set_argument('--lang', 'zh-CN')
page = ChromiumPage(addr_or_opts=co)

如果你实际跑过会发现，只改 --lang 有时候还不够，部分站点的语言判断还看 Accept-Language 请求头。这个头信息可以通过 hook 或者自定义 headers 的方式设置，DrissionPage 里可以用 page.set.headers() 相关方法调整。这里多说一句：设置语言不是爬虫的必备操作，但当你需要从多语言站点定向抓取某个语言版本的数据时，这个小功能能省很多事。

用户数据目录的设置同时决定了"身份"的持久性。每次启动浏览器，如果不指定用户目录，DrissionPage 会创建一个临时环境，关掉就没了。指定了目录，你的 Cookies、LocalStorage、登录状态都会保留。在每日任务场景里，建议固定一个目录来存储目标网站的登录态，能明显减少被验证码挡住的概率。

3. 核心实现：用监听器完成浏览器抓包

3.1 监听器的基本用法

DrissionPage 的抓包能力，核心是 listen 监听器。它的工作方式类似浏览器开发者工具里的 Network 面板，可以拦截页面发出的所有请求和响应。你不需要额外打开抓包软件，也不用配置代理，代码里直接就能拿到数据包。

基本流程是三步：

1. 调用 page.listen.start(targets) 开始监听，targets 参数用于过滤要监听的请求地址。
2. 执行页面操作，比如点击按钮、滚动页面、提交表单，这些操作会触发新的网络请求。
3. 通过 page.listen.steps() 或 page.listen.wait() 获取数据包，逐个处理。

targets 参数支持字符串和列表。比如你想只监听某个接口路径下的请求，可以这样写：

python复制page.listen.start('api/data*')

如果想同时监听多个接口：

python复制page.listen.start(['api/data*', 'api/list*'])

需要注意，监听器启动之后，只有新发起的请求才会被捕获，之前已经完成的请求是拿不到的。所以在写流程时，一定要先 start，再执行触发请求的操作。

3.2 一个完整的抓包示例

这里写一个完整的例子，模拟的场景是：打开一个动态加载数据的列表页，点击"下一页"按钮，抓取每次翻页时后台返回的 JSON 数据。

python复制from DrissionPage import ChromiumPage
import json
import time

# 初始化浏览器
page = ChromiumPage()
page.get('https://example.com/list')

# 开始监听目标接口
page.listen.start('api/list*')

# 先抓第一页数据
for packet in page.listen.steps():
    if packet.response.status == 200:
        data = packet.response.body
        print('第一页接口URL:', packet.request.url)
        print('第一页返回数据:', data)
    break

# 触发翻页操作，连续抓取后续数据
for i in range(2, 6):
    page.ele('css:.next-page-btn').click()  # 点击下一页按钮
    time.sleep(1)
    for packet in page.listen.steps():
        if packet.response.status == 200:
            result = packet.response.body
            print(f'第{i}页数据:', result)
        break

# 停止监听
page.listen.stop()
page.quit()

这里有几个关键点要展开讲。packet 对象里最常用的是 packet.request 和 packet.response，分别对应请求信息和响应信息。请求信息里有 url、method、post_data、headers 等属性，响应信息里有 status、body、headers 等属性。packet.response.body 拿到的就是接口返回的完整数据，大多数情况下是 JSON 字符串，可以直接解析。

在实际项目中，我不会把翻页操作写成循环里 sleep，而是用 page.listen.wait() 等待下一个数据包到达。这样不管接口响应快慢，都能精确拿到每一次翻页的返回，不会因为固定 sleep 太久浪费时间，也不会因为 sleep 太短漏掉数据。

3.3 数据包结果的处理与落地

数据包拿到手之后，处理逻辑就看你的业务需求了。最常见的做法是解析 JSON 提取字段，然后保存到本地文件或者数据库。比如上面的例子，可以改造成这样：

python复制all_records = []

for packet in page.listen.steps():
    if packet.response.status == 200:
        try:
            json_data = json.loads(packet.response.body)
        except json.JSONDecodeError:
            continue

        records = json_data.get('data', [])
        for item in records:
            all_records.append({
                'title': item.get('title'),
                'url': item.get('url'),
                'publish_time': item.get('publish_time'),
            })

# 保存到本地JSON文件
with open('daily_data.json', 'w', encoding='utf-8') as f:
    json.dump(all_records, f, ensure_ascii=False, indent=2)

处理过程中有几个容易踩的坑。第一，response.body 在响应体比较大的时候可能会被截断，如果你发现拿到的数据不完整，优先确认是不是接口本身返回就很大，然后考虑只监听必要的接口，或者调整监听过滤条件。第二，有些接口返回的是二进制数据，比如图片、文件流，这时候 json.loads 会直接报错，提前用 try 包一层，或者判断 Content-Type 再决定怎么解析。第三，翻页过程中如果同时有其他异步请求也在命中过滤规则，packet.response.body 可能不是你想要的那一条，建议在过滤条件里把 URL 写得更精确，防止混入干扰数据。

4. 实战场景：把抓包做成可每日运行的任务

4.1 场景一：动态列表页的滚动加载采集

很多网站的数据不是靠点击翻页，而是滚动到底部自动加载更多。这种场景用 DrissionPage 监听同样顺手。滚动操作的实现方式有不少，最直接的是用 page.scroll.to_bottom()，滚动之后页面会触发新的 XHR 请求，监听器就能捕获到。

下面这段代码演示了滚动加载场景下的抓包采集：

python复制from DrissionPage import ChromiumPage
import json
import time

page = ChromiumPage()
page.get('https://example.com/feed')

page.listen.start('api/feed*')

articles = []
for _ in range(10):  # 最多滚动10次
    page.scroll.to_bottom()
    time.sleep(1)
    for packet in page.listen.steps():
        if packet.response.status == 200:
            try:
                items = json.loads(packet.response.body)
                articles.extend(items.get('list', []))
            except json.JSONDecodeError:
                pass

page.listen.stop()

print(f'共采集 {len(articles)} 条数据')

实际跑这个逻辑的时候，我建议设定一个结束条件，比如检查返回的数据条数不再增加，或者检测到某个"没有更多了"的标记，而不是硬编码滚动次数。否则遇到已经滚到底部的页面，还会白白浪费时间。另外，滚动速度要控制好，触发加载之后稍微等一下，别一口气滚到底，有些网站的接口支撑不了那么频繁的请求。

4.2 场景二：登录态复用与扫码登录

每日任务最常见的需求是登录后抓数据。DrissionPage 处理登录态的思路很简单：第一次启动浏览器时，手动完成登录，登录信息会写入用户数据目录；之后每次启动都指定同一个用户目录，登录态直接继承。

第一次登录时，可以这样启动：

python复制co = ChromiumOptions()
co.set_user_data_path(r'D:\chrome_data\my_profile')
page = ChromiumPage(addr_or_opts=co)

page.get('https://example.com/login')
input('请在弹出的浏览器中完成登录，登录完成后按回车继续...')

# 登录完成后，访问需要登录态的页面
page.get('https://example.com/dashboard')
page.listen.start('api/dashboard*')
for packet in page.listen.steps():
    print(packet.response.body)
    break

这里的关键是 input() 暂停。脚本启动浏览器后，你自己手动扫码或者输入账号密码，登录成功后再让脚本继续跑。第二次运行的时候，只要 user_data_path 不变，直接访问需要登录态的页面就能正常拿到数据，不需要再走一遍登录流程。

这个方案的适用范围很广，比如企业后台的报表数据、需要登录才能查看的订单列表、个人中心的账单明细，都可以这样处理。有一点要提醒：如果目标网站检测到异地登录或者设备异常，登录态可能会失效，届时需要重新跑一次手动登录流程。为了避免每天被这个事打扰，我习惯在采集脚本里加一个登录态检测，发现跳转到了登录页就自动暂停并提示重新登录。

4.3 场景三：多账号并发与参数传递

有些任务需要同时处理多个账号的数据，比如公众号采集、店铺信息查询。这种情况下，开多个浏览器实例并行跑是个常见方案。但多实例不能共用一个用户数据目录，必须每个实例配独立的目录。更稳妥的做法是把每个账号的任务拆成一个独立的 py 脚本，由主脚本统一调度。

这里就要说到 Python 里很实用的一个小技能：一个 py 脚本给另一个 py 脚本传递参数，用 subprocess 配合 sys.argv 就能解决。主脚本负责分配账号和参数：

python复制import subprocess

accounts = [
    {'username': 'user1', 'user_data_dir': r'D:\chrome_data\account1'},
    {'username': 'user2', 'user_data_dir': r'D:\chrome_data\account2'},
    {'username': 'user3', 'user_data_dir': r'D:\chrome_data\account3'},
]

for acc in accounts:
    subprocess.Popen([
        'python', 'worker.py',
        '--username', acc['username'],
        '--user_data_dir', acc['user_data_dir'],
    ])

子脚本 worker.py 里可以通过 sys.argv 接收参数：

python复制import sys
from DrissionPage import ChromiumOptions, ChromiumPage

username = sys.argv[sys.argv.index('--username') + 1]
user_data_dir = sys.argv[sys.argv.index('--user_data_dir') + 1]

co = ChromiumOptions()
co.set_user_data_path(user_data_dir)
page = ChromiumPage(addr_or_opts=co)

# 执行具体采集任务

如果你觉得命令行传参太长不好管理，也可以把账号信息写成 config.ini，子脚本里读取配置文件。这里顺便提一句，config.ini 文件的路径别写死，建议用 os.path 动态获取当前脚本所在目录，这样脚本也好、打成 exe 也好，都不会因为路径问题读不到配置。

多实例并行要注意资源消耗。每个 Chrome 实例大概会占几百兆内存，开五六个实例就得注意机器配置能不能扛住。如果目标网站对并发敏感，建议用队列或者信号量限制同时运行的实例数量，尽量别一次性把所有账号全放出去。

5. 常见问题排查与避坑指南

5.1 高频问题速查表

我在用 DrissionPage 做抓包的过程中，遇到过下面这些比较典型的坑，整理成表格方便对照：

5.2 稳定性与反爬规避的细节

浏览器自动化脚本跑久了，最怕的就是被目标网站识别并限制。DrissionPage 理论上是一个正常的浏览器，但自动化操作的特征还是能被一些风控系统识别出来。我在实际项目里会注意几个细节。

第一，自定义 User-Agent。虽然 DrissionPage 默认会用真实浏览器指纹，但如果你觉得不妥，也可以手动设置一个常见的 UA：

python复制page.set.user_agent('Mozilla/5.0 ... Chrome/120.0.0.0')

第二，控制操作频率。每日采集任务讲究的是稳定，不是速度快。翻页之间加上合理的间隔，单次任务请求量控制在一个安全的范围内，比任何伪装技巧都管用。很多站点不是故意针对爬虫，而是接口扛不住高频请求，你频率一高，风控系统就自动封你 IP。

第三，窗口模式和无头模式的取舍。无头模式对服务器友好，也方便放在云服务器上跑，但暴露风险更高，因为无头浏览器的特征很容易被检测。如果你只是在自己电脑上跑每日任务，用普通窗口模式更稳妥。DrissionPage 支持 co.headless() 切换无头模式，建议结合具体站点的风控严格程度来选择。

5.3 合规与频率控制提醒

这个案例的技术本身是中性的，但用的时候要有边界。我的习惯是：只抓取公开可访问的数据，或者我有权限访问的数据；绝不绕过登录限制、不碰用户隐私、不采集未授权的个人敏感信息。目标网站的 robots 协议和用户协议建议先看一眼，别给自己惹麻烦。

每日任务的频率也要控制。单站点建议设置最小访问间隔，批量任务尽量分散到不同时间段执行，避免对目标服务器造成压力。我在本地跑定时任务时，一般用 schedule 或者系统自带的计划任务，把脚本设置在业务低峰期运行。采集数据入库之后，用完后及时清理，不长期囤积不必要的数据。

踩过几次坑之后，我现在写这类脚本都会在开头加一个简单的延迟控制函数，确保每个请求之间有固定的时间间隔。这个小习惯在我连续跑了几个月采集任务后，几乎没有再遇到过被限制的情况。

这个方向可以玩的还有很多，比如把采集到的数据直接写入 MySQL、SQLite，或者对接企业微信、钉钉机器人做定时推送。DrissionPage 的监听能力，本质上是给了你把浏览器变成"自动化数据管道"的入口，怎么用好它，就看你的具体场景了。我在实践中最深的一点体会是：稳定比功能多重要，能长期跑的任务才是有价值的任务。