DrissionPage 的 SessionPage 与 WebPage 详解

set_headers(headers)

设置默认请求头，后续请求会沿用这组头信息。

session_page.set_headers({'User-Agent': 'my-custom-agent'})

download(url, path)

下载文件时会很省事。

session_page.download('https://example.com/image.png', 'path/to/save/image.png')

4. 元素定位和数据提取

虽然它走的是请求路线，但 SessionPage 依然保留了比较顺手的选择器接口。对抓取任务来说，这点非常友好，不需要你在'请求结果'和'页面元素'之间切得太碎。

text = session_page('h1.title').text
link = session_page('a.link').attr('href')
all_links = session_page('a').all_attrs('href')

如果页面结构比较规整，这种写法会比手动解析 HTML 更省心。

5. Cookie 和会话管理

SessionPage 之所以适合登录态抓取，关键就在于它能稳定维护会话。你可以直接查看、设置、获取或清理 Cookie。

print(session_page.cookies)

session_page.set_cookies({'name': 'value'})
cookie_value = session_page.get_cookie('name')

session_page.clear_cookies()

这类接口在多页连续抓取时很有价值，尤其是需要跨页面保持身份信息的场景。

6. 优点与局限

SessionPage 的优势很直接：

• 速度快，不用加载浏览器
• 资源占用低，适合批量抓取
• 很适合静态页面和接口类数据

但它也有边界：

• 无法直接处理依赖 JavaScript 渲染的内容
• 不支持复杂的浏览器交互，比如点击、拖拽、输入这类动作

换句话说，它擅长'拿数据'，不擅长'演用户'。

7. 和 DriverPage 搭配使用

如果你遇到的页面一部分需要浏览器登录或交互，另一部分只是普通数据页，那么把 DriverPage 和 SessionPage 组合起来用，往往会比单独依赖浏览器更高效。

一个常见思路是：先用 DriverPage 完成登录，再把登录后的 Cookie 传给 SessionPage，后续抓取尽量交给后者。

from drission import Drission
from drission.page import SessionPage, DriverPage

drission = Drission()
driver_page = drission.driver_page
session_page = drission.session_page

driver_page.get('https://example.com/login')
driver_page('input[name="username"]').input('myusername')
driver_page('input[name="password"]').input('mypassword')
driver_page('button[type="submit"]').click()

session_page.set_cookies(driver_page.get_cookies())
session_page.get('https://example.com/data')
print(session_page.html)

这种拆分方式很实用：登录和交互交给浏览器，批量访问交给请求，会轻很多。

8. 小结

如果你要的是'快、稳、轻'，SessionPage 往往是第一选择。它特别适合静态页面、接口数据、登录态保持后的批量抓取；而一旦页面开始强依赖前端脚本，就要考虑和 DriverPage 配合，或者直接切到浏览器模式。

二、WebPage

WebPage 可以理解为 DrissionPage 里更统一的一层封装。它把 DriverPage 和 SessionPage 的能力揉在一起，提供了一个尽量一致的操作接口。对开发者来说，这意味着你不需要频繁切换思维：很多页面操作、元素提取、会话管理都能沿着同一套方法来做。

1. 核心功能

WebPage 的价值主要在三点：

• 接口统一：无论底层是浏览器还是请求，操作风格尽量一致
• 提取方便：支持 CSS 选择器、XPath 等常见方式
• 场景覆盖广：静态页面、动态页面、登录后页面都能处理

它本质上不是单独再造一套能力，而是把前面两种页面模型整合得更顺手。

2. 基本使用

使用时先创建 Drission 实例，再生成 WebPage。底层到底走浏览器还是请求，取决于你的初始化配置和使用方式。

from drission import Drission
from drission.page import WebPage

drission = Drission()
page = WebPage(drission)

page.get('https://example.com')

print(page.title)
print(page.html)

3. 常用方法

WebPage 的常用接口和网页操作习惯基本一致，学起来不会太费劲。

get(url, **kwargs)

加载指定 URL。

page.get('https://example.com')

title

获取页面标题。

print(page.title)

html

返回页面 HTML 源码。若处于浏览器模式，拿到的是渲染后的结果；若处于请求模式，则是响应内容。

print(page.html)

text

获取页面纯文本。

print(page.text)

元素选择和提取

WebPage 的元素定位也很顺手，拿文本、属性、批量元素都很自然。

text = page('h1.title').text
link = page('a.link').attr('href')
all_links = page('a').all_attrs('href')

操作元素

在浏览器模式下，WebPage 还能直接做点击、输入、提交表单这些动作。

page('button.submit').click()
page('input#name').input('drission')
page('form#login').submit()

滚动和等待

动态页面里，经常要等元素渲染完成或者滚动触发懒加载，这类操作也能直接处理。

page.scroll_to('bottom')
page.wait('div.content')

4. 优点与局限

WebPage 的优势在于通用性很强，很多时候你不需要太纠结当前页面到底是静态还是动态，只要用统一的方式去写代码就行。

它的局限也很清楚：

• 某些交互能力只在浏览器模式下可用
• 对特别复杂的前端页面，往往还是需要额外的定制处理

所以它更像是一个'高层入口'，方便你把不同场景收拢到一套代码风格里。

5. 和 Element 配合使用

WebPage 返回的很多对象本身就是 Element，这使得继续向下找子元素、提属性、点按钮都很自然。

element = page('a.link')
href = element.attr('href')
element.click()
sub_element = element('span')

这类链式写法在页面结构清晰时特别顺手，读起来也更接近人对页面的理解方式。

6. 适用场景

WebPage 比较适合下面这些场景：

• 需要浏览器交互的动态网页
• 希望用统一接口处理静态和动态页面
• 登录后需要持续访问多个页面的数据采集任务

如果说 SessionPage 是'高效取数'，那 WebPage 更像是'把取数和交互放到同一个工作台上'。

7. 小结

WebPage 的定位很清晰：它不是单纯替代某一个页面类，而是把 DriverPage 和 SessionPage 的能力整合起来，让你在不同网页类型之间切换时少一些心理负担。对想要写出结构更统一、维护更轻松的爬虫代码的人来说，这个封装很实用。

三、总结

DrissionPage 的价值，在于它没有把'浏览器自动化'和'请求式抓取'割裂成两套完全不同的写法。SessionPage 适合快速、轻量地抓取静态数据；WebPage 则提供了更统一的入口，方便同时处理静态页面、动态页面和登录态场景。

如果你的目标是高效采集数据，又不想在 Selenium 和 Requests 之间频繁切换思路，DrissionPage 确实是一个很顺手的选择。实际项目里，最常见也最稳妥的做法，往往就是：能用 SessionPage 就尽量用它，遇到交互和动态渲染再交给 WebPage 或浏览器模式处理。