ffl 和 croc、Magic Wormhole 这类 CLI 传档工具差在哪？

如果你常在终端机里传档，应该多少听过 croc、Magic Wormhole、portal、sendme 这类工具。它们都解决同一个基本问题：把档案从一台机器送到另一台机器。

主流传档方式大致可以分成两大类：

1. P2P 传输工具
   尽量让两端直接连线传档。如果直连失败，有些工具会改走 relay。Magic Wormhole、portal、sendme 都属于这个方向。croc 则比较偏 relay-first，用 relay 来避开 NAT 和防火墙带来的麻烦。

2. 云端上传型工具
   先把档案上传到服务器，再给接收者下载连结。像 transfer.sh、WeTransfer、file.io 这类服务都属于这个模式。

平常大家最常用的其实是第二类，例如 Google Drive、Dropbox、WeTransfer。原因很简单：接收端不用装东西，拿到连结就能下载。

CLI 传档工具通常有另一个优点：速度快、流程短、适合工程师、自动化和临时传输。但它们也常有一个共同限制：接收端通常也要安装同一个工具。

例如 croc 很好用，但两边都要有 croc。Magic Wormhole 也一样，双方都要进入同一套 wormhole 流程。这对自己的两台机器之间传档很方便，但如果你要把档案传给客户、同事、手机使用者，或者一群人，就容易卡住。

那么 ffl 有什么不同？

ffl 是「快档连结 FastFileLink」的 CLI 版。它的核心想法很直接：在终端机里把档案、资料夹，甚至 stdin stream 变成一个可以直接打开的 HTTPS 下载连结。

ffl 的核心差异：接收端拿到的是 HTTPS 连结

ffl 的心智模型比较接近：

ffl file.zip
→ 产生一个 HTTPS link
→ 对方用 browser / curl / wget / ffl 下载

接收端不需要先安装 ffl。如果他有浏览器，就能下载。如果他在 server 上，可以直接用 curl 或 wget。这一点让整个传输模式变得很不同。

多数 CLI 传档工具比较像一次配对：

sender terminal  <->  receiver terminal

ffl 则比较像建立一个可下载的交付入口：

sender creates HTTPS link
recipient A downloads
recipient B downloads
recipient C downloads later

这也是为什么 ffl 天生适合一对多、多次下载、可续传的情境。它不是只为「我的两台电脑互传」设计，也适合「我要把这份档案交给别人」这种更接近交付的场景。

快速比较

✅ 支援 / 适合　❌ 不支援 / 不适合　➖ 视情况或不是主要模式

WebRTC 对速度和路径有什么影响？

ffl 默认会尝试 WebRTC P2P。打得通时，资料直接从发送端流到接收端，中间不必绕过 relay。对大档案来说，少一段中转通常很有感。

如果 P2P 打不通，ffl 会自动 fallback 到 HTTPS relay / tunnel，下载仍然能继续，不会因为 NAT 或防火墙卡住整个流程。接收端如果用浏览器或 curl，走的是 HTTPS 路径；如果接收端也用 ffl，可以优先尝试 WebRTC。

croc 的设计则比较偏 relay-first。这让它很好穿透 NAT，但速度会比较依赖 relay 的位置、带宽和路由。跨国、公司网络、云端机房之间传大档时，这个差异会变得明显。

sendme 这类工具也有现代 P2P 能力，技术上很强。不过接收端仍然需要使用对应工具或 ticket 流程，没有 ffl 这种直接给标准 HTTPS 下载连结的接收体验。

croc 这类工具强在哪？

croc 的优点很明确：两台装置都装好后，用一组 code 配对，传档流程很顺。对工程师来说，从自己的笔电传到远端主机、从公司电脑传到家里电脑，这类一对一场景很适合。

Magic Wormhole 也有类似优势。它的 code phrase 很适合口头传递，安全模型成熟，适合双方都愿意使用同一套 CLI 工具的情境。

这些工具最大的甜蜜点是：

两边都懂 CLI
两边都能安装工具
一次传完就结束

如果你的需求刚好是这样，croc 和 Magic Wormhole 都很好。

ffl 更适合哪种情境？

ffl 的优势出现在另一种场景：

我想传档给不懂 CLI 的人
我想让对方直接用浏览器下载
我想把同一个连结给多个人
我希望下载中断后可以续传
我想用 curl / wget 放进自动化流程
我想同时保有 P2P 直连和 fallback 的可靠性

这些需求一出现，HTTPS link 的价值就变明显。

你不需要确认对方有没有装工具，也不需要教对方输入口令。你只要给他一个连结。对方使用浏览器、手机、server、CI job，都有自然的接收方式。

跟云端上传型工具差在哪？

