# 文件夹值得比 ZIP 更好的待遇 Source: https://help.strongfolder.com/zh/blog/folders-deserve-better-than-zip/ Updated: 2026-11-05 > 我们认为，不该再为了分享而压缩文件夹。打包一个大文件夹既费时间又要双倍磁盘空间，媒体文件几乎压不小，巨大的压缩包还会弄坏或搞乱长路径。StrongFolder 在浏览器之间把文件夹作为文件夹发送，收件人得到的是相同的子文件夹和文件名。 右键、“压缩”、等待、添加附件、发送。然后收件人下载、右键、“解压”，再等一次。我们大多数人做这些时根本不假思索——几十年来文件夹一直是这么发的。我认为是时候别再为了分享而压缩文件夹了。ZIP 格式诞生于 1989 年，当时要解决的问题是把文档塞进软盘、通过慢速调制解调器传输。如今我们的文件夹是视频项目、照片拍摄和代码仓库，这个老习惯付出的代价已经超过了它带来的好处。 ## 我们为什么要压缩文件夹？ 因为大多数分享渠道只能传单个文件。邮件附件是一个文件。聊天工具里上传的是一个文件。传统的下载链接指向一个文件。而文件夹是一棵由文件组成的树，所以必须先打包成一个文件，才能塞进这些管道。 压缩是第二个原因，在 1989 年它很重要：文本和电子表格能压缩掉很多。但对于如今人们发送的大多数文件夹，这个理由已经悄然消失了。 ## 压缩到底让你付出了什么？ 举个真实的例子：一个 40 GB 的婚礼拍摄文件夹——RAW 照片、几段 MP4 视频、一些修好的 JPEG。 - **磁盘空间，翻倍。** 你需要在原文件旁边再腾出约 40 GB 给压缩包。收件人需要 40 GB 放 ZIP，再要 40 GB 来解压——一个 40 GB 的文件夹要占 80 GB，至少在他们删掉压缩包之前是这样。 - **时间，三倍。** 你等它打包，再等它传输，然后收件人等它解压。在笔记本电脑上，打包和解压几十 GB 的时间可能和传输本身一样长。 - **几乎压不小。** JPEG、MP4、MOV 和大多数 RAW 格式本来就是压缩过的。把它们压缩几乎不会改变大小。你付出了时间和磁盘空间，换回来的几乎为零。 - **不到最后什么都用不了。** 如果是一个大压缩包，收件人要等到最后一个字节到达并全部解压后，才能打开第一张照片。 ## ZIP 里会出什么问题？ 成本是一回事。问题也会出现，而且往往发生在最糟糕的时刻。 **长路径。** Windows 默认把文件完整路径的长度限制在 260 个字符。在 Mac 上创建的、子文件夹层级很深且命名很详细的项目文件夹，在 Windows 上解压时可能报错或丢失文件。 **超大压缩包。** 原始 ZIP 格式的上限是单个文件 4 GB、65,535 个条目。ZIP64 扩展取消了这些限制，但并不是每台机器上的每个工具都以同样的方式处理它。有些网盘会把大文件夹的下载拆分成好几个 ZIP 文件，收件人之后还得把它们拼回去。 **文件名。** 用一个工具创建、用另一个工具打开的压缩包，可能会把非拉丁字母的文件名变成乱码——西里尔字母、希腊字母、中文、带重音的字母。结构送到了，名字却没有。 **垃圾文件。** macOS 访达创建的压缩包会带上 `__MACOSX` 文件夹和 `.DS_Store` 文件，让 Windows 用户摸不着头脑，最后还混进收件人的项目里。 **一处出错，从头再来。** 如果一次 40 GB 的下载在 95 % 时失败，压缩包就毫无用处。如果有一个字节损坏，解压可能半途而废。 这些都不稀奇。如果你发送过几 GB 以上的文件夹，很可能至少遇到过其中一种。 ## StrongFolder 如何把文件夹作为文件夹发送？ 我们打造 StrongFolder 的出发点很简单：如果文件直接从你的浏览器传到收件人的浏览器，就没有理由先把它们打包成一个文件。 当你选择一个文件夹时，你的浏览器会读取它的目录树——每一个子文件夹和文件名。不会上传任何内容。你把链接发出去；收件人打开链接并选择保存位置。然后文件通过加密的 WebRTC 连接在两个浏览器之间直接传输，每个文件都带着它的相对路径，同样的文件夹树就出现在收件人的磁盘上。 这在实际中带来的变化： - **不打包，不解压。** 收件人一打开链接，传输就开始。 - **不额外占用磁盘空间。** 收件人只需要放文件夹的空间，而不是文件夹加压缩包的空间。 - **文件逐个到达。** 剩下的文件还在路上时，第一批照片已经到了收件人的磁盘上。 - **如实处理路径。** 如果某个路径对 Windows 来说太长，我们会缩短文件名，并附上一个文本文件，列出所有被重命名的文件。没有任何东西会悄无声息地消失。 - **我们不设大小上限。** StrongFolder 不设大小限制。实际限制来自接收方设备的可用磁盘空间、网络速度，以及两台设备保持在线的时长。 有两个前提条件我每次都会提到。要保留结构保存整个文件夹，收件人需要在电脑上使用 Chrome、Edge、Opera 或其他 Chromium 浏览器——其他浏览器会逐个下载文件或下载为 ZIP。另外，在收件人下载完成之前，你的标签页必须保持打开，因为文件来自你的设备，而不是服务器。这就是不上传任何东西的代价。[为什么发送方需要保持在线](https://help.strongfolder.com/en/guides/why-sender-stays-online/) 对此有详细解释。 [立即发送文件](https://strongfolder.com) ## 什么时候 ZIP 仍然是合适的工具？ 我并不反对 ZIP。它是一种出色的格式——只是不该成为每次发送前的默认步骤。以下情况我仍然会压缩： - **我在归档。** 一个文件更容易存储、校验并保存多年。 - **我需要密码。** StrongFolder 的链接没有密码。对于敏感文件，加密压缩包（例如使用 AES-256 的 7-Zip）再加上通过另一个渠道发送的密码，能增加一层保护，而且适用于任何传输方式。 - **文件夹里有成千上万个小文件。** `node_modules` 文件夹或一堆小图片缓存打包成一个文件传得更快，因为每个文件都有自己的额外开销。 - **收件人用的是手机。** 手机无法从浏览器保存文件夹树，所以文件无论如何都会逐个下载或以 ZIP 形式送达。 至于其他所有情况——拍摄素材、剪辑工程、CAD 项目、游戏模组、扫描档案——就原样发送文件夹吧。 ## 怎样彻底告别压缩文件夹？ 如果你想要分步说明，并把电子邮件、网盘和传输服务放在一起对比，请阅读 [如何不压缩直接发送文件夹](https://help.strongfolder.com/en/guides/send-folder-without-zipping/)。对于超大文件夹，[如何发送大文件](https://help.strongfolder.com/en/guides/send-large-files/) 介绍了速度和设置，[限制与要求](https://help.strongfolder.com/en/limits/) 列出了所有浏览器细节。 如果哪天文件夹送到时出了问题——名字不对、子文件夹丢失，无论什么问题——请写信给我：[info@strongfolder.com](mailto:info@strongfolder.com)。文件夹是 StrongFolder 存在的理由，我想知道。 ## FAQ ### 用 StrongFolder 发送文件夹前需要先压缩吗？ 不需要。直接选择文件夹本身；StrongFolder 会读取它的目录树，并带着路径发送每一个文件。文件夹以文件夹的形式发送：子文件夹和文件名都会保留，不会被压缩打包。 ### 收件人需要什么才能完整拿回整个文件夹？ 按原有结构保存整个文件夹需要使用 File System Access API：电脑上的 Chrome、Edge、Opera 及其他 Chromium 浏览器支持。其他浏览器可以逐个下载文件，或以 ZIP 格式下载。 ### 压缩在什么情况下仍是更好的选择？ 有的：长期归档、需要带密码的加密压缩包，或者文件夹里有成千上万个小文件——把它们打包成一个文件传得更快。