本文围绕 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 同步处理的代码实现。最后强调前端工程师设计技术方案时，需注重完整性与用户交互体验，后续将持续更新新方案。

本文围绕浏览器插件采集源网站数据时应对风控的方案展开。开篇指出插件采集数据方式多样，用户打开页面解析 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 学习小知识点，但作者强调细节重要性。

面试时被问及不用开发者平台接口而用插件采集数据的原因，作者整理出两方面原因。一是开发者接口数据与页面呈现数据存在差异，包括数据不一致、接口数据少于页面数据、数据语义有歧义，需用插件解析页面 dom 或请求前台接口获取所需数据。二是从用户交互与服务器资源成本考虑，插件可将采集任务分散到客户端，缓解服务器资源瓶颈，不过此方式并非适用于所有服务器瓶颈场景，需具体分析。

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

本文围绕 Chrome Extension 的 option 部分展开，在版本 138.0.7204.101（正式版本）(arm64) 环境下，阐述其基础知识、交互方式、编码方式及通信能力。option 页面作为核心部分，用途多样，且一个插件仅能设一个。其呈现方式有选项卡页面和弹框方式，各有特点与注意事项。打开方式包括用户通过插件 logo - 选项打开（由 manifest.json 配置决定呈现方式）和开发者编码实现。通信方面，不同组件间通信方式有别，option 页面因呈现方式不同，与其他组件通信存在特殊情况，文中还以表格形式总结相关内容。

出于安全考量，Chrome Extension 的 Content 层脚本（content.js）运行于隔离环境，无法与网页直接互访 JS 变量或函数，旨在防止恶意网站干扰扩展功能及保护扩展代码。content.js 给 window 对象设变量，是在自身隔离的 window 对象中，网页无法访问，反之亦然。若要实现 Content 层与网页通信和数据共享，有两种方案：一是推荐使用 window.postMessage，其在双方 window 全局变量下均有，支持安全跨域通信，消息发送独立，接收方用 window.addEventListener 处理，但因网络复杂，需为扩展设置唯一识别消息标识；二是向页面注入 script 标签及 js 代码。

本文聚焦 Chrome extension 在动态加载架构下短连接通信问题。因插件基础包不含短链接通信代码，将其监听置于动态层，致使页面打开久后，点击按钮无法与 Service Worker 通信。当年采用长链接通信方案，把长链接代码放基础包，断联时重建通道唤醒 Service Worker，但未调研短连接激活及通信情况。现下调研发现，Service Worker 休眠后，content 层发短链接可激活其状态，然而动态加载时，若将监听放动态层，该环境在 Service Worker 休眠时会被清除，导致短连接虽能唤醒却无法建立通信通道。基于此，提出可行方案，一是将短连接通信代码放基础包，动态包处理业务；二是 Service Worker 激活时重执行动态代码，但此方案处理逻辑复杂不推荐。