技术架构深度解析猫抓Cat-Catch如何在浏览器限制下重构媒体处理管线【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch深夜调试一个视频站点network 面板里几十个.ts分片不断刷新。你装上资源嗅探扩展却发现只要切换标签页或在后台静置几分钟下载队列就冻结了——Chrome 会回收扩展的 Service Worker内存里的请求头、分片列表一并蒸发。**猫抓cat-catch**正是为解决这类问题而生的浏览器资源嗅探扩展它把嗅到资源延伸为完整交付识别、过滤、解析、下载、转封装在浏览器安全模型的重重限制下搭起一条完整的媒体处理管线。开场当 Service Worker 在下载中途睡去 ⚙️Manifest V3 把所有后台逻辑赶进了 Service Worker而它的生命周期由浏览器裁决空闲即回收事件驱动唤醒。这意味着所有状态都必须可重建——猫抓的background.js第一段注释就写着Service Worker 5 分钟后会强制终止扩展并链接到 Chromium 的 issue 记录。对嗅探扩展来说这不是性能问题而是数据完整性问题webRequest回调里捕获的请求头、正在排队的媒体列表、按 tab 划分的缓存都是纯内存态。浏览器一回收它们全部归零。猫抓的架构价值不在于某个炫技特性而在于它把随时可能被杀死作为默认前提设计了整套保活、落盘与重建机制——这是理解全部代码的一把钥匙。需求的显微镜把能下载拆成一张问题清单能下载视频在真实场景里是一组性质完全不同的问题。猫抓的需求拆分可以画成一张清单需求类型判断依据嗅到页面上的任意媒体资源刚需扩展存在的唯一理由覆盖率决定口碑下载时保留 referer / cookie / token刚需大量站点鉴权后才返回媒体裸 URL 下载必 403动态加载、加密的 m3u8 流痛点页面脚本运行时才发起请求且分片常带 AES-128 加密大文件不占满内存痛点长视频分片总量大内存态缓存必然爆掉做成完整视频管理库伪需求浏览器扩展的内存与生命周期撑不起属于越界猫抓的选择是识别优先、交付可控嗅探端做高覆盖交付端把复杂留给自己。于是出现了onSendHeaders与onResponseStarted双阶段监听——前者截获请求头含鉴权信息后者拿到响应头content-type、content-length、content-disposition判断这是不是媒体两阶段合并才得到一个可以完整复现下载的请求快照。这张快照就是后续一切功能的数据底座。图扩展弹出界面把捕获→预览→下载收进一个面板嗅探只是第一步交付才是终点方案的角力场存储、保活与嗅探的三场权衡 ⚖️存储策略session 优先、local 兜底而不是二选一代码里反复出现一行降级链chrome.storage.session ?? chrome.storage.local。这不是偷懒而是一场精确的权衡方案优势代价结论纯storage.local持久、跨会话高频写入有 IO 错误风险无内存态快放弃纯storage.session内存级速度无 IO 压力Firefox 与低版本 Chromium 不支持扩展重载即丢放弃session 优先 local 兜底快的地方快稳的地方稳需要重建逻辑采用关键洞察是session 丢数据不可怕可怕的是丢得不明不白。猫抓配合防抖批量写——单 tab 积压 100 条或距上次写入超 500ms 时延后 2 秒或 5 秒才落盘一次单 tab 数据超过 99 条干脆不再写 storage只在内存中维护。存储在这里被降级为可丢失的镜像真正的数据活在 Service Worker 内存里。保活机制三路冗余对抗生命周期裁决MV3 禁止持久后台页后猫抓选择了三种策略叠加策略原理局限webNavigation空监听每次导航重置 Service Worker 空闲时钟只对导航事件生效onConnect心跳 Portcontent script 建立命名端口后台 250 秒后主动断开反复拉长生命周期需要页面侧配合是业界知名 hacksetInterval(getPlatformInfo, 25s)周期性 API 调用维持活跃依赖实现细节未来可能失效这套保活组合拳的哲学是不赌单一机制。每个方案都可能被浏览器更新击穿但三条路同时失效的概率极低。这也解释了为什么background.js顶部同时挂着空监听、Port 心跳和定时器——它们是同一需求的三份保险。嗅探策略webRequest 为主declarativeNetRequest 为辅为什么不全面转向 Manifest V3 力推的declarativeNetRequestdNR因为它只能改请求、读不到响应头、也拿不到请求体——而猫抓判断资源靠的恰恰是响应头。dNR 的用武之地在另一处模拟手机 UA。updateSessionRules按 tab 动态注入modifyHeaders规则把一个标签页的 UA 全局替换为移动端这是 dNR 的舒适区。嗅探用 webRequest 拿数据篡改用 dNR 免权限各取所长。实现的解剖室从请求头到下载器的四段流水线 把background.js的findMedia展开是一条边界清晰的处理流水线捕获 → 过滤 → 入缓存 → 交付 │ │ │ │ │ │ │ └── downloader.html / m3u8.htmlStreamSaver / 在线ffmpeg │ │ └── 查重 防抖落盘 角标数字 │ └── CheckExtension / CheckType / 正则黑名单 └── onSendHeaders请求头 onResponseStarted响应头过滤阶段最能体现约束前置的设计。CheckExtension与CheckType都接受操作符 数值的大小条件如100 KB、500-1000 MB把用户的过滤意图编译成一次判定// 根据响应头 content-type 匹配类型表支持通配 audio/* 与大小表达式 function CheckType(dataType, dataSize) { const typeInfo G.Type.get(dataType.split(/)[0] /*) || G.Type.get(dataType); if (!typeInfo) return false; // 未配置的类型直接放行 if (!typeInfo.state) return break; // 用户关闭的类型提前中断 if (typeInfo.size ! 0 dataSize ! undefined !operatorCheck(dataSize, typeInfo)) return break; return true; }模块之间的协作关系值得注意background.js只做编排不碰页面 DOM页面内的捕获交给catch-script/catch.js的CatCatcher类它注入 MAIN world代理MediaSource方法、用 MutationObserver 监听动态插入的 iframe甚至为了兼容会克隆 iframe 并移除sandbox属性对应 issue #576——嗅探端与交付端通过runtime.sendMessage的addMedia消息对接background.js只认 URL 与请求头不关心是谁发现的。M3U8 解析器是交付端的集大成者用 hls.js 解析清单用从 hls.js 中分离出的AESDecryptor解密分片用 StreamSaver 边下边存可选的在线 ffmpeg 以嵌套 iframe 方式完成转封装。默认下载线程数为 6G.M3u8Thread: 6这个数字是分片数量、磁盘 IO、目标站点负载之间的经验平衡点——线程太少喂不饱带宽太多则大概率被站点风控6 是猫抓长期验证后的取值。图M3U8 解析器界面暴露了完整的技术面——分片列表、密钥/IV、线程数与下载范围全部可调国际化用工具链锁住社区协作_locales/下已有 10 种语言贡献者来自 changelog 各处署名。真正的工程智慧在tools/sync-locales.js以英文为基准为缺失 key 的语言文件自动填充英文占位保证任何语言在任何版本都不缺 key。翻译者无需理解架构维护者不必手动同步这降低了开源协作的隐性门槛。踩坑实录以版本号为刻度的一路修复把 changelog 当技术日志读能看到真实的失败与纠正iframe 沙箱吞掉捕获sandbox属性隔离了脚本MediaSource 代理失效最终用克隆节点移除属性的方式绕过issue #576一次性 URL难题部分站点生成的 m3u8 地址仅对单次请求有效2.7.0 改为从扩展缓存中直接读取 m3u8 内容再解析绕开地址时效BYTERANGE 分片2.6.8 支持EXT-X-BYTERANGE标签合并下载补齐了非标准切片的覆盖下载失败率高2.7.1 引入自动重试用成功率换取用户耐心在线 ffmpeg 文件丢失从新开标签改为嵌套 iframe模式2.6.8解决跨标签通信的偶发失败Firefox 的差异化storage.session缺失、blob URL 下载、录制脚本兼容都需要分支处理——跨浏览器从来不是口号而是一行行G.isFirefox。这些修复的共同特征是都在模块内部完成改catch.js不动background.js改 m3u8 解析器不影响嗅探引擎。渐进式演进在这里不是理念而是模块边界带来的自然结果。启发的搬运工三条可迁移原则与理性展望 原则一把平台的限制当成接口而不是边界。存储降级链、三路保活、双阶段嗅探都是在限制不可绕过的前提下设计出的方案。任何扩展项目都该先问我的 Service Worker 被杀死后用户会失去什么原则二用内存为主、落盘为镜的缓存模型应对配额与性能。高频数据留在内存storage 只做低频镜像配合防抖与阈值99 条内写盘、超过 9999 条清空控制写入成本。浏览器扩展的内存策略本质是可重建状态的设计。原则三用注入式脚本换取功能的热插拔。catch.js、search.js按需注入、随时移除、独立 i18n让深度搜索这类高风险脚本可以在出问题时单独回滚。松散耦合换来的是可运维性。理性的展望同样重要猫抓在浏览器内已经触到能力上限——MV3 下 dNR 对 webRequest 的逐步收紧、大文件受限于downloadsAPI 与内存模型、跨浏览器行为差异永远存在。它的下一步如果走向 AI 辅助识别或云端协同必须先回答Service Worker 生命周期这个老问题在新场景下的新版本。但正因如此这套围绕限制建立的架构才值得反复研读它证明了真正可用的技术方案从来不是对限制的规避而是与限制的共处。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 技术架构深度解析：猫抓Cat-Catch如何在浏览器限制下重构媒体处理管线
技术架构深度解析猫抓Cat-Catch如何在浏览器限制下重构媒体处理管线【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch深夜调试一个视频站点network 面板里几十个.ts分片不断刷新。你装上资源嗅探扩展却发现只要切换标签页或在后台静置几分钟下载队列就冻结了——Chrome 会回收扩展的 Service Worker内存里的请求头、分片列表一并蒸发。**猫抓cat-catch**正是为解决这类问题而生的浏览器资源嗅探扩展它把嗅到资源延伸为完整交付识别、过滤、解析、下载、转封装在浏览器安全模型的重重限制下搭起一条完整的媒体处理管线。开场当 Service Worker 在下载中途睡去 ⚙️Manifest V3 把所有后台逻辑赶进了 Service Worker而它的生命周期由浏览器裁决空闲即回收事件驱动唤醒。这意味着所有状态都必须可重建——猫抓的background.js第一段注释就写着Service Worker 5 分钟后会强制终止扩展并链接到 Chromium 的 issue 记录。对嗅探扩展来说这不是性能问题而是数据完整性问题webRequest回调里捕获的请求头、正在排队的媒体列表、按 tab 划分的缓存都是纯内存态。浏览器一回收它们全部归零。猫抓的架构价值不在于某个炫技特性而在于它把随时可能被杀死作为默认前提设计了整套保活、落盘与重建机制——这是理解全部代码的一把钥匙。需求的显微镜把能下载拆成一张问题清单能下载视频在真实场景里是一组性质完全不同的问题。猫抓的需求拆分可以画成一张清单需求类型判断依据嗅到页面上的任意媒体资源刚需扩展存在的唯一理由覆盖率决定口碑下载时保留 referer / cookie / token刚需大量站点鉴权后才返回媒体裸 URL 下载必 403动态加载、加密的 m3u8 流痛点页面脚本运行时才发起请求且分片常带 AES-128 加密大文件不占满内存痛点长视频分片总量大内存态缓存必然爆掉做成完整视频管理库伪需求浏览器扩展的内存与生命周期撑不起属于越界猫抓的选择是识别优先、交付可控嗅探端做高覆盖交付端把复杂留给自己。于是出现了onSendHeaders与onResponseStarted双阶段监听——前者截获请求头含鉴权信息后者拿到响应头content-type、content-length、content-disposition判断这是不是媒体两阶段合并才得到一个可以完整复现下载的请求快照。这张快照就是后续一切功能的数据底座。图扩展弹出界面把捕获→预览→下载收进一个面板嗅探只是第一步交付才是终点方案的角力场存储、保活与嗅探的三场权衡 ⚖️存储策略session 优先、local 兜底而不是二选一代码里反复出现一行降级链chrome.storage.session ?? chrome.storage.local。这不是偷懒而是一场精确的权衡方案优势代价结论纯storage.local持久、跨会话高频写入有 IO 错误风险无内存态快放弃纯storage.session内存级速度无 IO 压力Firefox 与低版本 Chromium 不支持扩展重载即丢放弃session 优先 local 兜底快的地方快稳的地方稳需要重建逻辑采用关键洞察是session 丢数据不可怕可怕的是丢得不明不白。猫抓配合防抖批量写——单 tab 积压 100 条或距上次写入超 500ms 时延后 2 秒或 5 秒才落盘一次单 tab 数据超过 99 条干脆不再写 storage只在内存中维护。存储在这里被降级为可丢失的镜像真正的数据活在 Service Worker 内存里。保活机制三路冗余对抗生命周期裁决MV3 禁止持久后台页后猫抓选择了三种策略叠加策略原理局限webNavigation空监听每次导航重置 Service Worker 空闲时钟只对导航事件生效onConnect心跳 Portcontent script 建立命名端口后台 250 秒后主动断开反复拉长生命周期需要页面侧配合是业界知名 hacksetInterval(getPlatformInfo, 25s)周期性 API 调用维持活跃依赖实现细节未来可能失效这套保活组合拳的哲学是不赌单一机制。每个方案都可能被浏览器更新击穿但三条路同时失效的概率极低。这也解释了为什么background.js顶部同时挂着空监听、Port 心跳和定时器——它们是同一需求的三份保险。嗅探策略webRequest 为主declarativeNetRequest 为辅为什么不全面转向 Manifest V3 力推的declarativeNetRequestdNR因为它只能改请求、读不到响应头、也拿不到请求体——而猫抓判断资源靠的恰恰是响应头。dNR 的用武之地在另一处模拟手机 UA。updateSessionRules按 tab 动态注入modifyHeaders规则把一个标签页的 UA 全局替换为移动端这是 dNR 的舒适区。嗅探用 webRequest 拿数据篡改用 dNR 免权限各取所长。实现的解剖室从请求头到下载器的四段流水线 把background.js的findMedia展开是一条边界清晰的处理流水线捕获 → 过滤 → 入缓存 → 交付 │ │ │ │ │ │ │ └── downloader.html / m3u8.htmlStreamSaver / 在线ffmpeg │ │ └── 查重 防抖落盘 角标数字 │ └── CheckExtension / CheckType / 正则黑名单 └── onSendHeaders请求头 onResponseStarted响应头过滤阶段最能体现约束前置的设计。CheckExtension与CheckType都接受操作符 数值的大小条件如100 KB、500-1000 MB把用户的过滤意图编译成一次判定// 根据响应头 content-type 匹配类型表支持通配 audio/* 与大小表达式 function CheckType(dataType, dataSize) { const typeInfo G.Type.get(dataType.split(/)[0] /*) || G.Type.get(dataType); if (!typeInfo) return false; // 未配置的类型直接放行 if (!typeInfo.state) return break; // 用户关闭的类型提前中断 if (typeInfo.size ! 0 dataSize ! undefined !operatorCheck(dataSize, typeInfo)) return break; return true; }模块之间的协作关系值得注意background.js只做编排不碰页面 DOM页面内的捕获交给catch-script/catch.js的CatCatcher类它注入 MAIN world代理MediaSource方法、用 MutationObserver 监听动态插入的 iframe甚至为了兼容会克隆 iframe 并移除sandbox属性对应 issue #576——嗅探端与交付端通过runtime.sendMessage的addMedia消息对接background.js只认 URL 与请求头不关心是谁发现的。M3U8 解析器是交付端的集大成者用 hls.js 解析清单用从 hls.js 中分离出的AESDecryptor解密分片用 StreamSaver 边下边存可选的在线 ffmpeg 以嵌套 iframe 方式完成转封装。默认下载线程数为 6G.M3u8Thread: 6这个数字是分片数量、磁盘 IO、目标站点负载之间的经验平衡点——线程太少喂不饱带宽太多则大概率被站点风控6 是猫抓长期验证后的取值。图M3U8 解析器界面暴露了完整的技术面——分片列表、密钥/IV、线程数与下载范围全部可调国际化用工具链锁住社区协作_locales/下已有 10 种语言贡献者来自 changelog 各处署名。真正的工程智慧在tools/sync-locales.js以英文为基准为缺失 key 的语言文件自动填充英文占位保证任何语言在任何版本都不缺 key。翻译者无需理解架构维护者不必手动同步这降低了开源协作的隐性门槛。踩坑实录以版本号为刻度的一路修复把 changelog 当技术日志读能看到真实的失败与纠正iframe 沙箱吞掉捕获sandbox属性隔离了脚本MediaSource 代理失效最终用克隆节点移除属性的方式绕过issue #576一次性 URL难题部分站点生成的 m3u8 地址仅对单次请求有效2.7.0 改为从扩展缓存中直接读取 m3u8 内容再解析绕开地址时效BYTERANGE 分片2.6.8 支持EXT-X-BYTERANGE标签合并下载补齐了非标准切片的覆盖下载失败率高2.7.1 引入自动重试用成功率换取用户耐心在线 ffmpeg 文件丢失从新开标签改为嵌套 iframe模式2.6.8解决跨标签通信的偶发失败Firefox 的差异化storage.session缺失、blob URL 下载、录制脚本兼容都需要分支处理——跨浏览器从来不是口号而是一行行G.isFirefox。这些修复的共同特征是都在模块内部完成改catch.js不动background.js改 m3u8 解析器不影响嗅探引擎。渐进式演进在这里不是理念而是模块边界带来的自然结果。启发的搬运工三条可迁移原则与理性展望 原则一把平台的限制当成接口而不是边界。存储降级链、三路保活、双阶段嗅探都是在限制不可绕过的前提下设计出的方案。任何扩展项目都该先问我的 Service Worker 被杀死后用户会失去什么原则二用内存为主、落盘为镜的缓存模型应对配额与性能。高频数据留在内存storage 只做低频镜像配合防抖与阈值99 条内写盘、超过 9999 条清空控制写入成本。浏览器扩展的内存策略本质是可重建状态的设计。原则三用注入式脚本换取功能的热插拔。catch.js、search.js按需注入、随时移除、独立 i18n让深度搜索这类高风险脚本可以在出问题时单独回滚。松散耦合换来的是可运维性。理性的展望同样重要猫抓在浏览器内已经触到能力上限——MV3 下 dNR 对 webRequest 的逐步收紧、大文件受限于downloadsAPI 与内存模型、跨浏览器行为差异永远存在。它的下一步如果走向 AI 辅助识别或云端协同必须先回答Service Worker 生命周期这个老问题在新场景下的新版本。但正因如此这套围绕限制建立的架构才值得反复研读它证明了真正可用的技术方案从来不是对限制的规避而是与限制的共处。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考