DrissionPage 专题：定位、用法详解与工具对比

DrissionPage 专题定位、用法详解与工具对比大家好我是小马不起床。这是爬虫系列的进阶专题。在前两篇中我们梳理了 requests 体系与 Selenium / Playwright 的选型逻辑。但在实际项目里很多读者反馈同样的问题Selenium 驱动管理麻烦、Playwright 部署笨重、requests 拿不到动态数据。本文介绍一个在国内爬虫圈使用率上升很快的工具——DrissionPage重点讲清它的定位、详细用法以及它与现有工具的真实差距。目录DrissionPage 是什么核心设计一个库两种形态安装与最小可用示例与 requests / Selenium / Playwright 的横向对比DrissionPage 的优点DrissionPage 的缺点与限制用法详解一浏览器配置 ChromiumOptions用法详解二接管已有浏览器与反检测用法详解三元素定位语法用法详解四元素操作用法详解五等待机制用法详解六标签页管理用法详解七滚动、截图与页面信息用法详解八网络监听 listen——真正的杀手锏用法详解九fetch 在浏览器内发请求用法详解十SessionPage 纯 HTTP 模式用法详解十一WebPage 双模式协同实战案例滚动加载页面 接口直采常见问题 FAQ选型结论1. DrissionPage 是什么DrissionPage 是一个国产的 Python Web 自动化与采集库GitHub 作者 g1879名字来自Driven Ssion浏览器驱动Page页面的组合概念官方将其定义为基于 py 的网页自动化程序。它与 Selenium 最大的区别在于技术路线Selenium代码 - WebDriver 协议 - 浏览器驱动(chromedriver) - 浏览器 DrissionPage代码 - CDP(Chrome DevTools Protocol) - 浏览器也就是说DrissionPage不需要任何浏览器驱动二进制文件。它直接通过 Chrome DevTools 协议控制浏览器——这与 Playwright 的路线类似但 API 设计更贴近中文开发者的使用习惯且把浏览器控制与HTTP 收发统一进了一个库。支持范围浏览器内核仅 Chromium 系Chrome、Edge 等 Python 版本v4 要求 Python 3.8 开源协议MIT免费2. 核心设计一个库两种形态DrissionPage 提供了三个页面对象这是理解它的关键对象能力类比ChromiumPage只控制浏览器渲染页面、模拟操作Selenium 的 driverSessionPage只收发 HTTP 数据不启动浏览器requests 的 sessionWebPage前两者结合可在两种模式间切换独特的设计设计意图非常清晰数据在 HTML 里 - SessionPage 就够了快 数据必须 JS 渲染或需要交互 - 换 ChromiumPage稳 同一站点先登录后采集 - WebPage 一个对象贯穿到底这一点与系列第 02 篇讲的选择路线完全吻合DrissionPage 相当于把 requests Playwright 两条路线合并进了一个 API 体系且两套 API 的元素定位、对象命名保持了一致性学习一次两种模式通用。3. 安装与最小可用示例安装pipinstall-UDrissionPage浏览器控制最小示例fromDrissionPageimportChromiumPage pageChromiumPage()page.get(https://www.baidu.com)page.ele(#kw).input(DrissionPage)page.ele(#su).click()print(page.title)print(page.eles(tag:h5))纯 HTTP 模式最小示例fromDrissionPageimportSessionPage pageSessionPage()page.get(https://example.com)print(page.html)titlepage.ele(#data .title).text注意两点1. ChromiumPage() 无参构造会自动查找本机 Chrome/Edge无需安装任何驱动 2. SessionPage 的 ele() 使用的是同一套定位语法返回的是纯 HTTP 元素对象4. 与 requests / Selenium / Playwright 的横向对比对比维度requestsSeleniumPlaywrightDrissionPage本质HTTP 请求库浏览器自动化浏览器自动化浏览器自动化 HTTP 二合一执行 JS否是是是是否需要驱动/独立运行时否是chromedriver 等需安装浏览器包否直连本机 Chrome/Edge支持的浏览器不涉及Chrome/Firefox/Edge/SafariChromium/Firefox/WebKit仅 Chromium 系元素等待不涉及需手写显式等待自动等待自动等待timeout 参数抓包 / 监听接口需配合 DevTools 手动分析需借助 HAR 或插件原生 network 监听原生listen语法极简跨语言生态全语言全语言生态最大多语言增长快Python 为主文档与社区语言英文英文为主中文丰富英文为主中文第一手文档反检测难度无浏览器特征webdriver 痕迹明显特征较少特征少可直连用户日常浏览器轻量程度最轻重较重中无驱动是显著减负分布式 / Grid不涉及成熟方案需自建无成熟方案结论性判断纯接口能解决的DrissionPage 的 SessionPage 与 requests 差距不大没必要为此上浏览器 需要浏览器的场景里DrissionPage 相对 Selenium 的部署减负是真实存在的—— 不用管理驱动版本、不用处理 driver 与浏览器版本匹配问题 相对 Playwright减负体现在可直连用户已安装的 Chrome 而 Playwright 通常需要下载其管理的浏览器构建。5. DrissionPage 的优点1. 无驱动架构不依赖 chromedriver不存在驱动与浏览器版本匹配问题 2. 双形态统一一个库覆盖 HTTP 与浏览器两条采集路线定位语法通用 3. API 简洁定位、交互、等待的接口数量明显少于 Selenium学习曲线平缓 4. 自动等待ele() 自带 timeout 参数默认等待元素出现减少手写等待代码 5. 抓包极简listen 系列接口可直接捕获浏览器发出的 Ajax 请求与响应 6. 可接管已有浏览器复用真实用户环境的登录态、扩展与指纹反检测友好 7. 中文文档完善官方文档为中文是国内一手学习资料入门门槛低 8. 元素定位语法统一id、class、tag、文本、属性、CSS、XPath 一套前缀语法全覆盖 9. 安装轻量pip 一条命令不强制下载浏览器 10. 迭代活跃版本更新频率高对新版 Chrome 的适配及时6. DrissionPage 的缺点与限制选型必须同时看另一面以下问题是真实存在的1. 内核受限v4 仅支持 Chromium 系无法覆盖 Firefox / Safari 测试需求 2. 生态规模社区体量远小于 Selenium / Playwright 英文资料几乎没有海外团队协作场景受限 3. 大规模调度没有官方 Grid / 分布式方案 上百浏览器实例的集群需要自行搭建 4. API 破坏性变更3.x 到 4.x 为彻底重写接口不兼容 网络上的旧教程大量失效学习时务必对齐官方 v4 文档 5. 资源消耗本质仍是驱动完整浏览器 内存与 CPU 开销与 Playwright / Selenium 同一量级并不轻量运行 6. 依赖 CDP与 Playwright 同样依赖 DevTools 协议 浏览器厂商若收紧协议暴露需要跟进适配 7. 纯 HTTP 模式SessionPage 功能面窄于 requests 生态 连接池精细控制、事件钩子等复杂 HTTP 场景仍以 requests/httpx 为主 8. 适用面企业级跨浏览器兼容性测试、移动端 WebView 自动化并非它的主场一句话定位DrissionPage 是个人与小团队做采集与自动化的高性价比选择 不是 Selenium/Playwright 在全领域的替代品。7. 用法详解一浏览器配置 ChromiumOptionsChromiumOptions用于控制浏览器的启动行为配置完成后传给ChromiumPagefromDrissionPageimportChromiumPage,ChromiumOptions coChromiumOptions()# 指定浏览器路径自动查找失败时使用co.set_browser_path(rC:\Program Files\Google\Chrome\Application\chrome.exe)# 无头模式后台运行不显示窗口co.set_headless()# 指定调试端口与用户数据目录多实例隔离的关键co.set_local_port(9222)co.set_user_data_path(rD:\chrome_data)# 设置代理co.set_proxy(127.0.0.1:7897)# 窗口尺寸co.set_argument(--window-size1920,1080)# 指定下载目录通过 Chrome 启动参数实现co.set_argument(--download.default_directoryD:/downloads)pageChromiumPage(co)ChromiumOptions 的方法均支持链式调用pageChromiumPage(ChromiumOptions().set_headless().set_local_port(9333))各配置项的使用场景set_browser_path 本机有多个浏览器或自动查找失败时 set_headless 服务器部署、不想弹窗干扰 set_user_data_path 每个采集任务使用独立用户目录避免会话串扰与端口冲突 set_proxy 代理出口控制配合 IP 池 set_argument 所有未被封装的 Chrome 启动参数都可以透传8. 用法详解二接管已有浏览器与反检测这是 DrissionPage 在反爬对抗中最实用的能力。思路是不启动新浏览器而是连接一个你已经在用的真实浏览器。第一步以调试端口启动本机 Chrome命令行chrome.exe --remote-debugging-port9222--user-data-dirD:\chrome_profile第二步让 DrissionPage 直接接管fromDrissionPageimportChromiumPage pageChromiumPage(127.0.0.1:9222)接管之后的效果1. 浏览器指纹是真实用户环境的指纹 2. 已登录的账号状态、Cookie、扩展全部复用 3. 不存在新启动浏览器的自动化初始化痕迹这套方案的常见用法是人工完成一次登录包括验证码、扫码之后脚本在同一浏览器内持续采集登录态无需任何搬运。必须提醒的边界接管真实浏览器能显著降低被识别的概率但不等于免检。 风控对抗是动态博弈任何工具的宣传都不能替代你自己的请求行为设计 频率、随机性、行为路径合理性。9. 用法详解三元素定位语法DrissionPage v4 使用统一的前缀语法ele()返回首个匹配元素eles()返回列表page.ele(#id)# 按 idpage.ele(.item)# 按 classpage.ele(tag:a)# 按标签名page.ele(namekw)# 按属性精确匹配page.ele(classbtn)# 按属性包含匹配page.ele(text:下一页)# 按文本内容包含匹配page.ele(css:div.item a)# 按 CSS 选择器page.ele(xpath://div[idx])# 按 XPath语法可组合逐步收窄page.eles(tag:divclassitem)# div 标签且 class 含 itempage.ele(text:登录 css:div a)# 文本含登录且匹配 CSS 路径相对定位在元素内部继续查找containerpage.ele(.list)linkscontainer.eles(tag:a)# 只在该容器内查找定位失败时的行为ele() 找不到时默认返回 None设置 timeout 会先等待再返回 eles() 找不到时返回空列表这套语法的价值在于同一字符串在 SessionPage、ChromiumPage、元素内部查找中完全通用切换到浏览器模式时不需要重写选择器。10. 用法详解四元素操作读取信息elepage.ele(.title)ele.text# 文本内容ele.attr(href)# 属性值ele.attrs# 全部属性字典ele.html# 外部 HTMLele.inner_html# 内部 HTMLele.tag# 标签名ele.states.is_displayed# 是否可见ele.states.is_enabled# 是否可用交互动作ele.click()# 点击默认先滚动到可视区域ele.click(by_jsTrue)# JS 点击绕过遮挡ele.input(关键词)# 输入文本默认先清空ele.input(追加内容,clearFalse)ele.hover()# 悬停ele.select(选项文本)# 下拉框选择文件上传对input[typefile]直接传入路径page.ele(tag:inputtypefile).input(rD:\photo.png)元素级截图ele.get_screenshot(pathele.png)这里体现了 DrissionPage 的一个设计原则常见动作全部内置了自动等待与滚动到视内的行为Selenium 中需要 Interaction 封装、ActionChains 处理的大头场景在这里是一行方法调用。11. 用法详解五等待机制DrissionPage 的等待主要收敛到一处——ele()系列的timeout参数elepage.ele(#lazy-item,timeout10)# 最多等 10 秒page.wait(2)# 显式等待 2 秒应急用行为模型元素未出现 - 在 timeout 内持续等待 超时 - 返回 None可捕获后续判空处理这与系列第 02 篇讲的显式等待优先原则是一致的只是 DrissionPage 把显式等待做成了默认路径开发者不再需要 import 一整套 ExpectedConditions。页面级控制page.set... 系列接口可配置加载等待策略、超时值等全局行为 具体项较多且随版本演进建议以官方 v4 文档的 Settings 章节为准12. 用法详解六标签页管理DrissionPage 将标签页tab作为一等公民每个 tab 是独立的 page 对象page.get_tab()# 当前标签页对象page.tab_ids# 全部标签页 idpage.latest_tab# 最新打开的标签页page.new_tab(https://example.com)# 新开标签页page.close_tab(tab)# 关闭指定标签页典型场景——点击后弹出新窗口继续操作page.ele(text:查看详情).click()tabpage.latest_tabprint(tab.url)datatab.ele(.detail).text多标签页并行采集时按 id 或条件获取目标 tabfortab_idinpage.tab_ids:tabpage.get_tab(tab_id)...13. 用法详解七滚动、截图与页面信息滚动page.scroll.to_bottom()# 滚到底部触发懒加载page.scroll.to_top()# 回到顶部page.scroll.down(500)# 向下滚动 500 像素page.scroll.to_see(ele)# 滚动使指定元素进入视口截图page.get_screenshot(pathpage.png,full_pageTrue)# 整页截图page.get_screenshot(pathview.png)# 可视区域截图页面信息page.url page.title page.html# 当前 DOM 的 HTML浏览器渲染后注意与系列第 01 篇的呼应点page.html是渲染后的结构等价于 DevTools 的 Elements 面板这一点与requests.get()拿到的原始源代码有本质区别。14. 用法详解八网络监听 listen——真正的杀手锏第 01 篇讲过最优采集路径是找到 Ajax 接口直接请求。DrissionPage 把这个找接口的过程做成了可编程接口page.listen.start(api/list)# 开始监听参数为 URL 特征串page.get(https://example.com/feed)# 触发请求packetpage.listen.wait()# 阻塞等待命中的请求print(packet.url)# 请求地址print(packet.method)# 请求方法print(packet.request.headers)# 请求头print(packet.response.body)# 响应体JSON 自动转 dictpage.listen.stop()# 结束监听批量捕获例如滚动分页场景packetspage.listen.wait(countall)# 取出当前已捕获的全部数据包它的实战价值1. 逆向分析阶段不用再手动翻 Network 面板脚本直接打印全部命中接口 2. 采集阶段正常驱动页面交互数据从监听包里直接拿 JSON 完全绕开 DOM 解析 3. 参数验证对比脚本请求与浏览器请求的 header/参数差异 排查 403 类问题效率显著提升与 Playwright 的 route/事件监听相比DrissionPage 的 listen 写法更接近抓包工具的使用直觉是它在采集场景中最受欢迎的功能。15. 用法详解九fetch 在浏览器内发请求listen负责收fetch负责发在浏览器上下文中直接发起请求自动携带当前页面的会话环境respage.fetch.get(https://example.com/api/list?page1)datares.json()print(res.status)print(res.url)适用场景接口带签名参数、纯 HTTP 库复现成本过高时 让浏览器替你完成签名与凭证携带脚本只管翻页取数。这与第 01 篇溯源思想一脉相承当加密链路难以还原时在正确的环境里发正确的请求是务实的降级方案。16. 用法详解十SessionPage 纯 HTTP 模式SessionPage 是内置的轻量 HTTP 客户端定位是不需要浏览器时的默认选择fromDrissionPageimportSessionPage pageSessionPage()page.get(https://example.com)page.post(https://example.com/api,json{key:value})print(page.status)print(page.html)# 直接用统一语法提取数据底层为 parsel 文档树foriteminpage.eles(.item):print(item.text,item.attr(href))会话与 Cookie 处理page.cookies()# 查看当前 cookieSessionPage 与 requests 的关系能力上约为 requests 的子集 内置了统一元素提取语法 需要精细控制连接池、钩子、重试策略时仍建议直接使用 requests/httpx 它的真正价值在于与 ChromiumPage 完全同构的 API切换模式零成本。17. 用法详解十一WebPage 双模式协同WebPage 将两种形态合并到同一个对象用模式切换代替两个实例fromDrissionPageimportWebPage pageWebPage()# 默认 console 模式纯 HTTP快page.get(https://example.com/login)# 遇到必须渲染的页面切到 browser 模式page.change_mode(browser)page.get(https://example.com/dashboard)datapage.ele(.report).text典型工作流登录、验证码等强交互环节走 browser 模式批量翻页取数切回 console 模式兼顾稳定性与吞吐。18. 实战案例滚动加载页面 接口直采综合以上能力一个无限滚动 接口捕获的完整采集骨架fromDrissionPageimportChromiumPage,ChromiumOptionsimporttime coChromiumOptions().set_local_port(9222)pageChromiumPage(co)page.listen.start(example.com/api/feed)page.get(https://example.com/feed)foriinrange(10):page.scroll.to_bottom()time.sleep(2)# 给懒加载留出触发时间forpacketinpage.listen.wait(countall):datapacket.response.body# 已经是 dict无需解析 DOMforitemindata.get(items,[]):print(item[id],item[title])page.listen.stop()这段代码的工程含义1. 采集目标是接口 JSON而非 DOM —— 解析层被整体移除 2. 页面只负责制造合法请求数据从监听通道拿走 3. 页面改版不影响脚本只要接口结构不变这正是第 01 篇方法论优先找接口在工具层的最佳落地形态。19. 常见问题 FAQQ1提示找不到浏览器 A用 co.set_browser_path() 显式指定 Chrome/Edge 可执行文件路径。 Q2多个脚本同时运行互相干扰 A每个实例配置独立的 set_local_port 与 set_user_data_path 本质上是隔离调试端口与用户数据目录。 Q3网上教程的代码跑不通 A大概率是 3.x 旧教程。v4 为彻底重写请只参考官方 v4 文档 与明确标注 4.x 的资料。 Q4无头模式下页面渲染不完整 A新版无头模式与原窗口渲染基本一致若异常可显式使用新版 headless 参数或退回有头模式配合虚拟显示Linux 下 xvfb。 Q5SessionPage 与 requests 冲突吗 A不冲突且不需要二选一。纯接口体系继续用 requests/httpx DrissionPage 只在需要浏览器或需要统一 API 时进场。20. 选型结论回到系列第 02 篇的选择路线把 DrissionPage 放进去后的完整决策树数据在接口里签名可复现 - requests / httpx不变成本最低 数据在接口里但签名链路复杂、必须依赖浏览器环境 - DrissionPagelisten fetch 组合是显著优势 页面必须渲染、需要交互单机或小规模 - DrissionPage无驱动部署减负 中文文档 反检测友好 - Playwright需要多内核或团队协作、工程化要求更高时 需要跨浏览器兼容测试、分布式大规模调度、多语言团队 - Playwright / Selenium生态与工程化仍是天花板 已有大量 Selenium 存量代码 - 维持现状新模块再评估三句话总结DrissionPage 的本质竞争力是无驱动 双形态 原生抓包。它把爬虫里浏览器只是接口触发器的主流场景做到了一站式解决。它的边界在生态与规模中小规模采集是甜点区企业级跨浏览器与集群调度仍不是它的主场。以上是本篇的全部内容。如果你正在被 chromedriver 版本匹配折磨或者想验证接口直采在工作流里怎么落地强烈建议从第 18 节的案例跑起。觉得有帮助欢迎点赞、收藏、转发评论区可以聊聊你正在用的自动化方案和踩过的坑。我是小马不起床我们下期见。