猫抓Cat-Catch浏览器资源嗅探扩展深度解析沙盒之内如何搭建完整的媒体处理流水线【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch网页里的视频明明在播放浏览器开发者工具里却翻不到完整的下载地址站点用 MediaSource 把分片拼成流、把密钥藏进 JS、把接口做成一次性 URL——普通用户只能干瞪眼。浏览器资源嗅探扩展猫抓 Cat-Catch 要解决的正是这个行业级痛点在 MV3 规范收紧、Service Worker 随时可能被回收、存储接口频繁报错的三重夹击下把看见资源、抓住资源、加工资源这条链路完整跑通。这篇文章不写功能清单而是从架构决策的角度复盘猫抓每走一步棋放弃了什么、又换回了什么。一、捕获引擎的三线作战webRequest、注入代理与 iframe 攻坚的取舍 ⚙️现代网页的媒体资源有三大藏身之处普通网络请求、MediaSource 动态拼接、嵌套 iframe 沙盒。任何单一路径都会漏抓猫抓的选择是三线并行但每条线的投入程度完全不同。第一线webRequest 钩子只做宽口径筛查在 js/background.js 中猫抓放弃了在onBeforeRequest阶段拦截请求源码中这段逻辑被整体注释转而使用onSendHeaders与onResponseStarted的组合。原因是明显的请求发出前可用的信息太少误判率极高而响应阶段能拿到 Content-Type、Content-Length 等关键元数据判断这是不是媒体资源才足够可靠。// 请求头暂存等待响应阶段核对 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.OnBeforeSendHeadersOptions.EXTRA_HEADERS].filter(Boolean)); // 收到响应头后拼接完整上下文做最终判定 chrome.webRequest.onResponseStarted.addListener(function (data) { data.allRequestHeaders G.requestHeaders.get(data.requestId); findMedia(data); }, { urls: [all_urls] }, [responseHeaders]);findMedia内部是一条多层过滤器链先按文件后缀过滤再按 MIME 类型过滤然后检查Content-Disposition附件头最后放行type media的资源。用户自定义的正则规则在发送阶段提前介入命中黑名单的请求 ID 直接进入G.blackList后续不再处理。这一层刻意做得宽进严出——宁可多捕几个再让用户筛也不放过真正要抓的目标。第二线MediaSource 代理攻克看不见的流针对 MSE 拼接的视频普通网络嗅探完全失效。猫抓的答案写在 catch-script/catch.js 里用 Proxy 代理MediaSource.prototype.addSourceBuffer和appendBuffer把每一段塞进缓冲区的二进制数据原样录下来同时用代理endOfStream判断播放是否结束。这套方案的代价是内存占用随视频时长线性增长于是代码里补上了两个兜底累计捕获超过 1GB 自动触发分段保存以及每 1GB 保存一次的用户选项。放弃的是把全片常驻内存换来的是长时间直播场景下的可用性。第三线iframe 攻坚解决 #576 号 issue很多网站把播放器放在带sandbox属性的 iframe 里导致内容脚本无法注入。猫抓的处理方式很直接cloneNode克隆 iframe 并摘掉 sandbox 属性再用 MutationObserver 持续监听新增节点。这是有副作用的操作——会轻微改变页面 DOM但相对于抓不到资源这个硬伤这是性价比最高的妥协。二、MV3 时代的两场硬仗Service Worker 续命与存储降级 ⚖️Manifest V3 把所有后台逻辑塞进 Service Worker而它会在约 30 秒无活动后被浏览器掐断30 秒后状态全部丢失。这是所有 MV3 扩展的共同噩梦猫抓应对这场硬仗的方式堪称教科书级。心脏起搏器HeartBeat 心跳通道在 js/background.js 开头猫抓用chrome.runtime.onConnect监听一个名为HeartBeat的端口收到消息后回复并维持连接 250 秒同时叠加setInterval(chrome.runtime.getPlatformInfo, 25 * 1000)与webNavigation空事件监听。多条起搏路径互相冗余谁先触发谁保活。这里的关键不是代码多巧妙而是接受了一个前提SW 一定会死我们的目标只是让它死得晚一点、醒得快一点。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); });存储降级从 storage.local 到 storage.session 的一次主动退让2.5.3 版本有一行值得细品的变更storage.local改为storage.session。直觉上配置持久化是刚需但猫抓在真实运营中发现storage.local的 IO 错误会导致扩展整体不可用——稳定性的优先级被提到了持久性之上。这一取舍可以用一张矩阵看清楚对比维度storage.local旧storage.session新数据生命周期长期持久浏览器会话结束即清扩展稳定性高 IO 错误风险显著降低需要承担的成本无配置可能丢失需重建缓存猫抓的评估结论忍痛放弃最终采纳配合存储降级猫抓还在写入路径上做了一整套减负设计单标签页缓存超过 9999 条强制清空防内存膨胀通过urlMap对 URL 指纹查重且查重集合超过 500 条自动清空、超过 500 条资源强制关闭查重——用可能漏一次重复换CPU 不被拖垮。保存动作本身也做了防抖100 条以上攒 5 秒、两次保存间隔小于 500 毫秒则延后 2 秒。每一处性能优化本质都是一次关于丢数据 vs 卡页面的明确选择。三、M3U8 解析器的流水线拆解从分片清单到成品的模块化之路 M3U8 是 HLS 流媒体的清单文件下载它的本质是把几十上百个 TS 分片拉下来再合并。猫抓把这条链路拆成了解析、解密、下载、合并四个相对独立的工位任何一个工位升级都不影响其他环节。工位一与二hls.js 驱动解析 AES 解密在 js/m3u8.js 中解析工作直接复用hls.js引擎关闭 worker、关闭 debug切片对象存入_fragments数组密钥内容与EXT-X-KEY的 IV 偏移量分别用keyContent与initData两个 Map 维护解密器AESDecryptor是从 hls.js 中独立抽取的模块const hls new Hls({ enableWorker: false, debug: false }); const _fragments []; // 切片对象集合 const keyContent new Map(); // 密钥内容缓存 const decryptor new AESDecryptor(); // 独立解耦的 AES-128 解密器m3u8.js 的页面通过 URL 参数接收任务上下文——url、requestHeaders、key、tabid、retryCount等全部通过 query string 传入。这样设计的直接收益是任务可恢复、可重试、可多开下载出错自动重试、遇到一次性 URL时从缓存读取 m3u8、支持EXT-X-BYTERANGE的字节区间分片合并。这些能力都是历次真实踩坑用户反馈、issue 修复沉淀出来的而非预想出来的需求。工位三与四分片并发下载与合并方式的选型下载环节最核心的权衡是在哪里合并。猫抓给出了三条出路浏览器内合并依赖mux.js把 TS 转 MP4支持 HEVC/H265 预览胜在零依赖但大文件合并吃 CPU嵌套在线 ffmpeg2.6.8 起支持在解析器页面内嵌 iframe 式在线 ffmpeg不再新开标签页解决文件无法正确送达的问题——这是对外部工具链路不稳定的针对性修正外部下载器转交通过自定义协议m3u8dl://或 aria2 RPC 把任务交给专用下载器适合追求速度与成功率的重度用户。三条路线共享同一套清单解析结果这正是模块化带来的红利上游的解密结果一次到位下游的出口可以随时加新。四、社区驱动的国际化用 10 种语言撬动全球贡献者 2.5.0 之后的版本里多语言几乎是每版都涨繁体中文、西班牙语、葡萄牙语、土耳其语、俄语、韩语、越南语……这种节奏靠的不是开发者自己翻译而是_locales/标准目录 贡献者认领的模式。结构如下_locales/ ├── en/messages.json # 英文默认语言 ├── zh_CN/messages.json # 简体中文 ├── zh_TW/messages.json # 繁体中文 ├── es/messages.json # 西班牙语 ├── ja/messages.json # 日语 ├── ko/messages.json # 韩语 ├── pt_BR/messages.json # 巴西葡萄牙语 ├── ru/messages.json # 俄语 ├── tr/messages.json # 土耳其语 └── vi/messages.json # 越南语仓库里的 tools/sync-locales.js 承担了同步与校验的职责避免新增文案后各语言文件不同步。在运行时内容脚本通过data-i18n属性与window.CatCatchI18n字典完成替换见 catch-script/catch.js 的applyI18n。这套机制的巧妙之处在于翻译者不需要理解任何架构只需要会改 JSON——贡献门槛降到最低社区的翻译供给就源源不断。放弃的是运行时动态下载语言包带来的灵活性换来的是打包即用、离线可用的稳定性。五、复盘与前瞻四件事做对了未来还差什么 回看整个演进历程猫抓真正做对的是四件事每一层都有兜底Shadow DOM 创建失败就退到 body 直接插入原生 attachShadow 被劫持就从 iframe 里取干净方法storage 失败就换 session。兜底不是锦上添花而是扩展在真实世界生存的底线。每个性能决策都标了代价查重上限 500 条、缓存上限 9999 条、保存防抖 2 秒——每个数字背后都是一次丢一点精度换大量流畅的明牌交易。把合并等重活留给生态不重复造 ffmpeg、不硬扛大文件合并而是通过自定义协议、iframe 嵌套、在线服务把专业工具接进来。扩展做调度中枢比做全能工人更可持续。用标准目录承接社区力量_locales不是什么新技术但配合 sync 脚本和清晰的认领机制就成了项目全球化最便宜的杠杆。至于未来方向其实已经被架构提前铺好了webrtc.js与录制脚本已经证明捕获能力可以延伸到实时流MQTT 协议的接入2.6.4让嗅探数据可以向云端同步云原生架构的地基已经打下在线 ffmpeg 的 iframe 嵌套模式说明浏览器内 云端辅助的混合计算是可行的。再往前一步用浏览器端的轻量 AI 模型做资源分类与质量预测需要的正是现在这套稳定、模块化、可扩展的管线。沙盒没有限制猫抓的上限反而逼它把每一分资源都用在刀刃上——这或许是浏览器扩展开发中最值得抄的作业。【免费下载链接】cat-catch猫抓 浏览器资源嗅探扩展 / cat-catch Browser Resource Sniffing Extension项目地址: https://gitcode.com/GitHub_Trending/ca/cat-catch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
