把豆包无印资源，做成一个真正能用的浏览器助手

我在原程序里确认了什么

最开始我去找的是浏览器程序目录里的源码，但目录中没有原始的 .cs、.js 或工程文件，真正的实现载体是编译后的 DolaMultiBrowser.dll。通过 .NET 元数据、方法名和字符串引用的静态分析，确认到了豆包备用接口提取、解析、视频源下载、预览转换和资源下载这些方法。

所以这次的核心结论是：原程序不是把视频画面上的水印擦掉，而是拦截豆包响应，提取 fallback_api，再经过解析得到 main_url / videoUrl，最后把它作为“无印资源”展示和下载。原始 C# 源码没有找到，具体的像素级去水印算法也没有被确认。

已经确认的调用链

这一步的意义是把问题从“猜它怎么去水印”变成“确认它如何找到可用资源”。只有先分清这两件事，后面的插件封装才不会写成一个看似能点、实际上靠猜的壳。

四个文件，各自只负责一件事

• page-hook.js：运行在页面 MAIN world，观察豆包页面的响应，在 im/chain/single 这类响应中递归寻找图片的 image_ori_raw.url，同时识别视频的 fallback_api。
• content-bridge.js：运行在扩展侧，负责创建“无印资源”面板、资源卡片、缩略图、筛选、选中状态、小窗预览，以及播放和导航交互。
• service-worker.js：调用浏览器下载 API，统一文件名和下载目录，把单个下载与批量下载从页面 UI 中分离出来。
• manifest.json：声明 Chrome / Edge Manifest V3、豆包页面匹配范围、下载与设置权限，以及可替换的解析接口配置。

图片和视频为什么是两条不同的路径

图片可以直接从豆包响应里的 image_ori_raw.url 取到，所以 0.2.0 就能完成图片预览和下载；视频则需要把 fallback_api 交给原 DLL 使用的解析服务，得到可下载的视频地址。这个解析服务是第三方依赖，不是我今天新建的服务，因此它可能因为接口变化或服务不可用而失败，设置页也保留了替换地址的入口。

这样拆分之后，插件能把“发现资源”和“保存资源”放在浏览器里完成，同时把外部解析依赖单独标记出来。以后哪一层变化，才知道应该改页面侦测、解析配置，还是下载逻辑。

根因不是视频源被裁切，而是容器比例不匹配

旧的小窗大约固定为 760 × 600，同时视频元素又被要求把宽和高都填满预览区。对于横屏、竖屏或其他比例的视频，这会造成黑边、视觉比例不协调，甚至让人误以为素材本身被裁掉了。

第一轮修复把图片和视频改为自动宽高、最大宽高限制和等比显示；第二轮进一步加深遮罩，避免豆包页面底部的按钮视觉穿透；最后在 0.3.3 中加入窗口自适应：先读取媒体真实宽高，再在屏幕允许范围内计算 stage 和小窗的宽高。

最后采用的计算思路

aspect = mediaWidth / mediaHeight
stageWidth = min(screenWidth, maxWindowWidth)
stageHeight = stageWidth / aspect
if stageHeight > maxStageHeight:
    stageHeight = maxStageHeight
    stageWidth = stageHeight * aspect
window = stage + header + footer

这段逻辑的价值不在于代码多，而在于它把“视觉上像比例不对”的问题，变成了可以测量、计算和复查的规则。最终保留了上一项、下一项、下载当前、播放、静音、进度条和时间显示。

对 AI 短视频和短剧制作来说

• 先看再下：生成了多张图或多条视频时，先在面板里看缩略图和预览，减少把不合适的素材全部下载下来再筛选。
• 批量收集：需要把一轮生成结果带入剪辑、分镜或素材整理时，可以勾选后一次提交下载，减少手动复制临时链接。
• 比例可靠：横屏和竖屏资源在预览中按真实尺寸显示，减少因为小窗拉伸造成的错误判断。
• 链路可维护：页面侦测、外部解析和浏览器下载分开，豆包接口变化时，可以定位到具体一层，而不是重新猜整个功能。

对我自己的工作方式来说

以前拿到生成素材，往往是在页面里找按钮、打开开发者工具、复制临时地址，或者依赖一个完整的浏览器程序。现在的思路是：把“发现资源”做成页面上的固定入口，把“预览”和“下载”做成连续动作，把资源直接放进后续视频生产的素材流里。

当然，这个助手只用于我有权使用的内容。它不是一个绕过权限或处理任意视频的工具；它依赖豆包前端响应结构和第三方解析服务，也不能保证平台接口变化后永远有效。

已经完成的本地检查

• 完成 JavaScript 语法检查。
• 完成图片和视频提取样例检查。
• 完成单个与批量下载路由检查。
• 完成媒体真实宽高和预览自适应规则检查。

目前仍然存在的边界

• 原始 C# 源码不在发现的浏览器目录里，当前扩展是按已确认行为重新封装，不是从源码直接编译出来的版本。
• 视频依赖原 DLL 使用的第三方解析服务；解析服务不可用、豆包接口改变或响应尚未完成时，面板可能不会出现资源。
• 今天的本地检查不等于已经在当前登录的豆包页面完成长期实时回归，下一步仍需重新加载扩展并在实际页面里验证一轮。
• 批量下载最多提交 30 个资源，浏览器可能根据下载安全策略弹出确认。