# 谁在用 StrongFolder？四个大文件传输使用场景

Source: https://help.strongfolder.com/zh/blog/who-uses-strongfolder/
Updated: 2026-11-05

> 最适合 StrongFolder 的大文件传输使用场景都有一个共同点：体积大、以文件夹形式存在、收件人现在就需要。交付 120 GB 的婚礼摄像师、发送 Revit 项目的建筑工作室、分享 30 GB 构建包的独立游戏开发者，以及把扫描照片发往海外的家庭，都省去了上传，并保留了文件夹结构。

经常有人问我，StrongFolder 到底是给谁用的。老实说：任何文件大到邮件和聊天工具发不了、不想先把文件上传到某个地方、而收件人此刻就准备好下载的人。这还是有点抽象，所以下面介绍四个大文件传输使用场景，每个都对比了人们以前通常怎么做，以及改用直接传输后有什么变化。


这些是**示例场景**，而非客户评价——没有名字，也没有引语。其中的数字是计算示例（大小（GB）× 8,000 ÷ 上行速度（Mbit/s）= 秒数），你可以用自己的数据重新计算。

## 婚礼摄像师如何交付 120 GB？

**要交付的内容：** 两种分辨率的成片、一段精彩集锦，以及新人想要存档的原始相机素材文件夹——总共约 120 GB，目录结构类似 `Film/`、`Highlights/`、`Raw/Camera A/`、`Raw/Camera B/`。

**以前：** 通常的做法是连夜上传到网盘，第二天发链接，然后新人下载时还要再漫长地等一次。拍了几场婚礼后存储套餐就满了，旧项目只能删掉或者付费保留。另一种做法是把 U 盘寄过去或当面交付——可靠，但要花好几天。

**改用直接传输后：** 摄像师从工作室的电脑上分享文件夹，新人一打开链接就开始下载——无需先等上传完成。在 100 Mbit/s 上行带宽下，120 GB 大约需要 9,600 秒，约 2 小时 40 分钟；在 50 Mbit/s 下约 5.3 小时。工作室电脑接上电源、插上网线、关闭睡眠。文件夹树原封不动地送达，画质也没有任何损失。

