不经过服务器传大文件：2026 年哪些方案真的能用
传一份 20 MB 的文档早就不是问题了。真正让各种「文件分享」悄悄失效的，是 20 GB：一个数据集、一个剪辑工程、一张磁盘镜像、一个装着 600 个文件的文件夹。这是 2026 年从浏览器出发传大文件的四条路的诚实对照——各付什么代价，以及浏览器点对点在哪里确实不行。
先说结论
如果双方能同时在线，而且谁都不想把文件放到第三方服务器上，那就用 WebRTC 浏览器对浏览器直传：不上传、不再从云上下载一次、没有配额、链接不过期。如果收件方几小时甚至几天之后才会点开，那你就需要存储，服务器是对的工具——只要清楚自己付的是这笔钱。
四条路对照
| 方式 | 字节住在哪 | 实际上限 | 你要付的代价 |
|---|---|---|---|
| 邮件附件 | 两个邮箱，加上中间每一台中继 | 25 MB，有时 10 MB | 没有别的代价——所以上限才压得这么低 |
| 网盘 / 快传服务链接 | 服务商的服务器，直到链接过期 | 看套餐，2–200 GB | 账号、上传时间、服务商的下行流量额度，以及一个持有你文件的第三方 |
| 对象存储 + 预签名 URL | 你自己的桶 | 事实上无限 | 你要维护一套后端、每次下载付流量、还要管凭证 |
| 浏览器点对点（WebRTC） | 哪都不在，中间没有存放点 | 发件方的磁盘与收件方的磁盘 | 双方全程都得在线；发件方的上行带宽就是上限 |
为什么浏览器现在做得到这件事
是五个 API 落地之后，第四条路才从「演示」变成了「能用」：
- WebRTC 数据通道——两个浏览器之间的有序或无序二进制通道，分片由 SCTP 负责。这就是那根管子，和视频通话用的是同一套传输。
- OPFS（Origin 私有文件系统）——浏览器里的沙盒文件系统，有真实的顺序写吞吐。块到达就直接写盘，而不是在内存里堆积，这才让 40 GB 的传输成为可能。
- WebAssembly——不用原生编译也能拿到够快的哈希与加密实现。在拿不到 WebCrypto 的浏览器里，用 ChaCha20-Poly1305 顶上。
- WebGPU——证明文件完整到达的那棵 BLAKE3 Merkle 树，可以在 GPU 上折叠而不是占用 CPU。没有 GPU 的机器降级到 wasm，再降到纯 TypeScript，校验照旧发生。
- Worker——上面这些都不许去阻塞绘制进度条的那一根线程。
「无服务器」仍然要有人交换电话号码
两台浏览器没法凭空在公网找到彼此：总得有个地方把会话描述和 ICE candidate 递给对方，这就是信令，也是整个流程里唯一接触第三方的环节。选项要么是自己跑一个 WebSocket 中继，要么用公共的。StraightPath 用公共的 Nostr relay——一个消息广播网络，正好适合这种小而短暂、无需登录但带密钥的流量——再加上公共 STUN 和默认关闭的 TURN 中转。
关键在于：信令里一个文件字节都没有。加密密钥也不在里面，密钥在 URL 片段（#k=…）里，而浏览器不会把片段发给服务器、不会写进 Referer，在这个应用里连地址栏和历史记录都不写。观察信令的一方只能看到一个房间号和一堆密文。
点对点确实更差的地方，直说
- 双方必须同时在线。发件方那个标签页就是服务器，关掉它，这次投递就死了。你要的是「丢个链接然后去睡觉」，那就该用存储。
- 上限是发件方的上行带宽。家用光纤往往很不对称——500 Mbps 下行、30 Mbps 上行的线路，天花板大约在 3.7 MB/s，收件方的机器再快也没用。
- 企业网络可能强制走中转。两端都在对称型 NAT 后面时会退回 TURN，那又是一个夹在中间的服务器（这次是经手字节，不是存储），而且更慢。它是可选的，因为它依赖某个公共中继活着。
- 移动端浏览器会限流后台标签页。要么用笔记本发，要么让手机屏幕停在这个页面上。
- 一个发件方对 N 个收件方，就是 N 次传输。CDN 能替你扇出，是因为字节躺在服务器上；点对点不行，每个收件方都要各自向发件方拉一遍。
一步一步：一个 10 GB 的文件夹，浏览器到浏览器
- 发件方打开页面，把文件夹拖进去。没有任何东西被上传——浏览器在本地读文件，一块一块地算进 Merkle 树。
- 页面给出链接和二维码。这个链接就是完整的投递：房间号加密钥。
- 收件方打开链接。浏览器用密钥解开清单——文件名、大小和预期的根值都是密封的，旁观者什么都学不到——然后开始按块请求。
- 块流入、解密、立刻写入 OPFS。内存保持平稳，磁盘占用恰好等于已收到的量。
- 最后一个字节到了，收件方在本地全量重算 Merkle 根，和清单里那个密封值比对。校验是一次完整的重读，故意不信任产出这些字节的接收路径。
- 收件方导出成真正的文件夹。如果中途关了页面，重新打开时会问你：是补齐剩下的块，还是删掉已到的部分从头再来。
排查
- 收件方那边毫无反应。
- 十次里有九次是发件方把标签页关了。这次投递只和创建它的那个页面同寿命。
- 连上了，但快不起来。
- 先查发件方的上行速度——那是上限。两端都在办公网或运营商 NAT 后面的话，到「高级」里打开 TURN，用一点速度换一条走得通的路。
- 校验失败。
- 客户端会有上限地重拉出问题的块，然后停下来明说，而不是无限循环。真正的失败意味着发件方的文件在传输途中被改过（重新分享一次），或者 flight 上有块被损坏了——Merkle 根存在的意义正是让这种事不能悄悄过去。
- 它在吃我的磁盘。
- 收到的块就是你磁盘上的真实字节，直到你导出并清理。一个好客户端会把这个数字显示出来，并给一个能把空间还回去的按钮。
- 链接能贴到群里吗？
- 可以，但要把它当成秘密：链接里含密钥。任何人在发件方在线时打开它，都能收到文件。缓解办法是让投递短命，并且走私聊。
该用哪个
25 MB 以内、只有一个收件方：老实说，邮件。收件方稍后才出现、或者需要一个长期有效的链接：网盘，然后为存储付钱。你在搭基础设施、要程序化控制：对象存储加预签名 URL。双方都在线、文件很大、你更希望字节直接过去：浏览器点对点——也就是StraightPath存在的理由。