用 Rust + Flutter 造了个免费开源的 IDM 替代品：FluxDown，聊聊它的下载引擎是怎么设计的
TL;DR：FluxDown 是一款免费、开源（AGPL-3.0）、零广告零追踪的多协议下载管理器。下载引擎用 Rust + Tokio 从零写起，UI 用 Flutter，支持 HTTP/HTTPS、FTP、BitTorrent、eD2K、HLS/DASH。Windows / macOS / Linux 全平台，还配了 Chrome / Edge / Firefox 扩展自动接管浏览器下载。
官网：https://fluxdown.zerx.dev ｜ 开源：https://github.com/zerx-lab/FluxDown
起因：IDM 很好用，但……
用过 IDM 的都知道它有多能打——多线程分段、断点续传、浏览器接管，下载速度经常能把浏览器自带的下载器按在地上摩擦。但它有几个绕不过去的槽点：
- 收费：$24.95，还要续费；
- 只有 Windows：macOS / Linux 用户无缘；
- 闭源：你不知道它在后台干了什么；
- 不支持 BitTorrent / 磁力 / eD2K，流媒体（HLS/DASH）也只是部分支持。
市面上"免费"的下载器又大多塞满广告、捆绑全家桶、偷偷上传数据。于是我干脆自己写了一个：下载引擎用 Rust 保证性能和内存安全，界面用 Flutter 做到跨平台且好看，永久免费、零广告、零追踪、不需要注册账号。
这就是 FluxDown。
它能做什么
先摆一张和 IDM 的对比表：
| FluxDown | IDM | |
|---|---|---|
| 价格 | 永久免费 | $24.95 + 续费 |
| 开源 | 是（AGPL-3.0） | 否 |
| 平台 | Windows / macOS / Linux | 仅 Windows |
| BitTorrent 与磁力链 | 支持 | 不支持 |
| eD2K / eMule 链接 | 支持 | 不支持 |
| HLS / DASH 流媒体 | 支持 | 部分支持 |
| 动态分段 | 支持 | 支持 |
| 浏览器扩展 | Chrome / Edge / Firefox | 支持 |
| 广告与追踪 | 无 | — |
核心亮点：
- 最高 10 倍提速：Rust + Tokio 引擎，IDM 式运行时动态分段；
- 多协议：HTTP/HTTPS、FTP、BitTorrent（DHT/UPnP/磁力）、eD2K（服务器 + Kad DHT 找源、MD4 校验）、HLS（AES 解密）、DASH，每种协议都有专属引擎；
- 浏览器集成：三层下载拦截，自动嗅探页面里的视频/音频/流媒体资源；
- 随处续传：每个字节都记录在 SQLite（WAL 模式），崩溃、断电都不丢进度；
- 干净纯粹：零广告、零追踪、无账号，本地优先，数据不出你的机器。
聊点硬核的：架构怎么设计的
一句话概括：Flutter 负责渲染界面，一个零 FFI 依赖的纯 Rust 引擎负责下载，两端通过 Rinf 信号通信，浏览器扩展经 Native Messaging 接入。
[浏览器扩展 (WXT)] --Native Messaging--> [fluxdown_nmh]
│ Named Pipe / Unix socket
[Flutter UI (shadcn_ui)] <--Rinf 信号--> [hub —— FFI 适配层]
│
[fluxdown_engine]
┌─────────┬────────┼────────┬─────────┐
HTTP FTP BT eD2K HLS/DASH
│
[SQLite]
这里最关键的一个设计决定是：把下载引擎 fluxdown_engine 做成零 rinf / 零 Dart 依赖的独立 crate。它通过两个 trait 和宿主解耦：
EventSink：引擎向宿主上报进度、分段拆分、队列变化等事件；HostSelection：引擎需要宿主介入决策时（比如让用户选 HLS 画质、选种子里下载哪些文件）回调。
hub 这个 crate 只是 Rinf FFI 适配层，负责信号收发和类型转换，不含任何下载协议逻辑。
为什么这么拆？ 因为这样一来，同一个引擎可以喂给完全不同的宿主：桌面 App（Flutter）、headless Web 服务器（axum）、命令行客户端（aria2c 风格 CLI）、甚至未来的手机端，都只需要各自实现一遍 EventSink / HostSelection，下载核心逻辑一行不改。目前仓库里已经有了 headless server 和 CLI 两个复用同一引擎的宿主。
这是典型的 依赖倒置 + 端口适配器：核心领域（下载）不依赖任何具体的 UI / FFI 框架，框架反过来依赖核心定义的 trait。写 Rust 的同学应该会喜欢这个边界。
智能分段：不是简单地开 N 个线程
很多下载器的"多线程"就是把文件均分成 N 段并行下。问题是：网络是不均匀的——某一段可能撞上慢速 CDN 节点，其他段都下完了它还在龟速爬，整体速度被这一段拖死。
FluxDown 的分段做了两件事：
1. 动态确定分段数（segment_advisor）
不是无脑开满线程，而是按文件大小分档，再受 CPU 核心数上限约束：
- < 1MB → 1 段（小文件多线程纯属浪费握手开销）
- 1–10MB → 4 段
- 10–100MB → 8 段
- 100MB–1GB → 16 段
-
1GB → 32 段起步
2. 运行时动态拆分与抢救（segment_coordinator）
- 主动拆分：检测到某个分段明显偏慢 → 把它剩余的部分再拆成两段并行加速；
- 抢救拆分：某分段卡死 → 拆分让空闲线程接管。
拆分是原子的：子分段插入 + 父分段缩小在单个事务里提交，避免中间态导致的重复下载或漏下。这个拆分过程会通过 EventSink 上报，前端能实时播放 IDM 那种分段可视化的动画。
这就是"空闲线程接管慢速分段"的含义——像 IDM，但更聪明。
全局限速：Token Bucket
后台挂着下载、前台还想正常刷网页，就需要限速。FluxDown 用经典的 Token Bucket 做全局限速器：
- 参数：
rate（字节/秒）+burst（突发缓冲，默认等于 rate）； - 每次写盘前
consume(bytes)异步等待令牌，令牌不够就 await，天然不阻塞 Tokio 运行时。
这样既能精确控制总带宽，又允许短时突发，不会把速度限制得一顿一顿的。
断点续传：SQLite 全量持久化
任务、分段、配置、队列全都落在 SQLite 里（WAL 模式 + 外键）。每个分段的 downloaded_bytes 都按 5 秒批量刷盘，断电 / 崩溃 / 强制关机后重启，从上次的字节数继续，不重下已完成的部分。
顺带一提，持久化层用的是 sqlx 的 Any 池，$N 占位符统一 SQL，同一份代码能同时跑 SQLite 和 PostgreSQL 双后端——这是为 headless server 部署预留的。
浏览器集成：三层拦截
装上扩展后，FluxDown 会自动接管浏览器下载。拦截做了三层防线：
webRequest.onHeadersReceived：缓存响应头，检测Content-Disposition/Content-Type；downloads.onDeterminingFilename：主拦截（Chrome MV3 专属），suggest({cancel:true})干净地取消浏览器自身下载并转交 FluxDown；downloads.onCreated + onChanged：兜底拦截，也是 Firefox 的唯一路径。
外加：自动嗅探页面里的视频/音频/HLS 流、Alt+Click 临时放行浏览器直接下载、右键"发送到 FluxDown"。全平台走 Native Messaging Host 与 App 通信（Windows 用 Named Pipe，Linux/macOS 用 Unix socket）。
下载与安装
从 GitHub Releases 或官网获取最新版（当前 v0.1.52）：
- Windows（x64 / ARM64）：
setup.exe安装程序 · 便携版.zip - macOS（Intel / Apple Silicon）：
.dmg· 便携版.tar.gz - Linux（x64）：
.AppImage·.deb· Arch.pkg.tar.zst· 便携版.tar.gz
⚠️ 安全提醒：官方唯一域名是 fluxdown.zerx.dev，开源仓库是 github.com/zerx-lab/FluxDown。近期发现有假冒站点
fluxdown.com.cn传播木马（SilverFox），请勿从任何非官方渠道下载。
最后
FluxDown 完全开源（AGPL-3.0），用 Rust 写引擎的初衷就是想证明：免费的东西也可以很硬核。技术栈是 Rust + Tokio + Flutter + Rinf，代码在 GitHub 上，欢迎围观、提 Issue、发 PR。
- 🌐 官网：https://fluxdown.zerx.dev
- 💻 开源仓库：https://github.com/zerx-lab/FluxDown
- 💬 QQ 群：832143651
如果它帮你省下了时间，欢迎给个 Star —— 这能让更多人发现它。有任何问题、建议、想支持的协议，评论区或 Issue 见。
浙公网安备 33010602011771号