关于浏览器插件的用途，笔者在翻阅了100多个浏览器插件后，发现其用途主要表现在 浏览器定制化 和 数据采集。其中，浏览器定制化 包括了浏览器界面样式、书签页功能、网络定制等；而，数据采集 主要集中在“源数据提取&存储后便于后续使用、分析”场景中，并且，这些场景往往会涉及到网络请求与页面解析等技术方案。
最近，笔者在面试的过程中，收到了这样一个问题：为什么不直接采用开发者平台的接口获取数据，而使用插件采集呢？
在此，笔者整理了一下我的回答：
在我的经历中，使用插件采集分为两种情况：
第一种是：开发者接口中的数据不同于页面呈现数据；
第二种是：出于 用户交互/服务器资源 成本考虑。
首先，开发者平台接口数据与页面数据不一致表现在：
电商场景下，用户多次进入商品列表页时，平台根据进入时间、网络环境等因素的不同呈现给用户的数据也会不同，但用户的大部分需求是：希望能获取到当前看到的列表中的所有商品信息；所以这种场景，就只能使用插件实时解析页面dom节点的方案来解决；
开发者平台提供的接口中的数据少于（或根本没有）页面呈现的数据。这种场景，可以在 JS 逆向获得前台页面接口及逻辑后，使用插件直接请求前台页面接口获取数据；
第三种情况其实是第二种情况的延伸，即，开发者平台提供的数据语义与页面呈现数据的语义有歧义的情况下，用户希望以页面数据为准；所以在这种情况下，我们可以依据 JS 逆向得到的逻辑信息确定是使用插件直接请求接口还是解析dom方案来解决问题；
其次，使用浏览器插件采集数据的最大优势是 把原本集中在服务器上做的事情分散到客户端去做，即从 用户交互/服务器资源 等成本考虑，浏览器插件缓解了服务器资源瓶颈问题，比如这样一个场景：
当用户批量提交商品链接并采集某一电商网站的商品详情时，如果所有的用户都将商品地址提交给我方服务器，再由我方服务器去采集（无论是通过开发者平台接口还是RPA），那么采集效率都会随着链接数量的增长而降低，即，我方服务器很容易成为数据采集的瓶颈。而如果使用插件，将采集任务分布到多个用户的浏览器端直接与电商网站进行数据交互，那么就可以缓解我方服务器的压力（请结合架构图理解，图中服务器资源可以是自建服务器也可以是云服务器）；
请注意，分散到客户端的场景并不适用于所有的 服务器瓶颈 场景。比如 有一些场景本身就是为了减少人工操作成本而实施的服务器端的自动化方案（这种场景需要分析性能瓶颈后再做对应优化）；
