Relayium

如何直接发送整个文件夹，而不只是文件

最近更新: 2026-08-05

发送一个项目和发送一个文件不是一回事——你手上是一个套着子文件夹的文件夹，一个一个复制粘贴会丢掉让它有意义的结构。先打包压缩也行，但那意味着在开始传输之前要先绕道用一个压缩工具。

Relayium 让你在实时传输里选中文件夹整体发送。浏览器会遍历整棵目录树、保留每个相对路径，并实时流式发出——同一局域网内 WebRTC 直连，跨网络经 TURN 承载端到端密文——且不保留服务器端实时副本或历史。留着稍后取用的存储链接是唯一不携带目录结构的那条路：请自己先打包，然后上传那一个压缩文件。

选文件夹，而不是一堆散文件

你需要准备

  • 发送这一侧要用桌面浏览器——Chrome、Edge 或 Firefox。iPhone 和 iPad 上 Safari 的文件选择器根本无法选中文件夹，只能选单个文件，所以发送文件夹要从电脑开始。
  • 一棵最多 1,000 个文件的目录树。这个上限是按批而不是按会话算的，所以更大的树可以分几次发送，不用重新连接。
  • 对接收方浏览器有个判断，因为它决定了到达时的形态：Chrome 或 Edge 会把目录树写进接收方挑选的文件夹，其他浏览器则会给出一个 .zip。
  • 实时发送需要双方同时在线；如果对方不在，则需要发送方登录，外加一个你自己打好的压缩包——因为存储链接上传的是一份平铺的文件清单，不携带任何目录结构。

不必一个个选文件，直接选中文件夹本身即可。Relayium 会在浏览器里遍历整个目录树，保留每个文件的相对路径——子文件夹、嵌套的子文件夹，全都保留——所以对方收到的东西和你出发时的目录结构一致。

目前这在桌面版 Chrome、Edge 和 Firefox 上可用。在 iOS 上不行：iPhone 和 iPad 上 Safari 的文件选择器没有办法选中文件夹，只能选单个文件，所以发送文件夹暂时是桌面端的功能。

  1. 在发送方电脑上打开传输页面——同一网络就用同网络页面，需要配对码就用实时传输页面。

    https://relayium.com/

  2. 把文件夹拖到页面上，或者用文件夹选择按钮。Relayium 会在浏览器里遍历目录树并保留每个文件的相对路径，所以不需要先打包。

  3. 同一网络下，在「附近的设备」里找到接收方，在它的卡片上按「打开工作区」，然后用工作区里的「发送文件夹」附件。跨网络是同一个动作：加入配对码房间，在那里的对端卡片上同样按「打开工作区」。无论哪种情形，对方收到的请求上写的都是文件数量和整棵树的总大小，而不是单个文件的大小。

  4. 在接收方，接受之前先读一下请求下面那行：用 Chrome 或 Edge 时它会说浏览器要问你存到哪，而这条路径才能在磁盘上还原出文件夹。然后按「接收」。

  5. 看着两块屏幕上的文件计数逐个走过这棵树。它数的是文件，所以一个 300 个文件的文件夹会走到「文件 300/300」，而不是给整批显示一根进度条。

    文件 300/300

文件夹发送完成时是什么样

计数停在这一批的最后一个文件，而每个文件到达时都用各自的 SHA-256 哈希做过端到端校验，所以落地的内容和你发出的逐字节一致。

接下来要看的是结果，而不是页面，因为它按浏览器而不同：用 Chrome 或 Edge 时，目录树连同子文件夹都在你挑好的文件夹里；用 Firefox 或 Safari 时，下载列表里是一个 .zip，解开后结构一致。

局域网直连
文件 300/300

对方收到的是什么

文件夹如何送达取决于接收端的浏览器。Chrome 和 Edge 可以把文件直接写入接收者选定的目录，文件夹会原样出现在磁盘上——不需要额外步骤。

Firefox 和 Safari 没有这个能力，所以它们收到的是一个仅存储（不压缩）的 .zip 压缩包，解压后就是完全相同的文件夹结构。它保持在 4 GiB 以内（不支持 ZIP64），这足以覆盖绝大多数项目文件夹和照片、文档集合——如果更大，就拆成两次发送。

现象、检查、处理

发送方设备上根本找不到选文件夹的入口。
https://relayium.com/   # 只有浏览器支持时，选择器才会提供文件夹这一项

你几乎肯定是在 iPhone 或 iPad 上，那里 Safari 的选择器只给出单个文件，别无其他。请从电脑上的 Chrome、Edge 或 Firefox 发起文件夹传输，把手机当作接收方。

