移动端加密文件传输：随时随地安全共享
确保移动文件传输端到端加密。了解基于浏览器的加密如何在iOS和Android上工作。
移动端文件加密在 iOS 的 Safari 和 Android 的 Chrome/Firefox 上通过 Web Crypto API 运行——与桌面端相同的 crypto.subtle.encrypt 调用。从相册或文件应用选取的文件，在任何字节离开手机之前，都会被 AES-256-GCM 加密。计算瓶颈在于 PBKDF2 密钥派生，iPhone 14 Pro 上完成 60 万次迭代约需 350 ms。对于一个 500 MB 的 .mov 视频文件，真正的速度瓶颈是上传带宽，而不是加密计算。移动端优先的传输服务不需要原生应用——浏览器已经具备所需的一切。
为什么基于浏览器优于原生应用
Dropbox、WeTransfer 2023 年前版本等文件传输原生应用需要宽泛的权限申请，在关闭后仍驻留内存，并推送广告。浏览器工作流无需安装，用完关闭标签页即告结束。更重要的是，苹果 App Store 曾拒绝真正零知识应用的上架（Cryptee 2021 年的遭遇有详细记录），这使得浏览器成为唯一能保证加密逻辑不被应用商店更新静默替换的交付方式。同一份 JavaScript 包在所有平台运行，可通过 SHA-384 哈希验证其一致性。
iOS 和 Android 上的 Web Crypto API
iOS 17+ 上的 Safari 17 完整支持 crypto.subtle：deriveKey、encrypt、decrypt、sign、verify。Android 上的 Chrome 自 37 版本（2014 年）起便提供此支持。两个实现都委托给操作系统原生加密原语——iOS 上的 CommonCrypto、Android 上的 BoringSSL——因此密码学运算受 ARM AES 指令硬件加速。Pixel 8 上加密一个 5 MB 数据块大约需要 15 ms。该 API 不向 JavaScript 暴露原始密钥材料（CryptoKey 对象是不透明句柄），有助于防范恶意扩展，而移动端浏览器的扩展安全问题远少于桌面端。
处理大文件而不耗尽内存
移动 Safari 在 6 GB 内存的 iPhone 上，JavaScript 堆约限制在 2 GB，旧设备更低。把文件整个读入 ArrayBuffer 再加密再上传的朴素模式，超过 1 GB 就会崩溃。流式处理是必须的：用 File.slice() 读取 5 MB 分块，用 HKDF 为每块派生子密钥加密，再通过带 ReadableStream 主体的 fetch() 上传。渐进式上传将峰值内存控制在 50 MB 以内，即使面对 10 GB 视频也如此。Chrome for Android 从 105 版本起支持流式 fetch 请求；Safari 在 17.4 版本中加入了完整支持。
电量与发热问题
AES-256-GCM 在硬件层面开销极低——ARMv8 的密码学扩展指令使其运行速度接近 DRAM 带宽。在 iPhone 14 Pro 上加密 1 GB 文件约消耗 2% 电量，且绝大部分来自上传的无线电模块，而非 CPU。用户真正感受到发热的是高迭代次数的 PBKDF2；120 万次迭代（OWASP 2024 建议值）耗时 700 ms，会使 A17 芯片短暂升至 90°C。将迭代次数调整为 60 万次可在安全性和发热之间取得平衡。Argon2id（m=32 MB）在持续工作时更温和，因为内存硬化带来的延迟分布更均匀，瞬时功耗密度更低。
移动网络与上传可靠性
移动端上传会中断。地铁隧道、电梯、从 Wi-Fi 切换到 LTE——这些场景都会终结一个朴素的 fetch()。完善的移动传输方案使用基于块级确认的断点续传协议，例如 tus.io（tus 1.0 规范，被广泛支持）或 S3 分片上传。每个 5 MB 块独立上传，失败只需重传该块。客户端将分块状态存入 IndexedDB，即使浏览器标签页重新加载或 iOS 将其驱逐，整个任务也不需要从头开始。SwissTransfer 和 HexaTransfer 都实现了断点续传；WeTransfer 的移动网页流程没有，这正是 2 GB 文件通过 LTE 上传经常失败的原因。
密码输入与用户体验难题
在手机键盘上输入 16 位强密码体验很糟糕。可提供替代方案：扫描发送方屏幕上的二维码（其中包含密码）、从原生密码管理器粘贴（iOS 通过 web 版的 .well-known/apple-app-site-association 等价机制从 Keychain 填充）、使用此前传输时注册的通行密钥。对于一次性场景，可使用 Web Share Target API 让 Signal 等配套应用注入密码，无需用户重新输入。
iOS Safari 的上传陷阱
iOS 上的 Safari 有几个需要注意的坑。iOS 16.4 之前，Fetch API 的上传进度事件不可靠。不支持 File System Access API，因此无法像 Chrome 那样从本地存储流式读取大文件。Safari 在内存压力下会主动驱逐不活跃的标签页，导致正在进行的上传中断。应对措施：将 XMLHttpRequest 配合进度事件作为回退方案（仍然可用），在上传过程中保持标签页在前台，并提示用户大文件上传时不要锁屏。保持屏幕常亮会消耗电量，但能防止标签页被驱逐。
Android 设备碎片化问题
Android 设备从 Pixel 8 Pro 到 80 美元的 Moto e14（运行 Android Go）应有尽有。Web Crypto 在所有设备上均可运行，但性能差异悬殊——搭载 MT6762（2 GHz）的设备完成 60 万次 PBKDF2 迭代需要 1.8 秒，而 Apple M3 级别的手机只需 200 ms。建议通过 Device Memory API 和 Hardware Concurrency 检测设备能力，动态调整迭代次数（Go 设备可降至 30 万次），并对纯蜂窝网络连接的用户提示 1 GB 以上的上传可能不稳定。这样做的价值在于：加密传输可在全球大多数手机上运行，而无需要求用户使用旗舰设备。
在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。