几百兆的文件传到一半断了：跨设备传输为什么会中断

断的往往不是网络，是连接

先把现象说准，因为它容易被归错因。典型的情况是这样的：小文件传得又快又好，一旦文件到了几百兆这个量级，传输就容易在中途失败；网络本身没有任何异常，重试一次可能成功，也可能又断在别的位置。

如果真是网络断了，那么同一时刻你的网页也该打不开、视频也该卡住。但通常没有。断掉的不是网络，是两台设备之间那条连接——而且往往是其中一端主动断的。

为什么一端会主动掐断一条正在传输的连接？这就要从跨设备连接怎么判断对方还活着说起。

任何一条长连接都面临同一个问题：怎么知道对面还在？TCP 连接在对方断电、崩溃或走出网络覆盖时，不会立刻通知你，socket 可以在那儿静静挂着好几分钟。所以跨设备工具都要自己发心跳：一端定期发一个探测包，另一端应答，超过一段时间收不到应答就判定连接已死，断开重连。

坑就在这里。心跳包和文件数据走的是同一条 TCP 连接、排在同一个发送队列里。传一个 500 MB 的文件时，队列里塞满了数据块，而心跳排在它们后面。于是：

结果就是那个让人费解的现象：连接是因为「太忙」而被判定为「已死」。数据流量越大、网络越紧张，心跳越容易被挤在后面，也就越容易断——这解释了为什么小文件从不出问题，大文件反复失败。

另一类失败发生在发送端自己身上。一个看起来很自然的写法是：把文件读进内存，然后交给网络层去发。文件小的时候这没问题，文件大了就会出事——磁盘的读取速度远快于 Wi‑Fi 的发送速度，读得比发得快，中间的差额全部堆在内存里。

几百兆的文件配上这种写法，内存占用会一路涨上去。移动端的系统对后台应用的内存有硬性限制，超了直接被系统终止——表现在用户这边，就是「传着传着应用没了」或者「传输莫名失败」。

正确的做法叫背压：把文件切成小块，发完一块、确认发送完成，再去读下一块。读取速度被发送速度反向约束住，内存占用是恒定的，不管文件是 50 MB 还是 5 GB。这个写法看起来慢一点，但它是唯一能扛住大文件的写法。

中断本身很讨厌，但真正危险的是中断之后的状态。这里有三种可能，而它们的差别很大：

处理方式	你拿到的东西	风险
不校验，直接落盘	一个大小不对的文件，看起来是正常的	最危险：视频播到一半黑屏、压缩包解不开，而你以为传成功了
校验字节数，短了就丢弃	明确的失败提示，没有文件	要重传，但不会有假成功
校验内容哈希	确认内容与源文件逐字节一致	最稳妥

第一种是最该避免的。一个残缺但存在的文件，比一个明确的失败更糟——你会以为备份已经完成，然后把手机上的原件删掉。等到几个月后打开发现文件坏了，原件早就没了。

所以评估一个传输工具时，值得专门试一次：传大文件时中途切断网络，看它给你的是一个报错，还是一个半截文件。

上面两类原因，我们都是针对性处理过的——不是因为预见得早，而是因为都撞过：

心跳有优先权。链路拥塞时，宁可丢弃画面帧也不让探测包排在后面饿死。判死的时间链也留足了余量：手机每 5 秒发一次心跳，15 秒收不到应答才判死，Mac 侧 20 秒才收割连接——三个数字之间的间隔是算出来的，不是拍脑袋定的。
应答不排队等主线程。Mac 端的心跳应答直接在传输队列里就地完成，不经过主线程。否则 Mac 一忙，应答就迟到，手机那边就会误判。
逐块背压。文件切成不超过 256 KiB 的块，发完一块确认之后才读下一块。内存占用与文件大小无关，不限制文件体积。
字节数与哈希双重校验。接收方核对累计字节数必须与声明的大小完全一致，否则丢弃并明确报告失败——不产生半个文件。还可以进一步用内容哈希校验。
连接断了会自己回来。网络抖动、切换 Wi‑Fi、电脑短暂离开之后，连接按预设节奏自动重建，不需要你手动收拾，详见断线重连是怎么工作的。

需要如实说明一处限制：我们目前没有断点续传。传输中断后需要重新开始，而不是从断点接上。我们优化的是「不容易断」和「断了不会给你半个文件」，不是「断了能接上」。这个能力还没做。

无论用哪个工具，这几条都能明显降低失败率：

关于不同传输方式的选择，可以继续看HarmonyOS 与 Mac 互传文件；各类工具的能力边界见Mac 与鸿蒙同步工具选型。

关于灵犀互联

投屏、文字剪贴板、文件与相册，通过一条本地连接协同。