写在开篇

当我们 采集的数据来源于源网站的API & 请求接口与用户地址栏有对应的唯一关键值 & 短时间内无法逐个突破风控关键点 时，“请求重放”就出场了。

PS. 如果说，上一章讲述的 请求头设置 是采集过程中的后置部分的话，那么本章就是数据采集过程的前置篇。因为，只有探索到了真正的请求接口和请求参数，才能落实到请求里去，所以，这一章的内容讲完，你应该就可以将采集流程串起来&实践数据采集了哦～

数据重放与插件

正如《浏览器插件数据采集时，被源网站风控的应对方案（一）》一文中所阐述的，“ 请求重放 ”的现实依据是：用户正常打开源网站时，源网站上的请求可以正常通过源网站的风控系统。据此，我们只需将合规的请求接口地址、参数、头部等信息存储下来并重新执行一次请求就可以获取到目标数据了。

结合 Chrome Extension，这个过程就涉及到了两个问题：

• 请求接口地址、参数、头部等信息从哪里来？

• 请求信息拿到后又如何执行重放？

首先，我们来讲讲“从哪里获取请求信息”。

现在，请你由“上面阐述的、用户正常操作的交互流程”发散思维：用户是 自行 打开源网页进行浏览时，可以看到完整的数据。那么，如果，Chrome Extension 能为我们 自动的、默默的 打开页面&等我们拿到请求信息后再关掉 TAB 的话就好了（静默打开 是为了用户侧没有那么强烈的交互感官刺激）。

很幸运的是，Chrome Extension 拥有操控 TAB 的能力。所以，第一个问题“光靠人为操作的流程太过繁琐&不便捷”从理论上已经解决。

那，又如何获取到请求信息呢？这就涉及到了 Service Worker 层的 chrome.webRequest.onBeforeSendHeaders.addListener 监听设置技术点啦。本章就不对这块内容做详述介绍了，有兴趣的同学可以参考 官方文档 ，基本原理就是为某一类请求设置一种监听：当某种请求出现时，拦截并获取到这种请求及该请求的参数。

说完了“获取请求信息”，接下来的“请求重放”就简单了：不过就是从存储介质中将数据提取出来，再用 fetch 等浏览器 API 执行一下请求一下就可以了～

好啦，到此，从 Chrome Extension 出发，实践“请求重放”方案就到此为止啦～接下来，我来展示下我本地的交互 Demo ～（PS.你可以对照上面的代码与视频中的日志理解）

写在结尾

除去代码，本章其实很简短，但是涵盖了“ Chrome Extension 自动操控 TAB 与请求拦截”等实践性较强的内容，所以，如果想较好的理解本章知识点，请务必实践一遍或至少对照视频与代码理解一遍（如有问题，请微信公众号留言哦～）；

另外，最后着重说明两点，也是 上述技术方案中并未涉及持久化存储，而是设计成简单的“ 自动打开TAB-获取请求及参数-重放请求-关闭TAB ”流程 的两个原因：

1. 很多时候，源网站的风控系统都会检测请求时间，如果你将一个请求存储下来&很长一段时间之后再去使用的话，很有可能这个请求会失效；

2. 因为“请求重放时，请求参数与之前的一次请求完全一致”，如果源网站有意要拦截的话是十分简单的，所以大家一定要控制好重放次数。一般，一个请求重放一次就可以丢弃了；

最后的最后，打个小广告：本章内容只适用于“源网站数据来源于 API 的数据获取，而非来源于页面 DOM 结构的数据获取”，如果想知道如何快速&尽量少被风控的同学可以期待一下我的下一篇文章哦～；