批量上传优化：更快传输文件夹

最快的批量上传策略：将文件夹打包成一个"仅存储"（无压缩）的 .zip，以一个大对象代替成千上万个小文件上传。5000 个 .jpg 文件每个 500 KB，合计 2.5 GB，但逐个上传所需时间是打包成一个 2.5 GB 存档后上传的 10—20 倍，原因在于每个小文件都要承担完整的 TLS 和 HTTP 开销。支持并行上传的服务（HexaTransfer、Dropbox、rclone）在分块较大时更有优势。即便不支持并行，将小文件合并成一个存档后，吞吐量仍然更高。另外，删除意外重复的文件，跳过 .DS_Store 和 Thumbs.db 这类垃圾文件，传输时间可以缩短到原来的几分之一。

为什么成千上万个小文件很慢

每次通过 HTTPS 上传文件都有固定开销：TLS 握手（可通过 keep-alive 连接复用）、HTTP 头（约 500 字节）、服务器确认，以及接收端的磁盘写入。对于 50 KB 的文件，这些开销可能超过文件本身的大小；对于 500 KB 的文件，开销占传输总字节数的 10%—20%。

乘以 5000 个文件，你就把一半时间浪费在元数据处理上，而不是实际数据传输上。这也是为什么将大量小文件的文件夹复制到外部存储时，总是比复制等大小的单个存档慢得多。

先打包，再上传

文件夹上传最关键的提速手段：先压缩成一个 .zip、.7z 或 .tar 文件，再上传。对已压缩的内容（照片、视频、Office 文档），用"仅存储"模式——获得打包优势而不浪费 CPU。对文本密集的文件夹（日志、源代码），用默认压缩，既打包又减小体积。

常用命令：

macOS/Linux： zip -0 -r archive.zip folder/（无压缩）；zip -r archive.zip folder/（默认压缩）
Windows： 右键文件夹 → 发送到 → 压缩（zipped）文件夹。或用 7-Zip：添加到存档 → 压缩级别 → 仅存储
大型文件夹： tar -cf archive.tar folder/（无压缩）或 tar -czf archive.tar.gz folder/（gzip 压缩）

打包前先去重

文件夹会随着时间积累重复文件。设计项目里可能有"final_v2.psd"、"final_v2_COPY.psd"、"final_v2_BACKUP.psd"——内容相同，文件名不同。一个 20 GB 的文件夹去重后通常能缩减到 12 GB。

常用工具：fdupes（Linux）、rmlint（Linux/macOS）、Duplicate File Finder（macOS）、dupeGuru（跨平台）。这些工具通过计算文件哈希来识别重复内容。先检查结果，再删除重复文件，最后打包。

摄影师使用 Lightroom 时，目录已经跟踪了唯一照片；导出时只选标注的精选图，而不是导出整个拍摄文件夹。

过滤系统垃圾文件

每个 macOS 文件夹都会积累 .DS_Store 文件（隐藏元数据）。每个 Windows 文件夹都有 Thumbs.db。Linux 的 KDE 桌面会生成 .directory 文件。这些文件对接收方毫无用处，还会增加存档的文件数量。

在 macOS 上打包时：

zip -r archive.zip folder/ -x "*.DS_Store" "__MACOSX"

在 Windows 上用 7-Zip 时，可在界面或命令行中排除：-xr!Thumbs.db -xr!desktop.ini。对于 rsync 风格的传输，使用 --exclude='.DS_Store' --exclude='Thumbs.db'。

并行分块上传

服务支持时，并行 HTTP 流能填满单个 TCP 连接在高延迟路径上无法充分利用的带宽。tus.io 协议通过并发分块上传支持这一功能。tus-js-client 库默认为单并发请求，但可配置为更高并发数。

对于跨洲际上传（例如美国用户向欧洲服务上传），并行可将有效吞吐量翻倍甚至三倍。对于本地上传，单流通常已能跑满上传带宽，并行并无额外收益。

分块大小调优

大分块减少每次请求的开销；小分块在网络故障后恢复更快。权衡取决于你的连接状况：

| 连接类型 | 建议分块大小 | |---|---| | 千兆光纤，有线 | 32—64 MB | | 家用光纤，Wi-Fi | 10—20 MB | | 办公室宽带 | 10 MB | | 移动 4G/5G | 2—5 MB | | 不稳定/酒店 Wi-Fi | 1—2 MB |

大多数面向消费者的服务会选择合理的默认值（5—10 MB），不暴露该设置。命令行工具（rclone、aws s3 cp、gsutil）允许精确调整。

文件夹层级深度对速度影响不大

常见误解："文件夹嵌套越深，上传越慢。"实则不然。打包后存档格式会将所有路径压平成字符串头部，无论嵌套多深。10000 个文件分布在 3 层和 10 层目录中，打包后上传速度完全相同。

真正有影响的是：单个文件的数量。无论是平铺的 10000 个小文件还是嵌套的 10000 个小文件，打包成存档才是关键。

按内容类型选择压缩策略

混合照片（.jpg/.heic）： 仅存储模式 .zip，不浪费 CPU
RAW 照片（.cr3/.arw/.nef）： 仅存储模式 .zip，内部已压缩
视频项目（.mp4、.mov、.prproj）： 仅存储模式 .zip
源代码： 7z 搭配 LZMA2，追求最大压缩比
日志文件： 7z 搭配 LZMA2，预计压缩比 10—20 倍
PDF： 仅存储模式，大多数 PDF 内部已压缩
混合 Office 文档（.docx、.xlsx）： 仅存储模式，本质已是 ZIP 压缩的 XML
数据库导出（.sql）： 7z 搭配 LZMA2，压缩效果极佳

后台上传 vs 前台上传

基于浏览器的上传必须保持标签页处于活跃状态。关闭标签页通常会中断上传。部分服务提供基于 Service Worker 的后台上传，在标签页关闭后短暂延续，但在移动浏览器和某些企业浏览器配置下并不可靠。

对于真正的大批量上传（100 GB 以上），桌面客户端更胜一筹，因为它以操作系统级别的进程运行。rclone 支持挂载并同步到任何主流云端。Dropbox 桌面客户端能可靠排队上传，即使合上笔记本盖子或切换 Wi-Fi 也能继续。

对于 10 GB 以内的批量上传，支持分块上传的现代浏览器服务完全能胜任。HexaTransfer 的客户端加密增加了少量 CPU 开销，但在当前硬件上不会对吞吐量产生明显影响。

分割超大批次

当批次大小超过服务的单次传输上限时，按逻辑而非机械方式分割。按日期分组的文件夹（例如某次拍摄项目）比按字节数任意分割更好，因为接收方可以验证每批是否完整（"3月1日—7日.zip"、"3月8日—14日.zip"），而不用猜测第 5 个分卷是否丢失。

完成前先验证

大批量上传很容易一键启动后就不管了。不要这样做。在关上笔记本之前：

确认上传页面显示"已完成"而非"进行中"
在不同浏览器或隐身窗口中打开链接，验证接收方的体验
确认存档能正常打开（上传过程中 .zip 损坏虽然罕见，但确有可能）
确认过期时间设置符合预期

五分钟的验证，胜过次日尴尬地发邮件询问对方是否收到文件。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。