写在开篇

扎实的 “JS 逆向工程”能力 & 丰富的实战经验 可以让我们快速定位到源网站的风控关键点，但，这种能力需要在较长时间、反复的实践中获得，并不是一两篇文章就能够说明清楚的。

那，今天这一章要说点什么呢？

说说 Chrome Extension 中“请求头的动态设置”吧。毕竟在大部分情况下，获取到 关键请求头的参数 后，我们得设置请求头才能传递给源网站。而且，请求头的动态设置是浏览器插件的重要使用场景之一，只要涉及到数据爬取场景，那就不得不学这块知识点。

注，作者当前遇到的大部分情况都是将风控相关的参数信息设置在请求头中的，但也有少数是将参数设置在请求体中的，所以大家在运用中要遵循实际情况哦～

有关请求头设置说明

官方提供了 dynamic、session、static 三种方案，其中前两种是由 JS 代码主导设置的，而 static 则是配置在插件的 manifest.json 文件中的。

dynamic

由 JS 代码执行时主导设置，且在 Service Worker 中长效缓存（经实践测试，当插件 ID 不变时，缓存不会被清除）;

session

由 JS 代码执行时主导设置；

经 官方文档&测试实践 得出，session 请求头更新规则 会在浏览器关闭、更新时被清除；

static

static 是配置在插件的 manifest.json 文件中的，即，有更新就要升级插件包；

一般，为了业务场景的扩展灵活性，我们会尽量采用 dynamic、session 方式，技术方案是：在数据库中存储相关请求的请求头设置信息，在适当时机获取并设置，而不是每次有新业务场景的时候去更新插件包。

本文，我们采用 dynamic 方案来阐述，在请求之前进行设置&请求完毕之后清除更新规则，以此来达到动态设置的效果：

另外，虽然本文只提供了 dynamic 的相关方案，session 的设置代码其实是相似的，只不过设计方案更复杂而已：

哪些请求头需特别设置？

看过了设置动态设置请求头的代码后，你一定很好奇，哪些请求头需要被设置呢？

根据以往经验，一般这几个请求头需要设置，基本上它们都与风控管理有关（后续如果发现了更多需要设置的请求头，我也会及时更新到本文中）：

写在最后

好啦，以上就是本章的全部内容啦，让我们来回忆总结下知识点，希望你都能牢记吧～

首先，我们对接了当前 Chrome Extension V3 版本中有哪些更改请求头的方案；

其次，用核心代码展示了 dynamic 方案的运用，因为作为实践者，综合下来我更倾向于这个方案；

而后，点明了需要设置的、与风控相关度高的请求头；

作为实践者，如果你的插件面对的网站比较少且能够做好请求分类的话，可以在 service worker 启动时使用 session 设置，毕竟可以大大减少多次动态设置规则的时间&提高执行效率；

最后，送君一句话：以匠心、致初心，愿所有人能在这快餐、内卷、浮躁的时代里，找到自己想要为之脚踏实地努力的事情。