收到的 .zip 损坏，或者下载在接近 4 GiB 时停住。
chrome://downloads   # 把 .zip 的大小和你发出的文件夹对一下

打包这条路径不支持 ZIP64，所以单个条目和整个压缩包都必须保持在 4 GiB 以内。请把目录树拆成两次发送，或者让接收方改用 Chrome 或 Edge——它会把文件写进选定的文件夹，根本不会生成压缩包。

.zip 的大小和文件夹一样，完全没有压缩。
chrome://downloads   # 条目的大小等于文件夹总大小，而不是更小

这是预期行为：这个压缩包仅存储，它只是把目录树打包起来而不做压缩，因此与你发出的内容逐字节一致。如果你更在意传输体积而不是精确副本，请在发送前自己压缩这个文件夹。

文件都到了，但全都平铺在一个目录里，子文件夹不见了。
chrome://downloads   # 没有目录选择器的浏览器会交给你一个 .zip

实时发送会保留相对路径，所以这只是压缩包还没解开时的样子，并不是传输把结构拍平了。解开压缩包，子文件夹就在里面；如果希望目录树直接落在磁盘上，请用 Chrome 或 Edge 接收，并在它询问时挑好目标文件夹。真正会拍平的只有存储下载链接那条路——它上传的是一份平铺的文件清单，路径会被丢掉——所以打算走链接的文件夹必须先自己打包。

几百个文件的文件夹传到一半停下，缺了一个文件。
https://relayium.com/   # 计数会显示它停在哪个文件上

实时发送是一次实时会话：只要两个页面都还开着，临时掉线可以从最后一个持久化检查点接着传。任何一侧关闭或刷新都会结束这次会话，那就没有什么可续的了。先保持两个标签页开着稍等一会儿再动手；只有在会话确实已经结束时，才从计数停住的那个文件重发这一批。如果对面根本没人，请先自己把文件夹打包成 zip，再把那一个压缩包作为存储链接上传——因为存储上传拿到的是一份平铺的文件清单。

实时传输，或留个链接稍后取

如果双方能同时在线，就实时发送文件夹。同一局域网内 WebRTC 直连；跨网络浏览器按设计使用 TURN 承载端到端加密的密文，中继无法读取或解密。Relayium 不保留服务器端实时副本或传输历史。同一网络无需账号；跨网络时配对码创建者登录，加入的一方始终无需账号。

如果对方现在不在，可以改为创建一个存储链接——但要先自己把文件夹打包。存储上传收到的是一份平铺的文件清单：相对路径会被丢掉，所以直接上传一棵目录树，到手的是一堆散文件，不同子目录下同名的两个文件还会撞名。做一个普通的 .zip 再上传那一个文件，结构就随压缩包一起走了。你的浏览器会在上传前用一把只存在于链接本身的随机 AES-256-GCM 密钥加密你上传的内容，服务器只保存它读不懂的密文。创建链接需要发送方登录；可以设置 1 小时、1 天、3 天、7 天或最长 14 天后过期（上限取决于套餐），也可以设置为首次下载后即焚。

常见问题

能从 iPhone 或 iPad 发送文件夹吗？

作为发送方不行——iOS 上的 Safari 没有文件夹选择器，只能选单个文件，所以目前发送文件夹要在桌面版 Chrome、Edge 或 Firefox 上进行。但 iPhone 或 iPad 完全可以正常接收文件夹，会以 .zip 形式收到。

子文件夹和文件结构会保留吗？

实时发送会：Relayium 保留每个文件的相对路径，包括嵌套的子文件夹，所以到达的文件夹和你选中的那个结构完全一致。存储下载链接不一样——它上传的是一份平铺的文件清单，路径会被丢掉——所以需要保住结构时，请自己先打包，再上传那个压缩包。

一个文件夹最多能发送多少文件？

单批最多 1,000 个文件，每个文件到达时都会各自用 SHA-256 哈希校验。

对方收到的是真正的文件夹还是一个 .zip？

取决于对方的浏览器。Chrome 和 Edge 会把文件直接写入对方选定的目录。Firefox 和 Safari 会收到一个仅存储的 .zip（不超过 4 GiB），解压后就是相同的文件夹结构。

发送文件夹需要账号吗？

同一网络下不需要。跨网络用配对码发送需要发送方登录，但无论哪种情况接收方都不需要账号。

选中一个文件夹，原样发出去——结构完整，每个文件都经过校验。

立即试用 Relayium

继续阅读