transfer.sh、WeTransfer、file.io 这类服务也能产生下载连结。它们的流程通常是：

先上传到服务器
再让对方下载

这很方便，但也代表档案一定先经过服务端储存。大档案会先等上传完成，隐私和保留期限也取决于服务提供者。

ffl 的策略更弹性。它可以先尝试 WebRTC P2P 直连，直连不行再 fallback。需要让发送端离线时，也可以使用 upload mode，让它变成临时下载连结。

这让它同时覆盖了两种常见需求：

双方都在线：优先 P2P 直连
双方不同时在线：upload mode 临时交付

如果再搭配 E2EE，relay 或暂存服务器也无法读取内容。

APE：为什么单档可携很重要？

ffl 除了 native builds，也提供 APE 版本。APE 是 Actually Portable Executable 的缩写，来自 Cosmopolitan 生态。简单说，它是一种「单一可执行档，尽量跨多个操作系统直接跑」的格式。

这跟一般 Go / Rust 工具也有差异。Go 或 Rust 常常可以编成单一 binary，但通常还是要依照平台下载不同版本：

linux-amd64
linux-arm64
macos-arm64
windows-amd64.exe
...

APE 的体验比较像：

下载 ffl.com
放进 USB、家目录、共享资料夹或工具包
需要时直接执行

对 DevOps、临时救援、客户环境、container、没有安装权限的机器很有用。你不一定要先安装 package manager，也不用在目标机器上建一堆 runtime。

这也让 ffl 的可嵌入能力比较特殊。官方 Android App 和 MCP Server 都是把 APE 版本当成核心 engine 使用。外层负责手机、AI agent 或服务端整合，底层仍然是同一个 ffl.com。

几个很有感的 DevOps 场景

1. 从 container 里把结果拉出来

你在 container 里跑了一个任务，产生了报表、模型、log bundle 或测试 artifact。一般做法可能要挂 volume、开 SCP、设权限，或者先传到云端。

用 ffl 可以直接：

ffl /output/report.zip

它印出一个 HTTPS link，你在本机浏览器或另一台机器用 curl 下载即可。container 环境越临时，这种方式越省事。

2. 把 MySQL 备份直接交给同事或另一台机器

备份数据库时，不一定想先落地一个巨大 .sql 档再上传。你可以把 stream 直接交给 ffl：

mysqldump production_db | ffl - --name production_backup.sql

对方可以用浏览器下载，也可以在另一台机器用 ffl 或 curl 接。需要还原时也可以搭配 stdout 流水线处理。

3. CI job 产生大型 artifact，临时分享给 reviewer

有些 build artifact 太大，不想塞进 GitHub Actions artifact、S3 或内部档案服务。尤其是 debug build、benchmark result、模型权重、压缩后的 log bundle。

在 CI 或临时 build server 里跑：

ffl build/output/

然后把 link 丢给 reviewer。对方用浏览器开，不需要知道 CI runner 里发生什么事。

4. 线上机器不能装太多东西，但需要临时传档

很多 production 或客户环境不适合安装额外套件，也不一定有 Python、Node、Go runtime。APE 单档在这种时候很方便。

你可以把 ffl.com 放在内部工具目录、USB、跳板机，或用一次性的方式抓下来。需要传档时执行，用完就删掉。

5. 把档案交给「不是工程师」的人

这点看似普通，其实很常见。你要把 log、视频、资料包、模型输出、设计素材交给 PM、客户、测试人员或外部厂商。

如果用 croc，对方也要装 croc。如果用云端硬盘，可能要先上传、设权限、等同步。

ffl 给对方一个 HTTPS link。对方用浏览器下载。这就是它最直接的价值。

什么时候选哪个？

如果你只是在两台自己控制的机器之间传档，而且两边都能装 CLI，croc、Magic Wormhole、sendme 都是成熟选择。

如果你要传给一般使用者、客户、同事，或者希望一个连结可以被多人、多次下载，ffl 会更自然。

如果你只需要把档案丢到云端，等对方之后下载，transfer.sh、WeTransfer 这类工具也可以完成任务。只是这类工具通常没有 P2P 直连，也比较不像一个便携式 CLI delivery engine。

小结

ffl 的特色可以用一句话概括：

它把 CLI 传档做成 HTTPS link delivery。

这让它和 croc、Magic Wormhole 这类一对一配对工具有明确区隔。接收端不必安装工具，同一个连结可以给多人下载，也能用浏览器、curl、wget 或 ffl 接收。

加上 WebRTC P2P、fallback relay、E2EE、upload mode、APE 单档可携，ffl 更像是一个可以日常使用、也能放进自动化流程里的档案交付工具。

想看更完整的逐项比较，可以看 Wiki 里的 详细比较。

想试试看？可以到 FastFileLink CLI 下载。