FluxDown 三层拦截机制 — Header、文件名、终极兜底

传统下载器的痛点

很多传统下载器的浏览器扩展只做一件事——监听浏览器的下载事件，在浏览器已经决定要保存一个文件后，拦截住再交给自己。问题是：此时浏览器已经吞掉了 Header 信息（比如 Redirect 过的真实 URL、Cookie、Referer），扩展只能拿到残缺的 URL 和文件名。

FluxDown 做了三层拦截，确保浏览器保存文件之前就能拿到完整的请求信息。

第一层：Header 级拦截

在浏览器发出下载请求、还没拿到响应 Header 之前就介入。通过 Chrome 的 chrome.webRequest API（Firefox 是 browser.webRequest）监听目标为 download 的请求：

• 拿到完整的 URL（包括 Redirect 后的真实地址）。
• 拿到原始的 Referer、Cookie、User-Agent、自定义 Header。
• 拿到 Content-Type / Content-Length 等响应头信息。
• 拿到 Set-Cookie（有些站点在响应头里下发一次性下载凭证）。

这一层抓到的信息最完整，也是扩展最常用的拦截方式。

第二层：文件名判定

有时候 Header 拦截时机稍晚、或者请求类型不好判断，扩展会对浏览器下载清单里已登记的下载项做二次判定：

• 用 URL path、Content-Disposition Header、响应体前几个字节的 Magic Number 判断文件类型。
• 结合扩展名（.zip / .iso / .dmg）、常见下载源域名、文件大小阈值来判断是不是值得拦截的下载。
• 过滤掉浏览器自动下载的 favicon、统计像素、XMLHttpRequest 等非真实下载。

这一层主要作用是「精确挑出大文件下载」，避免扩展抢了本该浏览器自己处理的小资源。

第三层：终极兜底

如果前两层都没拦截到（某些站点的下载走 JavaScript 动态创建 <a download> 再触发点击、完全不走标准下载流程），扩展还有一层兜底：

• 监听点击事件，目标是带 download 属性的 <a> 标签时提前介入。
• 监听 window.fetch 和 XMLHttpRequest，捕获流式响应或 blob 下载。
• 浏览器下载事件本身的 final fallback——至少能拿到已经在浏览器下载清单里的东西。

三层怎么配合

优先级：Header 拦截（最完整）> 文件名判定（最准）> 点击/fetch 监听（兜底）。抓到后统一送给 FluxDown 桌面端，FluxDown 在「新建下载」窗口里显示「Header 数量 × N、Referer ✓、Cookie × N」等信息让用户确认。

和其他下载器的对比