猫抓Cat-Catch技术架构深度解析一款浏览器扩展如何把自己炼成媒体处理平台【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch凌晨两点Chrome的Service Worker刚刚被系统杀死一个正在下载的视频任务瞬间中断。这不是个例——这是所有现代浏览器扩展开发者都绕不过的坎。而有一款叫**猫抓Cat-Catch**的开源浏览器资源嗅探扩展偏偏要在这种环境下把自己从能看见网页资源的放大镜进化成能解析、能下载、能转码、能录制的媒体处理平台。这篇文章不讲功能列表而是沿着它最艰难的三个技术抉择看看一个团队如何在浏览器划定的安全边界内一点点把不可能变成能做到。一张地图先看清它到底建了什么在进入细节前先用一张文字版架构地图建立整体认知。猫抓的运行体系分三层各管一摊┌─ 捕获层驻留在每个网页里的哨兵 │ js/content-script.js ── 页面注入入口 │ catch-script/catch.js ── CatCatcher 嗅探引擎webRequest MediaSource 代理 iframe 处理 │ catch-script/recorder.js ── 页面内录制器 │ catch-script/search.js ── 深度搜索探测疑似密钥/资源 │ ├─ 调度层后台 Service WorkerChrome 里叫 background service worker │ js/background.js ── 请求监听、数据聚合、心跳保活、存储调度 │ └─ 处理层独立页面 工具链 m3u8.html / mpd.html ── 流媒体解析与切片下载 downloader.html ── 通用下载器 popup.html ── 资源面板 / 侧边栏三层之间靠chrome.runtime消息、chrome.storage和webRequest事件通信。听起来规整但真正有故事的是这三层没有一层是应得的全是跟浏览器搏斗后捡回来的。第一战给随时可能断气的后台进程装上心脏起搏器Manifest V3浏览器扩展的新一代规范最狠的改动是把传统常驻后台页面换成了 Service Worker——一个用不了多久就会被系统回收的脚本进程。Chrome 给出的官方说辞是省内存但对猫抓这种需要持续监听网络请求的扩展来说这几乎是釜底抽薪Worker 一睡嗅探就断。猫抓没有坐以待毙而是做了一套心跳保活Heart Beat机制。原理不复杂既然系统会在空闲一段时间后杀进程那就制造不空闲的假象。// js/background.js 中的保活逻辑节选 chrome.webNavigation.onBeforeNavigate.addListener(function () { return; }); chrome.webNavigation.onHistoryStateUpdated.addListener(function () { return; }); setInterval(chrome.runtime.getPlatformInfo, 25 * 1000);页面导航事件被注册为空监听定时器每隔25秒调用一次系统 API。两者配合让 Chrome 认为 Worker有事在做从而延长存活时间。同时配合一个特殊的 HeartBeat 连接在极端情况下维持长连接。但这只是延缓死亡不是杜绝死亡。所以代码里还有第二道保险// Service Worker 被杀死后重新唤醒时等全局变量初始化完成再干活 if (!G || !G.initSyncComplete || !G.initLocalComplete || G.tabId undefined) { setTimeout(() findMedia(data, isRegex, filter, true), 500); }被杀死后重启先自检全局状态没就绪就延迟重试。这套尽力存活 醒来自检的组合拳是猫抓所有功能能稳定运行的地基。它教会我们的第一课是在平台限制面前与其抱怨不如把进程可能随时消失当作默认假设来编程。第二战网页里藏的资源凭什么都能被你看见嗅探一个视频文件最简单粗暴的方式是拦截所有网络请求看 URL 是不是.mp4、.ts。但今天的视频网站早就不这么玩了加密切片、动态加载、Blob URL、MediaSource 实时投喂……光靠看 URL根本抓不到。猫抓选择了混合嗅探相当于在网页里埋了三种探测器各管一段探测器手段覆盖场景网络层webRequest.onSendHeadersonResponseStarted双监听常规媒体 URL、带自定义头的请求运行时层重写MediaSource/URL.createObjectURL等方法Blob 流、动态投喂的视频缓冲页面层MutationObserver监控动态插入的 iframe沙盒 iframe 里加载的媒体关键点在网络层它不像早期版本那样只挂在onBeforeRequest上而是在请求发出前onSendHeaders和响应开始后onResponseStarted各看一眼。为什么要看两次因为看到 URL不等于知道它是不是媒体——onSendHeaders 阶段能拿到完整请求头含 Referer、自定义头这些后续下载要用onResponseStarted 阶段能拿到响应头此时 Content-Type 才见分晓。两个阶段的数据拼起来才构成一次完整判断。// 保存请求头供响应阶段使用 chrome.webRequest.onSendHeaders.addListener(function (data) { G.requestHeaders.set(data.requestId, data.requestHeaders); try { findMedia(data, true); } catch (e) { console.log(e); } }, { urls: [all_urls] }, [requestHeaders, ...]); // 收到响应头后再做最终判定 chrome.webRequest.onResponseStarted.addListener(function (data) { data.allRequestHeaders G.requestHeaders.get(data.requestId); G.requestHeaders.delete(data.requestId); // 用完即删防内存泄漏 findMedia(data); }, { urls: [all_urls] }, [responseHeaders]);一个容易忽视的细节requestHeaders用 Map 暂存、响应一到就 delete。因为一次页面会话可能产生几千个请求如果只存不删内存早晚被拖垮。用完后立刻清理这是长驻脚本的生存基本功。而 iframe 那一支同样有讲究。很多网站用sandbox属性隔离子页面导致注入脚本失效。猫抓的处理是克隆 iframe 节点、摘掉 sandbox、再替换回去并用 MutationObserver 盯着后续动态插入的 iframe。这个克隆替换不是炫技——直接改属性在某些浏览器里不生效克隆重插是实测最稳的路子对应 issue #576。第三战M3U8 解析器一台被塞进网页的小型流水线如果说嗅探是看见那么 M3U8 解析器就是把看见的东西完整拿到手。M3U8 是流媒体视频的目录文件里面列着几十上百个.ts切片和加密信息。猫抓的解析器m3u8.html 页面本质是一条流水线拉取 m3u8 清单 → hls.js 解析出切片列表 → 检测 AES-128 密钥 → 并发下载切片 → 解密 → 合并内置转码器或发送到 ffmpeg→ 落盘有四个设计点特别值得说其一直接复用 hls.js。猫抓没有自己写一套 M3U8 解析器而是把播放器领域的成熟库拿来做解析引擎。这是典型的不重复造轮子——解析清单是难点但不是卖点把精力留给下载调度和兼容性。其二AES-128 解密就地完成。代码里有一行const decryptor new AESDecryptor()这个类是从 hls.js 里剥离出来的。下载到加密切片后直接在浏览器里解密再合并用户拿到的就是能直接播放的文件。而密钥从哪来它会在网络请求里收集疑似密钥possibleKeys并提供验证功能——毕竟有些站点的密钥藏得很深。其三并发数不是拍脑袋定的。团队把最大下载线程调成 6背后是对网络生态的权衡并发太低大视频下载慢得让人抓狂并发太高容易被目标服务器当攻击封禁也不体面。6 是一个经过大量用户反馈验证的平衡点。这体现了一个判断——工具的下载体验不能建立在伤害他人服务器的基础上。其四能降级、能外送。切片合并支持本地内置转码也支持发送到在线 ffmpeg、m3u8dl 等外部工具甚至支持 MQTT 协议推送到远端下载器。这意味着用户在浏览器内解决和交给专业工具之间可以自由选择架构上留了后门产品上给了选择权。M3U8 解析器界面与切片下载进度来源README/m3u8.png踩过的坑那些被放弃的方案同样是财富一篇文章只讲我们做得多对是骗人的。猫抓的 CHANGELOG 里藏着大量此路不通的记录挑三个最典型的storage.local 被放弃。按直觉配置和捕获数据应该存storage.local持久化。但团队最终选了storage.session会话级作为主存储代码里到处是chrome.storage.session ?? chrome.storage.local的兼容写法。原因很现实local 存储有 IO 失败风险且数据跨会话残留容易把内存/磁盘拖爆限制每页面最大 9999 条资源就是为此。他们用配置可能丢失的代价换来了扩展永远不崩的底线。这是取舍不是缺陷。sandbox iframe 直接改属性无效。早期版本试图遍历 iframe 修改 sandbox 属性结果在部分站点失效视频就是抓不到。后来改成克隆节点→去属性→替换配合 MutationObserver 覆盖动态创建的场景才解决。这个坑说明页面环境远比想象复杂脚本必须对 DOM 的不可控性有敬畏。Firefox 兼容是一条持续十年的战线。猫抓同时维护manifest.json和manifest.firefox.json两套清单Chrome 用 service_workerFirefox 用 background.scripts 数组加载同一批脚本。光是Firefox 无法使用录制脚本Firefox 在线 ffmpeg 传不了文件这类问题CHANGELOG 里就修了不下十次。跨浏览器不是写一次到处跑而是每处都单独验证。它留下的三句话回看猫抓Cat-Catch的全部技术决策可以浓缩成三句话这也是它最值得带走的经验限制不是障碍是设计约束。没有 MV3 的进程回收就不会有心跳保活和醒来自检没有存储风险就不会逼出 session 优先的取舍。每一个被迫的妥协最后都变成了架构上的亮点。嗅探是入口闭环才是平台。单看任何一个模块——webRequest 拦截、hls.js 解析、StreamSaver 落盘——都不是新鲜事。新鲜的是它们被捏合成一条完整流水线让看见资源到拿到文件之间没有断点。用户体验是唯一不可妥协的北极星。并发调到 6、切片手动勾选、下载失败自动重试、多语言社区翻译……这些细节单拎出来都不起眼合在一起才成就了一款被全球用户信任的工具。至于未来项目已经在为 AI 增强和云原生留接口深度搜索脚本已能自动分析疑似密钥MQTT 支持为浏览器嗅探 远程下载的云边协同埋了伏笔。也许有一天猫抓不再只是浏览器里的下载器而会变成你个人媒体管道的第一公里。到那时回看今天这套在限制中创造的方法论依然是最值钱的部分。如果你也想从源码层面理解这套架构核心逻辑分别在 js/background.js心跳与调度、catch-script/catch.js嗅探引擎、js/m3u8.js流媒体解析里每一处注释都写满了为什么。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考