猫抓Cat-Catch浏览器资源嗅探扩展架构解读：从双击图标到触达媒体流的6000行代码-开发者社区

猫抓Cat-Catch浏览器资源嗅探扩展架构解读：从双击图标到触达媒体流的6000行代码

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

猫抓Cat-Catch是一款开源的浏览器资源嗅探扩展，它把"网页里正在播放的视频到底藏在哪"这个问题，拆解成了一套可嗅探、可解析、可下载、可转码的完整技术链路。读完这篇文章，你将理解一个扩展如何在不拥有任何服务器的情况下，用约六千行JavaScript完成专业媒体处理，以及它在每个关键节点上的取舍逻辑。

开篇场景：一次真实的视频下载遭遇战

你在某个视频网站点开一部影片，播放器正常出画，但开发者工具的网络面板里翻不到任何.mp4结尾的链接——数据被切成几百个几十KB的分片，通过 HLS 协议（HTTP Live Streaming，苹果提出的流媒体传输协议，把视频切成小分片顺序传输）动态加载。此刻若打开猫抓的弹出面板，看到的却是分片地址、切片数量、加密标记、甚至可能的密钥，点一下"解析"，一个独立页面开始逐片下载并合并输出完整文件。

这个从"浏览器黑盒"到"结构化媒体信息"的转变，靠的不是魔法，而是三套并行工作的探测机制。

三层探测机制：同一份媒体，三双眼睛盯着

猫抓的嗅探策略不是单一技术，而是三条互补的探测路径同时运行：

第一层，网络请求监听。基于webRequestAPI（浏览器提供给扩展的网络请求拦截接口），在onSendHeaders和onResponseStarted两个时机捕获请求信息。选择"响应开始"而非"响应结束"作为判断点，是为了用最早的响应头拿到 Content-Type、Content-Length，尽早判断资源类型。

第二层，MediaSource 方法代理。现代播放器大多通过 MediaSource API（浏览器提供的可编程媒体缓冲接口）把分片喂给<video>标签。猫抓在页面注入脚本，改写其addSourceBuffer、appendBuffer等方法，凡是流入播放器的数据都被旁路拷贝一份——这正是它能抓到"URL 不断变化的一次性 m3u8 地址"的根本原因。

第三层，深度搜索脚本。对应 catch-script/search.js 中的实现：劫持JSON.parse与Worker构造器，遍历页面脚本解析过的每一个数据对象，再用正则提取疑似密钥。这里有个容易被忽视的工程细节——脚本会先探测当前环境是否支持 Blob Worker，再决定是否对Worker做包装，说明作者对跨浏览器行为差异有充分预案。

三条路径各司其职：请求监听负责广度，MediaSource 代理负责深度，深度搜索负责"掘地三尺"。代价是代码复杂度显著上升——catch.js一个文件就接近千行，且每一条路径都要单独处理 iframe、沙盒、跨域等边界情况。

存储方案的反复：为什么最终放弃了 storage.local

这是项目演进中最典型的一次"先犯错再纠正"。早期版本用chrome.storage.local持久化捕获数据，理论上配置永不丢失，但实际运行中频繁遭遇 IO 错误——扩展在浏览器重启后直接白屏不可用。原因在于扩展的存储写入没有流量控制，高频次的写入请求在磁盘压力大时极易失败。

2.5.3 版本做出的决定是：改用storage.session（会话级存储，数据在浏览器关闭后清空）。权衡很清楚：

收益：存储操作更稳定，扩展不再因 IO 错误崩溃，这是可用性红线；
代价：数据不持久，浏览器关闭后嗅探记录丢失。

为了尽量弥补，代码里做了双重保障——chrome.storage.session ?? chrome.storage.local的降级写法兼容低版本浏览器，同时用chrome.alarms定时任务周期性把内存缓存写回存储。这是"稳定性优先于持久性"的典型取舍：一个嗅探工具的核心价值是"此刻能用"，而不是"历史全在"。

M3U8 解析器：一条从嗅探到生产的完整流水线

M3U8 解析器是猫抓最重的功能模块，对应 js/m3u8.js（约2400行）。它借用了 hls.js 的解析能力作为前端入口，但真正的重活在自己手里：

多级 playlist 处理：支持 master playlist 嵌套子 playlist，自动递归解析；
AES-128 解密：内置从 hls.js 分离出的AESDecryptor，密钥从keyContent缓存中读取，配合深度搜索得到的"疑似密钥"集合做验证；
MP4 转封装：通过 mux.js 完成 TS 到 MP4 的转换，支持 HEVC/H265；
分片级控制：2.6.8 版本起支持点选任意切片合并下载，2.6.x 版本增加了EXT-X-BYTERANGE（字节范围分片）的支持。

下载线程数在 2.4.7 版本被定为 6，这是实测后的经验值——线程太多会触发服务器限流导致频繁失败，太少则带宽利用率不足。值得注意的是，下载失败自动重试机制（2.7.1 版本）比盲目加大并发更能提升成功率，这也是"用重试换成功率"而非"用并发换速度"的务实选择。

图注：解析器页面同时承载切片列表、下载进度、加密状态与 ffmpeg 转码开关，一个页面完成了传统桌面下载工具的全部工作。

直播录制的另类实现：缓存捕获与 WebRTC 接管

猫抓还提供了两条非常规路径。其一是"缓存捕获"：不拦截网络，而是直接抓取视频元素当前缓冲区的数据，配合"自动跳转缓冲尾"选项，能对直播流做持续录制，绕过了直播 URL 不断变化的难题。其二是 catch-script/webrtc.js，通过接管RTCPeerConnection的addTrack事件捕获 WebRTC（网页实时通信技术）流——这是浏览器中私密性最高、常规嗅探完全无能为力的媒体来源。

国际化与工程协作：一个社区驱动的小型生态

2.5.0 版本引入的多语言体系，走的是典型的开源社区路线：_locales/目录下每个语言一个messages.json，全部通过chrome.i18n动态加载，支持回退到默认语言。工具目录下的 tools/sync-locales.js 承担了关键工程职责——它读取英文文件作为基准，自动为每个语言文件补齐缺失键、移除废弃键，保证社区翻译永远不拖垮代码。截至 2.7.2 版本，项目已覆盖中、英、日、韩、西、俄、葡、越、土等十种语言，且每个版本都附带了贡献者名单，翻译成本被压低到"只要会自己的母语就能参与"的程度。

诚实的技术反思：限制与未解问题

猫抓的成就建立在承认限制之上。Service Worker（Manifest V3 中扩展的后台脚本，生命周期短且频繁休眠）是最大的敌人——Chromium 会在空闲约5分钟后强制终止它，所以 js/background.js 里通过chrome.webNavigation事件触发保活，并设计了HeartBeat心跳通道和 500ms 的初始化重试队列，防止 Worker 被唤醒后全局变量尚未就绪就处理请求。

未解决的问题同样存在：深度搜索的密钥命中率依赖正则覆盖的广度，存在漏判；在线 ffmpeg 转码依赖第三方服务，2.6.8 版本至今仍标注"测试中"；持续录制对内存的消耗没有上限控制。这些写在 CHANGELOG 里的"测试中""beta"标记，本身就是工程诚实度的体现。