传输后文件损坏？如何防止数据丢失

在现代基于 HTTPS 的传输服务上，文件损坏在传输过程中很少发生，因为 TCP 校验和、TLS 1.3 完整性保护以及 AES-GCM 认证标签都能捕获传输中的位错误。当损坏确实发生时，问题通常出在端点：下载中断只写入了部分文件、写入时磁盘出错，或客户端 Bug 截断了数据流。用 SHA-256 哈希值比对两端文件，哈希相同说明文件完全一致，不同则重传。使用 AES-256-GCM 的服务提供内置认证，解密成功本身就是完整性的证明。

为什么传输过程中很少发生损坏

每一个 HTTPS 请求都带有 TLS 完整性校验。TLS 1.3 与 AES-256-GCM 或 ChaCha20-Poly1305 等 AEAD 密码套件配合，每条记录都会生成一个认证标签；如果传输途中发生位翻转，标签验证失败，记录在到达应用层之前就会被丢弃。TCP 在每个数据段上还有自己的 16 位校验和。两重保护下，静默损坏穿过的概率极低——光 TLS 这一层就约为 1/2¹²⁸。

未加密的协议（FTP、纯 HTTP）就没那么可靠了。TCP 校验和可能漏掉某些错误；中间设备内存不良时，位有可能静默翻转。这是除凭据泄露问题之外，避免用明文 FTP 传输大文件的另一个实际理由。

损坏实际上发生在哪里

传输后文件损坏的常见原因，按大致频率排序：

下载中断保存为残缺文件。 浏览器下载在 75% 时丢失连接，通常会保存一个 75% 完整的文件，在下载文件夹里看起来是"在的"但打开就坏了。Chrome 和 Firefox 现在通常会标记为 .crdownload 或 .part，但旧版本和部分第三方下载管理器不会。

本地磁盘写入错误。 外接硬盘故障、磁盘空间满或坏道，导致文件只写入了一部分。Windows 不总是清晰地报错；macOS 有时会。

防病毒软件将文件改动后隔离。 实时防病毒有时会在下载中途对可执行部分进行"清理"或修改压缩包，让文件在技术上还在那里，但逻辑上已经损坏。

客户端 Bug 截断数据流。 在维护良好的客户端上很少见，但部分旧版 FTP 客户端、老版本 SyncToy 或自定义上传脚本存在已知的截断 Bug。

用 SHA-256 哈希值验证

证明文件完整传输的唯一可靠方法，是在两端各计算一次加密哈希值并比对。SHA-256 通用性强、速度快（现代 CPU 在 AES-NI 加持下可达 500 MB/s），且抗碰撞。

macOS/Linux：shasum -a 256 file.mov。Windows 10+：certutil -hashfile file.mov SHA256。两个命令均输出 64 位十六进制字符串。将哈希值连同链接一起发送（"SHA256: a1b2c3..."），让收件人在下载后自行验证。

哈希值匹配，文件逐位完全相同；不匹配，重新传输。

AES-GCM 免费提供完整性保证

使用 AES-256-GCM（带关联数据的认证加密）的服务，在每个数据块中都包含认证标签。收件人解密时，标签验证失败意味着密文被篡改或损坏，解密会以"GCM 认证失败"之类的错误明确报错。

这意味着文件能成功解密，就保证了它未被修改。收件人不需要额外运行 SHA-256 校验。HexaTransfer、Smash 安全模式、SwissTransfer、Tresorit Send 和 Proton Drive 都使用 AES-GCM 或 XChaCha20-Poly1305（类似的认证模式），原因正在于此。

识别不完整的下载

不完整下载的典型特征：磁盘上文件的大小小于传输页面上标注的大小。右键下载的文件，检查大小，与发送方报告的大小比较。不一致就说明下载没有完成。

媒体文件容易暴露这个问题：残缺的 MP4 播放一分钟后截断；残缺的 ZIP 解压时报告"压缩包损坏"；残缺的 PDF 显示前几页后报错。文本文件往往看似能打开却在末尾被静默截断，这是最糟糕的情况，因为你不容易察觉。

为不稳定连接提供断点续传下载

如果收件人在下载途中断线，断点续传支持至关重要。HTTP 范围请求（RFC 7233）允许客户端从某个偏移量重新开始。curl 用 -C -，wget 用 -c，浏览器内置下载管理器的支持因版本而异：Firefox 和 Chrome 在服务器支持 Range 的前提下，同一会话内可续传。

只使用单次 POST 或不暴露 Range 头的服务，在下载中断时强制重头开始——对于 20 Mbps 蜂窝网络上的 10 GB 文件来说，体验极差。

防病毒软件干扰

Windows Defender、Avast、Bitdefender 和 McAfee 有时会在下载中途拦截进行扫描。通常这是透明的。偶尔对于压缩包或可执行文件，防病毒会决定"清理"文件，删除内容或将文件替换为隔离存根。

如果某个文件在收件人机器上持续下载损坏，让他们临时禁用实时防病毒后重试。如果重试成功，防病毒就是问题所在，把传输服务的域名加入排除列表。

磁盘空间和文件系统问题

目标磁盘在写入中途空间用完，也会导致下载损坏。macOS 通过 APFS 快照层写入，通常能清晰报错；Windows NTFS 更容易静默截断。在开始 10 GB 下载之前，先检查外接硬盘的可用空间。

文件系统 Bug 虽然罕见但真实存在。旧版 Windows 上的 exFAT 历史上存在超过 4 GB 文件的截断 Bug。当前系统版本的 ext4、NTFS 和 APFS 都是可靠的。

用特定工具验证文件格式

视频文件：ffprobe -v error file.mp4 静默报告错误，输出为空表示容器结构完整；更彻底的检查用 ffmpeg -v error -i file.mp4 -f null -，逐帧遍历并报告解码错误。

PDF：Acrobat 的"验证"命令检查对象结构；qpdf --check file.pdf 从命令行完成同样的事。

压缩包：unzip -t file.zip 和 7z t file.7z 在不解压的情况下测试，速度快，能发现大多数损坏。

选择内置完整性保证的服务

对于关键传输，选择通过设计提供加密完整性的服务。端对端 AES-GCM 加密、下载页面显示 SHA-256 哈希值，或客户端中的显式校验和验证，都能给你"证明"而不仅仅是"希望"。HexaTransfer 使用 AES-256-GCM，解密成功本身就验证了文件未被篡改，10 GB 每次传输上限覆盖大多数专业交付场景。

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