企业官网建设流程全解析

猫抓 Cat-Catch 资源嗅探扩展完整指南：5 步拿下页面不让你下载的视频

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

视频页面右键菜单被拦截、下载按钮消失，打开开发者工具也只见一堆零散的 .ts 分片——这个时候，开源的资源嗅探扩展猫抓（Cat-Catch）能帮你。它不需要你复制任何地址，浏览页面时就会把每一个媒体请求悄悄记下来，最终把视频、m3u8 流和图片直接交到你手里。

一句话原理：凭什么页面拦不住它

猫抓不破解任何页面的防御，它只是在浏览器的网络层和媒体层各装了一个"记录仪"，把页面真实发出的请求和真正喂给播放器的数据流原样还原出来。网站能挡住你的鼠标，但挡不住浏览器自己发出的请求。

围绕这个机制，它的核心能力可以列成一张清单：

• 被动嗅探：自动列出页面加载的媒体文件
• 主动捕获：代理 MediaSource 还原动态分片
• m3u8 解析：识别密钥、多线程下载、合并转码
• 协议覆盖：HLS、DASH、WebRTC、普通 HTTP 全收
• 下载器对接：Aria2 RPC、m3u8dl:// 协议、在线 ffmpeg
• 多语言界面：内置十种语言，界面跟着你的浏览器走

跟着做一遍：五分钟完成首次下载

第一次使用不需要任何代码基础，五步走完：

1. 在 Chrome 网上应用店或 Edge 插件商店搜索"Cat-Catch"安装（Firefox 版也支持）
2. 打开一个正在播放视频的页面，点一下工具栏的猫爪图标
3. 弹出面板里按类型、大小筛选当前页面捕获到的资源，支持正则匹配
4. 勾选目标文件，点下载，文件直接进你的下载目录
5. 如果捕获到的是 m3u8 播放列表，点 m3u8 解析器入口，设置线程数与输出格式后再启动下载

想读源码的读者，仓库在这里，四条主线就是四个入口：

git clone https://gitcode.com/GitHub_Trending/ca/cat-catch

• 嗅探与捕获核心：catch-script/catch.js
• m3u8 解析器：js/m3u8.js
• 后台调度与心跳：js/background.js
• 下载逻辑：js/downloader.js

拆开看原理：一只耳朵听请求，一只眼睛盯画面

可以这么理解它的两条捕获通道：耳朵挂在浏览器的网络请求接口webRequest上，页面每发一个请求，后台就检查一遍Content-Type和 URL 是否像媒体文件，像就记进当前标签页的资源列表——静态的 mp4、音频、图片大多在这一步被抓住；眼睛则盯住播放器本身，页面里的MediaSource相关方法被注入脚本重写，每次往播放器里追加一段分片数据都会被记录下来，等于把"边播边扔"的流媒体重新攒回完整文件。

各模块分工大致是这样：

猫抓的资源捕获链路 ├── js/background.js webRequest 请求监听，记录媒体 URL，心跳保活 ├── catch-script/catch.js 代理 MediaSource/appendBuffer，记录分片，悬浮面板 UI ├── catch-script/search.js 深度搜索，从页面 JS 里挖出疑似密钥 ├── catch-script/recorder.js、webrtc.js 录制脚本，覆盖动态流与 WebRTC 流 └── js/m3u8.js m3u8 解析、密钥处理、多线程合并下载

两条通道各管一半：只靠耳朵，走 MediaSource 的动态视频一个都看不见；只靠眼睛，静态直链又抓不到。对普通用户来说，你不用关心视频走的是哪条路，面板里出现的就都是能下载的。💡

进阶场景：当视频变成几百个 m3u8 分片

难点：直播或平台分发场景下，页面里往往只有一个.m3u8文件。它不含任何视频数据，只是一份"菜单"，列出几十到上千个.ts分片地址，还常用 AES-128 声明密钥；更糟的是，这类播放列表地址常常几分钟就失效，直接拿地址去下载，十有八九 404。

解法：猫抓的 m3u8 解析器（2.2.2 起基于 hls.js 内核重写）按三步走——拉取并校验播放列表、读取时长分辨率与密钥信息；密钥从页面深度搜索脚本 catch-script/search.js 里挖，也支持你手动上传 Key 文件、填十六进制或 base64；最后并发下载分片、合并输出，还能转成 mp4。

关键细节：两个地方最容易被忽略。一是Referer请求头——很多站点校验请求来源，裸地址下载会被拒，猫抓会把来源页的 Referer 和自定义请求头一并带下去；二是缓存直读，2.7.0 版本开始解析器可以直接从浏览器缓存里读出 m3u8 内容，专门对付"一次性 URL"这种每次访问都换地址的场景。

工程取舍：两次真实决策的代价与回报

决策一：把下载线程钉死在 6 个（2.4.7 版本）。问题：线程越多下载越快，但对目标站点压力也越大，社区早有把别人网站压垮的争议。选择：把最大下载线程调整并限制为 6，不给用户"拉满"的选项。代价：极限网速场景下牺牲了一部分峰值速度。回报：默认行为对服务器更温和，"下载体验"和"不把对方搞崩"被放在同一优先级——对你意味着不用自己权衡，开箱就是安全的默认值。

决策二：存储从 local 换成 session（2.5.3 版本）。问题：storage.local在高频读写下出现过 IO 错误，严重时会直接拖垮整个扩展。选择：整体迁到storage.session，代价是要求 Chrome 104 以上。代价：会话级存储随浏览器会话走，不再跨重启持久化，需要持久配置的用户得用导入/导出。回报：高频场景下扩展在各种低配置机器上都站得住，更新日志里只用了简短一句"减少 IO 错误导致扩展无法使用"，但效果是实打实的稳定。

类似的"对抗"还有 Service Worker 休眠：MV3 的后台空闲即被杀，从 1.0.24 引入 Heart Beat 心跳保持存活，到 2.0.0 更新日志里维护者甚至直白地写下——"该死的 Service Worker... 现在后台被杀死能立刻唤醒自己... 继续用肮脏的手段对抗 Manifest V3"。这种坦白在开源项目里不多见。

猫抓版本演进表：关键节点与解决的真实问题

写在最后

猫抓解决的根本问题只有一句话：在浏览器允许的安全边界内，把"网页上正在播的媒体"变成"你自己硬盘上的文件"。而它留下的开放问题也同样清晰——当更多平台把密钥挪进 DRM 保护或服务端签名之后，"在浏览器里嗅探"这条路能走多远？猫抓给出的方向或许已经藏在 catch-script/recorder.js 这类脚本和 MQTT 推送里：让浏览器只是媒体流水线上的一个车间，而不是终点站。🚀

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