安利一个自己的开源项目： DrissionPage

[g1879]

DrissionPage 是我一个人开发了几年的开源项目，现在 GitHub 上获得 3.8K 星，gitee 上 3.5 星，并且获得了 gitee 的 GPV 项目。

项目地址：https://gitee.com/g1879/DrissionPage 项目文档：https://g1879.gitee.io/drissionpagedocs

✨️ 概述

DrissionPage 是一个基于 python 的网页自动化工具。

它既能控制浏览器，也能收发数据包，还能把两者合而为一。

可兼顾浏览器自动化的便利性和 requests 的高效率。

它功能强大，内置无数人性化设计和便捷功能。

它的语法简洁而优雅，代码量少，对新手友好。

---

🎇 强大的自研内核

本库采用全自研的内核，内置很多实用功能，对常用功能作了整合和优化，对比 selenium ，有以下优点：

• 无 webdriver 特征

• 无需为不同版本的浏览器下载不同的驱动

• 运行速度更快

• 可以跨<iframe>查找元素，无需切入切出

• 把<iframe>看作普通元素，获取后可直接在其中查找元素，逻辑更清晰

• 可以同时操作浏览器中的多个标签页，即使标签页为非激活状态，无需切换

• 可以直接读取浏览器缓存来保存图片，无需用 GUI 点击另存

• 可以对整个网页截图，包括视口外的部分（ 90 以上版本浏览器支持）

• 可处理非open状态的 shadow-root

---

🎇 亮点功能

除了以上优点，本库还内置了无数人性化设计。

• 极简的语法规则。集成大量常用功能，代码更优雅

• 定位元素更加容易，功能更强大稳定

• 无处不在的等待和自动重试功能。使不稳定的网络变得易于控制，程序更稳定，编写更省心

• 提供强大的下载工具。操作浏览器时也能享受快捷可靠的下载功能

• 允许反复使用已经打开的浏览器。无须每次运行从头启动浏览器，调试超方便

• 使用 ini 文件保存常用配置，自动调用，提供便捷的设置，远离繁杂的配置项

• 内置 lxml 作为解析引擎，解析速度成几个数量级提升

• 使用 POM 模式封装，可直接用于测试，便于扩展

• 高度集成的便利功能，从每个细节中体现

• 还有很多细节，这里不一一列举，欢迎实际使用中体验：）

[x2ve]

@g1879 #17 非常感谢，开始就使用了 page.listen.steps(),只是没注意自己的 api 接口地址一直变化，导致只抓取到了首次的地址，目前已正常采集

[RangerWolf]

问一下，能远程控制吗？ 比如一个 leader + n 个 worker ，每个 worker 配置 1 个实际工作的实例

[g1879]

@RangerWolf 我没有这个需求没有试过，群里好像有人这样用。

[fdghjk]

@g1879 #7 换代理是必须要用的

[LeeReamond]

别的都没啥问题，问题是我没有 gitee 账号，注册账号还要绑手机号的代码托管服务？

[GeekGao]

很好很强大。

[LeeReamond]

@g1879 试用了一下还不错，尤其是不需要 chromedriver 这点非常好，但是现在有个痛点。

目前引擎的所有代码在 alert 弹出后都会阻塞，无法在用户层对于 alert 事件做任何处理，只能设置为自动确认才能让代码自动执行。

如果 alert 内部含有有效信息的话则完全无法获取。

是否可以参考 selenium 将 alert 设计成异常的形式，用户让可以对中断进行处理。

[g1879]

@LeeReamond 用 handle_alert()，是可以处理的，不一定自动确认，accept 参数设为 None ，只获取 alert 文本不进行处理，然后再调用一次 handle_alert()处理就行。handle_alert()会自动等待 alert 出现再处理。
另外，还有 next_one 参数，用来处理下一次出现的 alert ，主要是处理页面跳转时触发的 alert 。

[LeeReamond]

@g1879 最主要是有阻塞的问题，因为网站弹窗不一定是在预期时候出现的，你这么搞不确定什么时候自己代码就阻塞住了，所以最合适的就是上报异常。如果按你说的在跳转页面前使用 next_one 预设下个页面会弹窗，但是用户无法确定网页运行到什么状态才会弹窗，这就导致虽然能捕获弹窗数据，但是用户代码里感知不到什么位置出现弹窗了。

