@iyaozhen 说白了就是两个协议间的抗衡，目前来看由于 puppeteer 的广泛接受度，以及微软也加入到 chromium 阵营，恐怕留给 webdriver 的时间就不多了。

我刚看了下 webdriver2，比起 1，就加了一点功能而已，还是太鸡肋了。举个简单的例子，你说 selenium 更侧重自动化测试，测试需要 profiling 的时候检测性能的时候，selenium 就得使用及其 hack 的手段了，而且也没发支持 devtools 那样丰富的功能。

总体来说 webdriver 协议理想是非常好的但是相比 devtools 协议的成熟度，还是差太远了。关键是 firefox 都已经意识到这点在与 puppeteer 团队合作开发 devtools 的支持了，可见一斑。我当然是希望能用统一的协议，但现实就是这么骨感。

@iyaozhen 是的。这段是很早期写的，用词有些过分了。我这就去修改下。我觉的 selenium 主要问题还是它基于 webdriver 协议 https://www.w3.org/TR/webdriver1/。这个协议的主要问题是还太早期，很多功能上的支持和 devtools 协议比起来还是太弱了，我还没研究 webdriver2，说不定会好些。比如你提到的劫持 ajax，webdriver1 根本就不支持，比如你要劫持 https 的请求时，webdriver1 只能借助代理，还要处理一堆证书问题，我恐怕你很难找个现成好用的插件（反正我是没找到 golang 和 java 的，只看到个 python 的 selenium-wire 但它还有限制）。你觉得这说服不了你，那对于 shadow-dom，webdriver1 就根本无法处理了。

如果你看下这个 https://github.com/sukgu/shadow-automation-selenium/issues/7#issuecomment-563062460
你就会知道这是质的差别，selenium 是无法处理 closed shadow root 的，然而 rod 可以。还有很多本质差别，日后有时间我们会尽量列个表出来。

分享下我们处理 zombie 的库： https://github.com/ysmood/leakless

具体用到了这个项目： https://github.com/go-rod/rod

@tinytin 多谢支持

@WilliamYang 欢迎来提需求或贡献代码～

@missdeer 我从来都不安装软件啊，打开页面就能用，discord 的网页版比 tg 的网页版好用太多了。

@Jirajine 看场景吧，没有最好的，只有合不合适需求。如果项目复杂或者需要多人合作可能有类型会更方便，我觉得道理和为什么 javascript 的大量开发者转为 typescript 是一样的。

而且写 golang 感觉和写脚本也没太大差别，大部分类型都可以省略。有了 IDE 辅助，反而比脚本语言完成同样的任务花的时间更少，也更少需要去看文档了。

@missdeer 我们通过很多讨论过之后决定用 discord 的，tg 很难用，连代码高亮都没有。slack 我工作每天用，感觉对开源社区不太友好，更适合闭源项目，免费版还各种限制。

好奇为什么 discord 劝退呢？能详细聊下吗？

@tremblingblue 比如 rod 作为人名还是非常常见的，就跟 jack 类似。

@movistar 说的挺中肯的，每一条都有积极意义。用你自己的逻辑来演示下你说这些话有多搞笑吧：

0. 什么是逻辑？
1. 有逻辑的标准是什么？

明显用常识就能得到 @movistar 所说几点的适用范围，将问题极值化来淡化隐含范围是辩论的取胜的技巧，但是太在乎驳倒对方对解决问题，合作，提升自我没有太大帮助。人家好心来提示你，你却要把话题从常识转移到哲学吗？

你是不是要开始忍不住想反驳我 “什么叫常识？范围的标准是什么？”

希望你能消消气，过两天冷静下来的了再看大家说的话，你要是还想反驳可以 @ 我，很多还是可以极值化到让你无法反驳的。

@guanzhangzhang 不是什么大佬，你有问题，可以随时去聊天群里问，如果去英文的群，那能回答你的人就更多。觉得问题有一般性，可以提 issue 。能来贡献代码的人，我都会尽量帮你提高的。

我来这里宣传是希望更多的人来维护，而不是来求夸奖求 star 的，那都是浮云。贡献者多了，我也能从大家的代码受益。

@xinyana 图发错了，这个 https://user-images.githubusercontent.com/1415488/86591816-41b80000-bfcd-11ea-8e82-b96452a1f91e.png

@xinyana readme 的 examples 里 第一个就是 hello world，我给不会 golang 的 QA 看，她都能猜到怎么用 rod：

https://user-images.githubusercontent.com/1415488/86591430-8e4f0b80-bfcc-11ea-87a2-20245f5743e6.png

要是你还觉得难，那你得先学习下 css selector 和爬虫相关的基础之时了

@darrh00 有详尽的文档，上 go 的官方网站就能看，readme 里 examples 就是很容易找到才对：

https://user-images.githubusercontent.com/1415488/86591222-184aa480-bfcc-11ea-8614-b7b2681b00b0.png

@Te11UA 这个 rod 已经有解决方案了，如果你想了解更多反爬虫经验，可以去聊天群找 PiuPiuPiu，他正在做相关的开发，这里就不聊敏感话题了。

@vus520 如果能把你的结果分享出来那就好了，简单的开个 issue 我们就能看到，这样能帮助更多的人选择哪种方案更符合他们的需求。

“cpu 的消耗” 订正为 “内存和 CPU 的消耗”

@vus520 那我推荐你试试 rod，splash 基于 QT, 它用的 webkit 和 v8，rod 基于 chromium，它用的 blink 和 v8，blink 是 fork 的 webkit，他们团队对此的解释可以看这里 http://www.chromium.org/blink/developer-faq

chrome 团队在这篇文章里说了：我们会有更好的多线程支持和性能提升。当然这点就仁者见仁智者见智了。我个人的观察是用 rod 内存消耗基本是几 MB，cpu 的消耗更大的是在于我渲染的什么网站，而不是选什么引擎。关注问题我们看瓶颈在哪，所以我发现容不容易开发才是我选择使用什么方案的决定性因素。比如如果我要实现个拖拽模拟，结果 webkit 要 hack 一堆函数，那我肯定是不会选 webkit 的。

如果吹毛求疵的话，rod 是基于 golang 的，splash 是基于 python，单从你自己项目的架构和可维护性来讲，golang 往往是爬虫更佳的选择。python 之所以现在还在爬虫界这么火，我觉得还是因为老一辈的积累和工具的成熟度，但仅我个人来看未来还是 golang 更适合处理这方面的业务。

@vus520 当然，默认就是不渲染图片。rod 使用的 headless 技术，这个你可以查阅相关文章，非常多。当然 rod 的性能肯定比 scrapy 之类的在理论上就差很多，但 rod 能做很多 scrapy 完全无法完成的复杂任务，且对爬虫的初学者更友好。