本文聚焦于 Chrome Extension 中请求头的动态设置。开篇指出 “JS 逆向工程” 能力虽能定位源网站风控关键点，但获取关键请求头部参数后，设置请求头是重要环节。官方提供 dynamic、session、static 三种请求头设置方案，鉴于业务扩展灵活性，作者倾向于前两者，本文着重阐述 dynamic 方案。文中详细介绍了 dynamic 方案实现代码，包括生成唯一规则 ID、检查规则是否存在、设置和清除更新规则等函数，同时说明 session 方案代码与之类似，但设计更复杂，设置时机为插件启动时。此外，还点明了如 'referer'、'origin' 等几个与风控相关且直接设置在 fetch 头部无效、需特别设置的请求头。最后，作者总结知识点，强调在合法合规前提下获取和运用数据，维护网络秩序。

本文聚焦于 Chrome Extension 通信，指出通信是 Chrome Extension 关键技术，涉及扩展内部模块间、扩展与扩展、扩展与原生应用以及扩展与 web 端的数据交互。作者在文中主要展示了自行整理的关于浏览器扩展通信相关的汇总表格，并预告未来会对每种通信项展开详细解读与实践，同时给出文章合集相关推荐。

本文围绕 Chrome Extension 中 Service Worker 展开，强调其对 Chrome Extension 应用的重要性，并记录关于它的一些关键细节点。指出每个 Chrome Extension 仅有一个 Service Worker，manifest 文件里设置的 js 文件在 Service Worker 每次启动及休眠后重启时执行，执行该文件若需设置持久性数据，要做好唯一性校验。还表明 Service Worker 休眠后，内存变量（全局变量）、特定监听函数及动态请求头设置规则会被清除，开发者应适时采用持久性缓存方案。同时说明多个插件的 Service Worker 环境相互隔离，一个插件内 Content 与 Service Worker 是 N - 1 关系，Content 触发 Service Worker 操作要做好唯一性校验，且建立长链接通信能唤醒休眠的 Service Worker，最佳实践是监听断联时机并重建长链接，以确保插件随时可用。最后表示内容基于实践测试，期待指正并会持续更新

本文介绍基于 “chrome.scripting + cheerio” 的源网站数据采集方案，核心流程为：Service Worker 打开 TAB 页，通过 chrome.scripting 获取 DOM 字符串，利用 cheerio 库解析数据并抛给服务端。相较于上一方案，该方案优势显著：交互更少，因无并发问题，插件端可存储数据，服务端非必需；同步执行，流程易理解、编码量少，对开发者友好；只需关注 DOM 节点出现时机，异常逻辑减少；执行时间相近但更易调试，减少了等待场景。文中还展示了插入按钮、Service Worker 同步处理的代码实现。最后强调前端工程师设计技术方案时，需注重完整性与用户交互体验，后续将持续更新新方案。

本文介绍源网站数据采集方案，采用 Chrome Extension 实现，流程为 “打开 TAB 页 ->Dom 解析”。解析 Dom 有两种方案，本文先探讨不借助第三方库、由 Content 层用 DOM API 提取数据的方案，涉及服务端、插件端 Content 层和 Service Worker 层交互，还展示了获取百度首页搜索按钮文字的代码实现，最后提及该方案价值及后续将介绍的 “cheerio + chrome.scripting” 方案。

本文围绕在特定数据采集场景下，Chrome Extension 中 “请求重放” 方案的应用展开。当采集数据源于源网站 API，请求接口与用户地址栏存在唯一关键值且短时间难以突破风控关键点时，“请求重放” 方案登场。该方案基于用户正常打开源网站请求可通过风控系统这一现实依据，通过 Chrome Extension 实现请求及参数的获取与重放。文章详细阐述了获取请求内容和请求重放的具体实现过程，包括在 replayRequestUtil.js 和 service-worker.js 等文件中编写代码，利用 chrome.webRequest.onBeforeSendHeaders.addListener 监听请求，通过fetch等 API 重放请求。同时给出了本地交互 Demo 的测试流程，并强调方案未涉及持久化存储的原因，一是源网站风控可能检测请求时间，长时间存储的请求易失效；二是重放请求参数一致易被拦截，应控制重放次数。最后表明该方案仅适用于 API 数据获取，呼吁合法合规获取数据。

本文围绕浏览器插件采集源网站数据时应对风控的方案展开。开篇指出插件采集数据方式多样，用户打开页面解析 DOM 虽稳妥但繁琐低效，常见场景是用户提交链接由插件后台循环请求获取数据，然而此方式易遇源网站风控。接着介绍三种应对方案：一是确认源网站风控关键点并解决，考验 JS 逆向工程能力，优势在于掌握后能快速采集且开发简单；二是请求重放，适用于难找出风控关键点的高风控网站，虽复杂易被识别，但适合 API 获取数据场景且对开发者友好；三是插件操控 TAB 并解析数据，最贴近用户操作路径，较为稳妥，但技术复杂，不适用于无法从页面 DOM 获取全部数据的场景。最后强调应对风控核心是贴近用户操作路径，各方案无绝对好坏，需平衡选择，还提及源网站、插件开发者、数据使用方应遵循的原则，并预告后续会有方案落地的系列文章

作者起初对 chrome.offscreen 应用场景不明，受相关文章启发，梳理其在控制网页音频开关场景的应用。此前应对该需求，采用插件在每个 TAB 页注入音频 DOM 节点，由 Service Worker 控制开关，但存在多音频同时播放及消息传递导致音频冲突问题，影响用户体验。而 chrome.offscreen 方案中，同一时间浏览器仅一个音频，监听处理和消息发送主要在 Service Worker 与 offscreen 间，更为简单可靠。文中通过代码示例展示了在离屏文档创建音频节点、接收消息开关音频，以及在 Service Worker 监听 TAB 页相关事件控制音频。最后作者表示 chrome.offscreen 还具备处理 iframe、剪切板等能力，未来将继续探索并分享。

本文围绕 Chrome 扩展中 chrome.storage.session 数据清除时机展开探讨。在 Chrome 扩展里，chrome.storage.session 数据会在插件被禁用、重启、更新及浏览器重启时清除，这一特性本适用于减少网络请求场景，即获取更新时效不敏感数据以降低云服务商成本。但在 Chrome 扩展 V3 版本中，因扩展后台 Service Worker 有 “休眠” 概念，作者对 “reloaded” 是否包含休眠后重启存疑，若包含则 chrome.storage.session 不适用于该场景。通过实践，作者设计了涉及 Chrome 扩展 Content 与 Service Worker 层的通信及用户操作交互流程进行验证。最终得出 chrome.storage.session 数据清除时机 “reloaded” 不包括 “休眠后的重启时机”，并展示了部分相关代码及测试交互分步解说。虽为 Chrome Extension 学习小知识点，但作者强调细节重要性。

文章围绕 Chrome Extension 中消息竞争回复问题展开，引用官方文档提示，指出当发送短连接消息后，多个接收方监听函数处理消息时，发送方仅接收最先调用sendResponse函数返回的消息，其余忽略。“多个监听函数” 可分布于多个插件或一个插件的不同部分。作者凭借自身经验，成功验证了两种场景：一是一个接收方设置多个监听函数，通过在一个插件内，Content 层发送消息，Service Worker/option 设置多个监听函数捕获处理消息的代码示例展示；二是多个接收方各自设置监听函数，以多个插件间，一个插件 Content 层发送消息，另一个插件的 Service Worker 与 option 页面都监听函数的代码示例说明。最后作者表示若后续验证其他场景将及时更新。