猫抓 Cat-Catch从资源嗅探到 M3U8 引擎的 6 次架构选型【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch猫抓Cat-Catch是一个浏览器资源嗅探扩展当前版本 2.7.2运行在 Manifest V3 之上。它要解决的核心痛点是网页里正在播放或加载的媒体资源mp4、m3u8、mpd 等用户往往拿不到直链或者直链带 Referer 校验无法直接下载。猫抓的能力边界是被动嗅探 主动捕获 M3U8/MPD 解析合并 WebRTC 录制覆盖 Chromium 系和 Firefox不支持 Safari。后台为什么不会死Service Worker 的三条保活路径MV3 把 background 从常驻页面改成 Service Worker空闲约 5 分钟即被浏览器终止。对普通扩展这不重要但对嗅探工具是致命的——webRequest回调注册在 Worker 里Worker 一死所有请求就都漏掉了。猫抓在 js/background.js 里做了三件事// 心跳保活popup 打开时建立 PortWorker 内 4 分 10 秒后主动断开 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(); }, 250000); });为什么是 250000ms4 分 10 秒而不是 300000ms因为浏览器给的终止窗口约 5 分钟留 50 秒余量应对系统调度抖动断开后由 popup 重新连接形成循环。这是第二、三条路径之外的兜底前两条都更免费保活手段原理触发条件代价注册webNavigation空监听导航事件本身就是活动信号用户在浏览网页时持续有效无setInterval(getPlatformInfo, 25s)定时调用 API 阻止休眠判定Worker 存活期间每 25 秒一次轻量调用心跳 Port 500ms 自唤醒显式通信延长寿命被杀后首个事件回调里setTimeout重新初始化事件驱动被杀瞬间可能丢一条数据第三条路径值得单独说findMedia入口检查全局初始化标志未完成就 500ms 后重试自身——Worker 被杀后靠下一条网络请求把自己叫醒。这等于承认了保活不可能 100% 成功转而保证死了也能立刻复活。保活方案本身不追求精确追求的是恢复路径足够短。模块职责谁负责抓谁负责下谁负责存猫抓没有做微内核那一套实际是一个中心 几个专用页的结构。核心判断标准只有一条数据能不能离开 background。模块核心职责对外接口依赖谁js/background.js嗅探主逻辑、请求头缓存、数据持久化webRequest回调、runtime消息全部模块的数据源头catch-script/catch.js页内主动捕获代理 MediaSource、捕获面板 UI注入页面经runtime回传数据background 的开关与设置js/m3u8.downloader.js切片并发下载、合并、转码调度m3u8.html 页面内hls.js、mux、m3u8-decrypt见 lib/js/m3u8.js / js/mpd.jsM3U8/DASH 解析页逻辑、参数拼装各自独立 HTML 页面background 的嗅探数据js/popup.js资源列表、筛选、正则匹配、预览入口popup.html / sidePanelbackground 存储的数据catch-script/search.js、recorder*.js、webrtc.js深度搜索、视频缓存录制、WebRTC 录制按需注入的独立脚本页面环境边界的取舍很实际解析器、下载器、预览器都做成独立 HTML 页面而不是塞进 popup因为每个页面有自己的第三方库hls.js、mpd-parser、StreamSaver独立页面天然隔离内存与脚本生命周期代价是多几次页面间消息往返。主动捕获脚本放在catch-script/而非js/区分注入网页执行的代码和扩展自有页面代码这个目录约定在 review 时比注释更省解释成本。模块划分的第一原则是让重逻辑解析、下载远离生命周期最短的上下文Worker 和 popup。图M3U8 解析器页面切片列表、自定义请求头、密钥验证与 ffmpeg 参数都集中在这一个独立页面里性能与稳定性三个场景的阈值怎么定并发下载。2.4.7 版本把 m3u8 解析器最大下载线程调整为 6。没有做动态线程池原因是切片下载是 IO 密集且单任务体量小固定 6 并发在大多数网络下已接近带宽上限而动态调度在 Service Worker 被杀的场景下状态难以恢复。稳定性补丁都花在恢复路径上2.4.8 修下载失败丢失线程2.6.2 加录制失败重试2.7.1 加下载出错自动重试——与其优化正常路径的速度不如保证异常路径不卡死。内存。三个阈值各管一层场景阈值版本解决的问题每页面最大储存9999 条2.5.9广告密集的页面把缓存无限撑大popup 加载超过 500 条可中断2.4.2长列表渲染卡死 popup资源去重urlMap 重复资源排除2.6.2 重构同一视频跨页重抓造成内存翻倍IO。2.5.3 把运行时数据从storage.local迁到storage.session官方 changelog 的原话是减少 IO 错误导致扩展无法使用要求 Chrome 104。持久化不再每次嗅探都写盘而是靠chrome.alarms定时把内存里的cacheData快照写一次代码里就一行回退(chrome.storage.session ?? chrome.storage.local).set({ MediaData: cacheData });??直接覆盖了 Firefox 和旧版本 Chromium 两种不支持的场景。写盘频率从每个请求降到每个 alarm 周期磁盘写入量降了一到两个数量级。稳定性阈值宁可保守一点9999 而非 999因为溢出被丢弃的是一条资源记录而内存撑爆是整个扩展不可用。Chrome 与 Firefox一份代码两套 manifest猫抓的 Firefox 适配策略是能兼容就兼容不能兼容就换 manifest而不是做运行时 API 桥接层。两份入口配置对比能力ChromiumFirefox降级方案background 加载MV3 service_workerMV2background.scripts见 manifest.firefox.jsonFirefox 直接脚本加载background.js开头用typeof G undefined判断是否重复加载侧边栏 sidePanel支持Chromium 1142.6.3 修了低版本无法安装的问题不支持回退到 popup / 弹出新窗口两种模式storage.session支持104不支持回退storage.local注入类脚本深度搜索/录制全版本128 才开放2.5.7低版本隐藏入口blob url 下载m3u8 切片正常曾无法下载2.7.0 修复无只能修2.5.7 让 Firefox 也升到 MV3 结构但保留了 V2 式的 scripts 加载方式——因为 Firefox 的 MV3 background 当时同样受限与其等 Firefox 补齐不如自己选更可控的加载路径。Chromium 侧的最低版本 93 写死在 manifest 的minimum_chrome_version低于 102/114 的功能靠运行时检测隐藏按钮。多端适配的结论是差异写在构建产物manifest层而不是 if-else 层这样每个分支的行为可以单独验证。图Edge 等 Chromium 系浏览器的安装引导走同一套 MV3 manifest安全与隐私只做了三件低成本的事猫抓不声称有体系化安全架构实际投入集中在三个具体问题上问题方案位置注入的 UI 被页面 CSPTrusted Types拦截运行时探测先试写innerHTML失败再创建catCatchPolicy策略都不行就跳过catch-script/catch.js部分网站不希望被嗅探屏蔽列表可白名单模式2.6.5 加全局强制屏蔽列表background 的blockUrlSet扩展页面自身显式声明script-src self; object-src selfCSPmanifestTrusted Types 那段探测逻辑值得看一眼它的姿态// 先试探页面是否开启 Trusted Types未开启则直接透传 try { const fakeDiv document.createElement(div); fakeDiv.innerHTML string; createHTML (string) string; } catch (e) { /* 页面开启时创建 policy 拦截 innerHTML 赋值 */ }这是典型的探测优先写法不预设环境先试一次再决定路径。隐私侧的边界更简单——数据只存本地 storageMQTT、aria2 RPC、数据发送这些出站能力全部是用户手动配置的目标地址扩展不内置任何上报端点。安全投入与嗅探工具的实际风险匹配页面会杀你的 UI但不会偷你的数据。版本演进与选型逻辑六个关键节点回看版本关键变化为什么这么选1.0.24HeartBeat 首次加入MV3 转型期最小代价止血先让扩展可用2.0.0Worker 被杀后 500ms 自唤醒视频主动捕获接受保活会失败把重心挪到恢复速度被动嗅探拿不到的源主动抓2.2.2解析器换 hls.js下载器与解析器分离自研解析的 bug 面太大引入成熟库分离后两者可独立迭代2.4.7下载线程固定 6放弃动态调度换取异常恢复的确定性2.5.3 / 2.5.9storage.session9999 条上限 屏蔽列表用存储层换 IO 错误率用硬上限换内存下界2.6.2 / 2.6.8侧边栏模式EXT-X-BYTERANGE 支持侧边栏是体验升级但绑定 Chromium 114故做成可选BYTERANGE 是长尾 M3U8 结构不做就覆盖不了收束成四条判断恢复优先于保活。与其花力气让 Worker 永不休眠不如让被杀后的复活路径短到 500ms。阈值是防溢出用的不是优化用的。9999、6 线程、500 条这些数字的取值逻辑都是超过就坏而非超过就慢。浏览器差异写进 manifest不写进代码。运行时 if-else 分支会随版本腐烂双 manifest 则每个分支独立可测。第三方库只引入不重造。hls.js、mux、mpd-parser 全部走 lib/ 现成方案自研集中在扩展特有的嗅探与调度层。这套取舍的共同点是每个决定都优先保证坏了能恢复、能关掉、能回退功能扩张始终排在稳定性之后。对于同样要跨浏览器、跨版本长期维护的扩展项目这个顺序本身比任何单个方案都值得借鉴。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考