写在开篇

看过上一节的朋友是不是很期待这一小节？嘿嘿，那现在就开讲吧。

首先，我们来认识一下 cheerio 库。

cheerio 库是一个基于 Node.js 的轻量级 HTML/XML 解析工具，专门用于在服务端高效处理网页内容，其设计灵感来源于前端 JavaScript 的 jQuery 库，语法和操作方式高度相似，因此学习成本极低。

上面是豆包关于 cheerio 库的介绍，简单来说，cheerio 库就是可以像 jquery 一样操作 html 中的 dom 节点的一个 JS 库，两者区别就是 cheerio 可以将 html 字符串转换成 dom 节点实例后再进行操作，jquery 库是直接操作 DOM 节点。

技术方案设计

知道了 cheerio 库的作用后，“chrome.scripting + cheerio”这个方案的流程理解起来就真的很容易了。

浏览器插件使用scripting函数解析DOM数据

结合上图，流程说明如下：

1. Service Worker 打开 TAB；

2. 由 Service Worker 使用 chrome.scripting 函数获取新 TAB 页 body 下的所有 DOM 节点的字符串；

3. 利用 cheerio 进行 DOM 节点的解析获取到数据；

4. 将数据抛给第三方存储系统或向发起请求的 TAB 页抛出反馈信息。

5. 1. 数据的抛出可以单个单个向存储系统/请求侧抛出，也可以整体抛出，在这个方案中不会有多大影响（我们这里使用单个单个抛给服务端的方式，减少各个采集过程的相互影响）；

特别需要提醒的是，在这个方案中，新打开的TAB页不过就是展示出数据等待 Service Worker 去取而已，并不会涉及到新开 TAB 页中的浏览器 API 的调用。

另外，最重要的一点是，由以上流程图可以清晰的看出 单个链接的采集流程是同步执行的、两个链接采集之间也是同步执行的，所以，无论是流程理解上还是代码编写上，对于技术人员来说简直就是顺手拧开瓶般轻松；

方案落地与Demo

讲完理论的东西，我们当然要落到代码上啦～

首先，还是在发起的TAB页中插入可执行按钮。

接着就是Service Worker的事情了，很简单的同步代码。

以上代码实践后，就会有这样的效果：

与上一节方案对比

看到这里，你是不是也意识到：当数据存在于用户可视页面上时，本文阐述的方案更便捷呢？那接下来，我们就好好整理下两个方案到底有哪些区别吧！

1. 首当其冲的当然是最大的优势：在足够满足技术方案完整性的情况下，涉及的技术端之间的交互更少；

这里说的是，虽然方案设计时我们加入了服务端的内容，但事实上，因为本次方案不像上一小节的方案具有并发问题，也就是插件端存储数据的能力就完全可用了，即，服务端的存储可要可不要；

另一方面就是，虽然本小节的方案依然涉及到了TAB页的操控，但新TAB页中不会涉及到消息通信、浏览器API的调用，相当于出现异常逻辑的可能性更少了；

2. 第二个就是本文方案是同步执行，在开发方面对技术人员的比较友好（不仅流程理解性高，而且编码量具少）；

3. 兜底策略上，本方案只需注意 DOM 节点的出现时机即可；

4. 但从执行时间上来讲，其实两个方案的执行时间是差不多的，只不过本方案更方便去调试、缩短执行时间。

上一节的方案中有几个必要的停留时间：链接与链接之间的间隔时间、Service Worker 等待 Content 层准备好的时间、Content 层需要等待数据出现的时间、为避免消息丢失而需要等待的时间、最后判断是否全部链接采集完毕的等待时间；

本方案的必要停留时间就很少了：链接与链接之间的间隔时间、Content 层需要等待数据出现的时间；

相比较之下，越少的等待场景，调试起来肯定越简单；

写在最后

到此，应对源网站风控的几个方案就讲完了，后续如果有其他方案的，会继续更新，望各位朋友持续关注哈～