一个把「上传—下载」压成「直传」的文件传输工具：文件不落在别人的服务器上，收件人连客户端都不用装。

先看清它在做什么

EteDrop 是一个跨平台的文件传输工具，思路很直接：能不经过服务器就不经过服务器。它用 WebRTC 在发送端和接收端之间拉一条直连通道，服务端只负责三件事——帮两台设备互相找到、把分享页分发出去、以及提供运行状态接口。文件本身不进服务器，也不存在第三方存储上。

这件事说起来简单，落到体验上差别不小。把文件先上传到某处、再让对方下载，一份文件在链路上实际走了两趟；直连只有一趟。官方博客里算过一笔账：5GB 的文件在 50Mbps 的连接下，走两趟大约 14 分钟，直连大约 7 分钟。数字会随网络浮动，但「一趟和两趟」的差别是结构性的。

公网传输：不落地，也不中转

EteDrop 的分享方式是「链接 + 取件码」。你把链接发出去，收件人打开、输入取件码，就能看到并取走文件。链接可以随意转发，取件码保证只有对的人能取——这一层访问控制，是那种「同网段自动发现」的传输方式给不了的。

跨网络时它靠 WebRTC 的 NAT 穿透建立连接。官网常见问题里给出的说法是：约 80% 的用户网络环境支持 P2P 传输。剩下那部分穿不透的环境，直连这条路就走不通，所以它对网络条件是挑剔的。这不是隐藏条款，官方把它写在了首页 FAQ 里。

局域网模式：同网段自动切

两台设备挂在同一个路由器下面时，EteDrop 会自动走局域网直连，不绕公网。这个模式的速度取决于路由器和网卡，实际表现接近本地网络的硬件上限。办公室互传、家里几台设备来回倒素材，用的基本都是这条路径。

局域网模式支持一次发给多台设备，也能批量接收。除了文件，剪贴板里的文字和图片也能直接发过去，省掉「先存成文件再传」这一步。这条路径连外网都不需要，断网环境下照样能用。

接收端零安装，这件事被低估了

传输工具真正的摩擦往往不在速度，而在「对方装没装」。EteDrop 把接收端做成了网页：发件人这边用客户端，收件人只需要一个浏览器。对方用的是 Windows、Mac 还是手机，都不影响。

于是你不用再为了发一个 300MB 的视频，先让对方注册账号、装客户端、等它更新完再打开。发链接，对方点开，取件码一填，事情就结束了。

先看清，再下载

EteDrop 在分享页里内置了预览：PDF、常见图片、音频、纯文本和带语法高亮的代码文件可以直接在浏览器里打开看，MP4 视频支持边收边看。确认这一版没问题，再点下载。

这个细节在传大文件时尤其有用。500MB 的素材下完才发现对方发错了版本，重来一次的成本不低；能先看一眼，就能少走一次这样的弯路。

开源，也能自己搭一套

项目已经在代码托管平台上开源，采用 MIT 许可。仓库按职责拆成了几块：Flutter 写的多平台客户端、NestJS 写的信令服务、React + Vite 写的分享页，以及 Docusaurus 搭的官网。想在内部网络里自建一套，服务端部署、桌面端打包、移动端打包都有对应的文档。

技术栈没什么花活：Flutter / Dart 负责跨平台客户端，NestJS + TypeScript 负责信令与接口，媒体处理那部分依赖 FFmpeg。作者把第三方组件声明和许可义务单独列了一份文档，做二次分发的人需要自己核对 FFmpeg 的编译选项——这类细节愿意写清楚的独立项目并不多。

它合适与不合适的地方

双方都在线、手里有个大文件要立刻给对方、或者不希望文件在别人的硬盘上留一份，这是 EteDrop 最舒服的场景。反过来，如果收件人此刻不在，你要的是「先放着，明天再来下」，那还得靠有存储能力的服务——P2P 没有异步投递这回事。

另外官方也写明了：传输中断之后需要重新传，目前没有断点续传。传 10GB 以上的东西，建议走稳定的有线或者信号强的 Wi-Fi。这些属于取舍而不是缺陷——直连省掉的是服务器，代价自然也就是服务器本来能提供的那部分保障。

EteDrop 把一个老问题拆回最朴素的样子：文件从 A 到 B，中间不经过第三个人。代价是双方得同时在线、网络得穿得透；换来的是更短的等待，和一份「文件没落在别人机器上」的踏实。