另外还有个问题是，全局等待，像 selenium 有个隐式等待（就是页面所需所有资源加载完毕）的 api ，我看你的文档里只有一个 start_load 和一个 doc_loaded ，是不是都不太对

[g1879]

@LeeReamond 不是全局等待，这个一两句说不太清楚，你先了解了解。我的等待方式比 selenium 好。比如说，selenium 的等待只能以最长的等待设置为准，我的可以用短的覆盖长的等待时间，有很多情况都灵活得多。
至于 alert ，我不理解你的意思。一般做自动化都先把网站行为摸透，知道什么时候会出现 alert 吧，不一定出现的，设个短的 timeout 就行了。

[LeeReamond]

@g1879 虽然我不是做专业爬虫工作的，但你这个设计思路那不是往增加开发人员心智负担上使劲。。。因为业务的复杂度是无限的，网站为了给自动爬取增加不适会用各种办法，如果用异常上报的方式，开发人员只需要规定在某个时期内出现异常那么就重新开始流程这样。但是如果你要求把行为摸透，那只有两种可能，要不然就是网站行为太单纯，要不然就是极大增加开发人员心智负担，打上无数的状态控制。说到底最关键原因还是 alert 会阻塞用户代码，你没法用常规的流程控制手段去控制它。

再者我想知道 chromnium 实现精准控制状态，还要保证爬虫速度，这得多花多少经历来进行流程控制，另外还要假设对方网站不会频繁更新，否则你无法写一个大略的状态控制来增加鲁棒性。我很高兴你这个框架可以不用像 selenium 一样隔一段时间还要更换 chromedriver ，但是你现在提供的功能我代码迁移不过去

[g1879]

@LeeReamond 不太明白，你意思是增加一个设置，接收到 alert 就抛出异常？

[LeeReamond]

@g1879 起码 selenium 是这样处理的。我试着把在跑的几个脚本往你这个迁移，主要问题就是 alert 。目前的几个典型场景需要解决方案：

1.网站没有严格反爬，但也不会让自动脚本太舒服，alert 行为不是很可控，会随机弹。
2.在没有严格流程控制的情况下不让弹窗阻塞脚本（ selenium 的方案是在上级 catch 异常即可，所以我可以很粗糙地开发但仍然保持对流程的高度控制）。
3. 服务器对验证码的判断结果由 alert 返回。这个场景的问题是，验证码 cv 识别有成功率，handle 不能撤回只能依赖 timeout 和等待让代码健壮性变成依托。

以上这些场景都是 trycatch 非常合适的应用场景，你不知道流程会在脚本执行到哪步时触发异常行为，但是因为有异常直接 catch 所以整体流程依然可控。现在没有办法 catch 的原因是弹窗后整个被阻塞，即使尝试用 next_one 预埋 handler ，因为你是单线程同步脚本，又没有个回调，这该怎么控制。

[g1879]

@LeeReamond 你用的是哪个版本？新版出现 alert 是没有阻塞的，alert 存在也会向后执行，但如果这个时候调用设计 js 的操作，才会抛出 AlertExistsError 。你的代码给我看看？

[ZnductR0MjHvjRQ3]

大佬 是否支持 带账号密码的代理 IP ？ 以及无痕模式/隔离？

[forsky]

编程新人， 这是我 pip 安装的第一个包。 很好用，还在学习中

[ZnductR0MjHvjRQ3]

仔细看了一下文档 确实牛逼
说真的大佬 就光说文档这块 都比 翻起来巨恶心的 selenium 强了很多了
并且我仔细看了一下 4.0 功能确实也很全了，做大部分自动化的东西也已经够用了
目前手里的一个项目就需要用到自动化浏览器的功能，后面我尝试用一下看

[LeeReamond]

@g1879 最近一周内安装的版本。你指的没有阻塞是设置了 autoaccept 或者 nextone 的情况下没有阻塞吧，普通的出现弹窗事件->处理弹窗事件的逻辑是阻塞的。

https://gist.github.com/RedmondLee/ec0c13215c97c9902cd8c12ecbfbca1c

[g1879]

@LeeReamond 如果接管前 alert 就存在，是没有办法接管的。

[LeeReamond]

@g1879 上面说了半天了，你指的没有阻塞是设置了 autoaccept 或者 nextone 的情况，而无法实现对弹窗的发现后处理。