浏览器传输 vs 应用传输：无需安装？
比较浏览器和应用程序文件传输。了解Web解决方案为何提供更好的便利性和跨平台支持。
基于浏览器的文件传输在几乎所有临时或面向客户的工作流中胜出，因为它不需要安装任何东西，在 Windows、macOS、Linux、iOS、Android 和 ChromeOS 上运行效果完全一致。基于应用的传输（Dropbox、Google Drive、OneDrive、WeTransfer 原生应用）在桌面同步、后台上传，以及同一个人每天需要传输几十次文件的场景中仍然胜出。其余场景——摄影师交付最终拍摄成果、律师发送证据开示材料、开发者将构建产物交给测试人员——HexaTransfer 或 SwissTransfer 这类基于浏览器的服务无需任何安装提示就能完成工作。
"基于浏览器"实际意味着什么
现代 Web 传输服务完全运行在浏览器中，使用十年前根本不存在的 API。File API 无需服务器介入即可从磁盘读取文件。Web Crypto API 使用原生浏览器实现（通常通过 Intel/AMD 的 AES-NI 或移动端 ARM 密码学扩展进行硬件加速）执行 AES-256-GCM 加密。Fetch API 通过 tus.io 等协议将加密分块流式传输到服务器，支持断点续传。Service Worker 让页面在部分离线时工作，或在后台处理上传。
最终结果：浏览器成为一个有能力的文件处理客户端，无需安装步骤。"应用"就是网页，每次会话都重新加载，提供商一旦发布修复就立刻生效。
应用传输的两个子类别
"应用"可以指两种不同的东西。原生桌面同步应用（Dropbox、Google Drive for Desktop、OneDrive）作为后台进程运行，监视文件夹并同步变更。移动应用在 iOS 和 Android 上做类似的事，使用 iCloud Drive、Google Drive 或 OneDrive 客户端。
另外，一些传输服务在其 Web 流程之上发布了专用应用——WeTransfer 有桌面和移动应用，为超大文件或后台上传增加了上传可靠性。这些应用是可选的；同一服务的 Web 版本通常处理相同的工作负载。
安装门槛扼杀采用率
面向客户的自由职业者没有任何筹码要求客户安装任何东西。"在我能发给你最终视频之前，请先下载 SecureTransferPro 桌面客户端，安装它，创建一个账户，接受三个权限对话框，然后重启你的浏览器"——这不是专业体验。
基于浏览器的链接立刻就能用。点击，看到文件，下载。这就是 WeTransfer 增长到数亿用户的原因——收件人的流程毫无摩擦。Dropbox Transfer 也受益于同样的特性，尽管 Dropbox 的整体平台是应用驱动的。
安全权衡的演变
应用历史上是注重安全的传输服务的首选方式，因为它们可以控制运行时环境。原生应用可以固定证书，将密钥存放在平台安全飞地（Keychain、Credential Manager、Android Keystore），并避开浏览器复杂的攻击面。
这个论点已经弱化了。Web Crypto API 提供了经过验证的原语，包括 AES-256-GCM、SHA-256、PBKDF2 和 ECDH。子资源完整性（SRI）让页面固定自身脚本的哈希值。HTTPS 配合 HSTS 和证书透明度让针对 TLS 的中间人攻击极其困难。内容安全策略（CSP）标头将脚本加载限制在已知来源。
一个谨慎的浏览器实现在安全性上现在已经与原生应用竞争力相当。残余风险——提供商发布恶意 JavaScript——同样适用于自动更新的原生应用。
平台覆盖范围
| 平台 | 基于浏览器 | Dropbox 桌面应用 | Google Drive 桌面应用 | |---|---|---|---| | Windows 10/11 | 是 | 是 | 是 | | macOS 12+ | 是 | 是 | 是 | | Ubuntu/Debian | 是 | 是（ARM 非官方）| 无官方版本 | | Fedora/RHEL | 是 | 是（rpm 可用）| 无官方版本 | | iOS | 是（Safari、Chrome）| 是（App Store）| 是 | | Android | 是（Chrome、Firefox）| 是（Play Store）| 是 | | ChromeOS | 是 | 有限（Android 应用）| 原生 | | Linux ARM64 | 是 | 有限 | 否 | | 特殊环境（自助机、图书馆）| 是 | 否（无法安装）| 否 |
浏览器覆盖本质上是通用的。应用覆盖存在缺口。
资源消耗
原生同步应用持续运行。Google Drive for Desktop 空闲时通常使用 150—300 MB 内存，并产生多个后台进程。Dropbox 客户端历来因 CPU 占用激进而被批评，尤其是在大型文件夹初始索引期间。两者都在同步时大量写入磁盘。
基于浏览器的传输在你不主动传输时不消耗任何资源。在需要时打开页面，完成后关闭。没有守护进程，没有定时任务，没有开机启动项。对使用电池的笔记本来说，这一点很重要。
大文件上传可靠性
大型上传以前偏向原生应用，因为浏览器无法可靠地恢复一个在中途失败的 20 GB 上传。现在这不再是问题。tus.io 断点续传上传协议通过 tus-js-client 库在浏览器中实现，将上传分成可配置大小的分块（桌面端通常 5—64 MB），用 HEAD 请求确认每个分块以检查已接收字节数，并在中断后从最后成功的偏移量处恢复。
HexaTransfer 或 SwissTransfer 的会话可以在合上笔记本盖、切换 Wi-Fi 网络或短暂 ISP 中断后继续，无需重新开始。Web 在专用应用曾经提供的功能上已经追上来了。
原生应用仍然重要的场景
桌面同步——在你的机器上有一个与云端同步的文件夹——本质上是应用的工作。没有基于浏览器的服务尝试这件事。如果你的工作流涉及同一组文件需要在多个设备上持续编辑，原生同步应用依然正确。
非常大的计划上传（每晚 50 GB 以上）受益于作为服务运行的原生工具，它们能够智能重试，并且不需要浏览器窗口保持打开。rclone、Dropbox CLI 和 OneDrive 企业同步客户端能很好地处理这些工作负载。
移动照片和视频自动备份是另一个应用的强项。没有基于浏览器的服务可以在你不看页面时持续在后台上传新照片——操作系统会挂起或终止后台 JavaScript。
基于浏览器明显胜出的场景
一次性交付。面向客户的文件交接。任何涉及组织外部一方或双方的交互。任何你不拥有的设备——图书馆的公共电脑、酒店商务中心、出差时借用的笔记本。不允许安装的自助机环境。被锁定为禁止第三方应用的企业设备。
浏览器是通用执行环境。如果你需要某样东西在任何地方无需协商地工作，浏览器就是答案。
商业层面的意义
对服务提供商来说，基于浏览器的交付降低了客户支持成本。没有"你的操作系统版本是多少？"工单。没有应用更新的竞争条件。没有内核扩展冲突（还记得 Dropbox 发布的内核扩展与 macOS 安全更新冲突的事吗？）。服务每次页面加载就自我更新。
对买家来说，基于浏览器的传输意味着不需要对桌面代理进行采购审查，不需要 IT 安全审查应用在后台做什么，不需要更新部署管道。攻击面是网页，比具有系统级权限的二进制 blob 更容易评估。
混合现实
大多数人两者都用。Dropbox 用于团队共享文件夹，浏览器传输服务用于外部客户交付。笔记本上同步 Google Drive 用于持续编辑的文档，HexaTransfer 或 SwissTransfer 用于发送 5 GB 视频给不需要被邀请进你的 Google Workspace 的承包商。
结论
"基于应用的传输"作为独立产品类别正在萎缩。Dropbox、Drive 和 OneDrive 的原生同步应用对于持久共享工作依然有意义。专用传输应用（WeTransfer 桌面版等）对大多数用户来说已经失去存在的理由——浏览器现在可以做到这些了。对于以交付为核心的传输，基于浏览器的方式是默认选择，自 2020 年前后就已经是这样了。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。