浏览器资源嗅探扩展为什么会被后台休眠杀掉：Cat-Catch 的三个平台级解法-平芜编程栈

浏览器资源嗅探扩展为什么会被后台休眠杀掉：Cat-Catch 的三个平台级解法

【免费下载链接】cat-catch猫抓浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch

Cat-Catch 是一个浏览器资源嗅探扩展，已整体迁到 Manifest V3。本文按问题顺序看它怎么处理 Service Worker 休眠、存储 IO 和 Firefox 兼容这三件平台级难事，以及每个方案的落点和代价。

心跳间隔为什么定在 4 分 10 秒

Service Worker 能活多久

Manifest V3 的后台是 Service Worker，浏览器会在它空闲 5 分钟后直接终止进程。对一个嗅探扩展来说，这等于后台随时会"断电"：正在缓冲的资源列表、未完成的下载状态都会随进程消失。Cat-Catch 在 1.0.24 就加了 Heart Beat，2.0.0 版本说明里写得很直白——后台被杀死后要能立刻唤醒自己。

做法是让内容脚本在页面里维持一条 Port 连接。页面只要开着，这条连接就不断给后台续命。核心逻辑在 js/background.js 开头几十行，简化后是这样：

chrome.runtime.onConnect.addListener(function (Port) { if (chrome.runtime.lastError || Port.name !== "HeartBeat") return; Port.postMessage("HeartBeat"); const interval = setInterval(function () { clearInterval(interval); Port.disconnect(); // 4 分 10 秒后主动断开，等下一次重连 }, 250000); });

250000 毫秒是 4 分 10 秒，比 5 分钟休眠窗口短 50 秒。到期后扩展主动断开 Port，由内容脚本重新发起连接，相当于在浏览器动手之前自己把心跳"续"了一次。断连回调里还会清掉定时器，避免页面关闭后留下悬挂的 interval。

两条补充的续命路径

光有 Port 还不够。同一文件里还有一行setInterval(chrome.runtime.getPlatformInfo, 25 * 1000)，每 25 秒调用一次无害的 runtime API，用来应对 Port 短暂缺席的情况；popup 页面打开时也会发一条 HeartBeat 消息给后台（js/popup.js）。多标签页场景下，任一活跃页面都能维持后台存活。

对开发者的参考：如果你的扩展也依赖长期后台状态，"5 分钟窗口 − 固定安全余量"是一个可以直接套用的定参方法，比追求常驻进程更稳。

运行数据换用 storage.session 算的是哪笔账

高频写 local 出过什么问题

嗅探扩展的写入模式和普通工具类扩展完全不同：每捕获一个资源就要动一次存储，一个页面几十秒内可能触发上百次。2.5.3 之前这些运行时数据存在storage.local，走磁盘持久化路径，写多了就出现 IO 报错，严重到扩展直接不可用的地步。2.5.3 把嗅探缓存整体挪到storage.session，版本说明里明确写着目的：减少 IO 错误导致扩展无法使用，前提是 Chrome 104 以上。

session 存储走内存，会话结束即清空——恰好匹配"资源列表只对本次浏览会话有意义"的语义，用户配置仍留在 local。

9999 条上限：内存的最后防线

换存储解决不了另一件事：数据本身会膨胀。js/background.js 里给每个标签页设了长度阈值，超限就整页清空缓存；js/init.js 中这个阈值按端型区分，移动端是 999，桌面端是 9999（2.5.9 版本引入的每页上限）。配套的查重也做了成本控制：URL 指纹只维护最近 500 条，超过就整体清掉重来，popup 页面在 500 条以上也允许中断加载。

对开发者的参考："运行时缓存与会话同寿命、配置与浏览器同寿命"是比"全部持久化"更省事的分层；给每类数据配一个硬上限，比事后做清理逻辑可靠。

Firefox 线是怎么并行维护的

一份代码，两份声明

仓库里同时存在manifest.json和manifest.firefox.json，Firefox 侧另配 js/polyfill.js 兼容层。js/background.js 的头部注释写明了加载模型差异：Chrome 走 V3 的 service_worker，Firefox 走 background.scripts，脚本在初始化时先判断是否已加载，避免重复注入。时间线上，1.0.24 加入 firefox.js 兼容层并上架 Firefox，2.4.6 把版本要求提到 113+，2.5.7 完成 Firefox 侧的 Manifest V3 升级，且脚本注入类功能要求 128 以上。

差异落在哪几个点上

能力	Chrome / Edge	Firefox	猫抓的落点
Manifest V3	支持	128 起支持	双 manifest 构建
storage.session	支持	不支持	运行时回退 local
sidePanel	支持	不支持	该入口直接隐藏
declarativeNetRequest	支持	支持	按条件启用
WebRTC 录制	支持	受限支持	功能降级

代码里的回退写法很统一：chrome.storage.session ?? chrome.storage.local，Firefox 或旧版本 Chromium 自动落到 local。侧边栏是 Chromium 独占能力（2.6.2 新增选项时注明不支持 Firefox），2.6.3 还专门修了 Chromium 114 以下缺 sidePanel API 导致扩展起不来的问题。

对开发者的参考：双 manifest + 薄兼容层比在代码里到处if (isFirefox)便宜得多，前提是接受"部分入口按引擎隐藏"，而不是为 Firefox 造一套替代品。

🎬 把 m3u8 解析链路修到能应付真实世界的流

嗅探只解决"看见"，能不能下载下来取决于解析链路。这条链路的几个关键动作都有明确的版本记录：

2.0.0：支持 N_m3u8DL-CLI 的m3u8dl://协议，m3u8 解析器开始支持在线合并下载；
2.2.2：解析器改用 hls.js，同时把下载器和解析器拆成两个页面；
2.4.7：js/m3u8.js 的并发上限调整为 6 条线程，并支持自定义请求头；同版本加入 Aria2 RPC 下载；
2.5.7：疑似密钥增加验证功能，m3u8dl://和调用本地程序都加了下发前确认参数；
2.6.2 / 2.6.8：录制失败重试、文件大小估算、HEVC/H265 预览，再到 EXT-X-BYTERANGE 标签的合并下载、任意切片勾选合并、嵌套在线 ffmpeg（不再单独开新标签）；
2.7.1：下载出错自动重试。

6 线程不是拍脑袋的数字，而是 2.4.7 在重写下载器后的压线值：再高容易触发站点限流，再低拖长直播录制的追赶时间。

对开发者的参考：m3u8 场景的坑大多是"真实世界"的——一次性 URL、加密密钥、BYTERANGE 分片、断流。按问题逐个打补丁、每个补丁带版本号，比一次性重写下载器更容易被社区验证。

两道安全阀：内容净化与屏蔽列表

Trusted Types 的降级写法

2.2.0 引入 Trusted Types 后，catch-script/catch.js 里的initTrustedTypes()先尝试探测：页面 CSP 若已开启 Trusted Types，就注册一个名为catCatchPolicy的策略来放行createHTML；探测失败则回退到普通字符串，并打一条 warn。注入脚本里大量用 innerHTML 拼装资源条目，这类页面在严格 CSP 站点上容易被拦，提前注册策略比被拦了再修省事。