**注意事项：** 新人需要远超 120 GB 的可用磁盘空间，并在电脑上使用 Chrome、Edge 或 Opera 才能保存整个文件夹。一个定制的 U 盘作为纪念品仍然是个贴心的做法——直接传输取代的是等待，而不是礼物。详见 [如何分享大视频文件](https://help.strongfolder.com/en/guides/share-large-video-files/)。

## 建筑工作室如何发送 Revit 项目文件夹？

**要交付的内容：** 一个 Revit 主模型，带有链接的结构和 MEP 模型、CAD 链接和图片——比如说 6 GB、几千个文件——发给外部顾问。

**以前：** 全部压缩，上传压缩包，发送链接。顾问解压到另一个文件夹，几个链接因为指向绝对路径而断掉，一个下午就花在了重新链接上。每次修订都会在某人的网盘里再多出一个压缩包。

**改用直接传输后：** 工作室用 Revit 的 eTransmit 把项目打包成一个文件夹——它会复制主模型及其链接文件并重写路径——然后原样发送这个文件夹。文件夹以文件夹的形式发送：子文件夹和文件名都会保留，不会被压缩打包。 在 50 Mbit/s 上行带宽下，6 GB 大约需要 16 分钟，而且之后服务器上不会留下任何东西。

**注意事项：** 对于工作共享模型，请发送分离的副本，切勿发送中心文件。如果是在同一个模型上进行日常协作，共享项目平台是更好的工具；直接传输用于交付一个打包好的项目。详情请见 [如何发送 CAD 文件](https://help.strongfolder.com/en/guides/send-cad-files/)。

## 独立游戏开发者如何与测试人员分享 30 GB 的构建包？

**要交付的内容：** 一个试玩构建包——可执行文件、数据文件夹和库——约 30 GB，五位测试人员今天都要拿到。

**以前：** 把构建包上传到网盘（家庭宽带要好几个小时），发出链接，然后眼看着网盘配额在第三个构建包时就耗尽了。或者在发行平台上建一个分支，这对公开试玩版来说是正确的做法，但对一次快速的内部测试来说太重了。

**改用直接传输后：** 在测试人员的群聊里发一个链接。一个链接可以被多位接收方打开；每个人都直接从发送方下载。 问题在于上行带宽：如果五个人在 100 Mbit/s 上行带宽下同时开始，每人大约分到 20 Mbit/s，而以 20 Mbit/s 传 30 GB 大约需要 12,000 秒——所有人都要 3.3 小时。如果一次只给一位测试人员，大约 40 分钟就能拿到构建包。错开开始时间，或者在本来就一直开着的台式机上连夜发送，就能缩短等待。

**注意事项：** 缺少任何一个文件夹，构建包都无法启动，这正是保留结构如此重要的原因。对于公开试玩版和定期补丁，Steam 试玩或 itch.io 这类平台可以在你离线时处理更新。只分享你拥有版权的构建包。参见 [如何分享游戏文件](https://help.strongfolder.com/en/guides/share-game-files/)。

## 一个家庭如何与海外亲人分享扫描照片？

**要交付的内容：** 几十年的家庭照片，以高分辨率扫描并按年份分门别类——比如说 25 GB、几千个文件——发给另一个国家的亲戚。

**以前：** 聊天应用会压缩照片并限制文件大小，共享相册要求每个人都有账号和存储空间，刻光盘寄到国外又要好几周。这份档案常常就这样一直没能分享出去。

**改用直接传输后：** 全家约好一个在两个时区都合适的晚上，两台电脑都保持唤醒，亲戚们在 Chrome 中打开链接。在 20 Mbit/s 的家庭上行带宽下，25 GB 大约需要 10,000 秒，不到三小时——相当于看一部长片的时间，而且只需一次。每张扫描件都以原始质量送达，并放在各自的年份文件夹里。同样的原画质原则也适用于摄影师的 RAW 文件：[如何发送 RAW 照片](https://help.strongfolder.com/en/guides/send-raw-photos/)。

**注意事项：** 如果爷爷奶奶打算“下周找个时间”再下载，共享网盘相册会更体贴——StrongFolder 的链接只在你持续分享期间有效。

## 这些大文件传输使用场景有什么共同点？

四个不同的人，一个共同的模式：

| | 婚礼影片 | Revit 项目 | 游戏构建包 | 家庭档案 |
|---|---|---|---|---|
| 大小 | 约 120 GB | 约 6 GB | 约 30 GB | 约 25 GB |
| 形式 | 文件夹树 | 链接文件 | 必须保持完整的文件夹 | 按年份分的文件夹 |
| 收件人现在就准备好了？ | 是 | 是 | 是 | 是，在约定的时间 |
| 50 Mbit/s 上行所需时间（一位收件人） | 约 5.3 小时 | 约 16 分钟 | 约 80 分钟 | 约 67 分钟 |

文件很大，是文件夹而不是单个文件，而且收件人已经准备好了。正是在这种情况下，省去上传、保留结构、服务器上不留副本才会带来回报。StrongFolder 不设大小限制。实际限制来自接收方设备的可用磁盘空间、网络速度，以及两台设备保持在线的时长。

这并不适用于所有情况。当发送方无法保持在线、文件必须在几周内保持可用，或者大家需要预览和评论时，云端链接更胜一筹——参见 [P2P 与云端文件传输](https://help.strongfolder.com/en/guides/p2p-vs-cloud-file-transfer/)。从教师到开发者，更多场景请见 [使用场景页面](https://help.strongfolder.com/en/use-cases/)。

[立即发送文件](https://strongfolder.com)
如果你的情况与这些都不一样，我很想听听：[info@strongfolder.com](mailto:info@strongfolder.com)。

## FAQ

### 这些是真实的客户故事吗？

不是。它们是根据典型情况构建的示例场景，附有计算好的数字，你可以用自己的文件大小和网速重新算一遍。我们不公布客户名称或引语。

### 一次大文件传输需要多长时间？

大致是：大小（GB）× 8,000 ÷ 发送方上行速度（Mbit/s）= 秒数。以 100 Mbit/s 传 120 GB 大约需要 9,600 秒，即 2 小时 40 分钟。由于存在额外开销，实际传输会慢一些。

### 什么时候应该改用网盘？

当你无法保持在线直到收件人下载完成、文件必须在几天或几周内保持可用，或者大家需要在线预览和评论时。在接收方下载完成之前，发送方的浏览器标签页必须保持打开并在线——文件来自发送方的设备，而不是服务器。