上传卡在 99%，剩下的 1% 到底在等什么？

关注

原创最新推荐文章于 2026-11-09 16:08:36 发布 127 阅读 AI 写同款· GEO 优化 ›

一个视频传了几十秒，进度到了 99%。你把手机放下，回了两条消息，再回来，还是 99%。

这时候最难受的是没有合适的动作。退出怕前功尽弃，重试怕生成两份，只能盯着最后那一点空白。

进度条很像一个承诺：还差一点就好了。但这“一点”究竟代表剩余数据，还是服务器还没处理完，光看百分比并不知道。

上传过程中，客户端能在不同位置统计进度。

有的统计从本地文件读取了多少，有的统计交给网络层多少字节，也有的展示服务端已经确认接收的数据量。这些数字都可能递增，但含义不同。

文件已经读完，不等于全部离开手机；数据交给网络层，也不等于服务器已经确认收到。即使传输完成，业务可能还在做后续处理。

因此，进度显示到 100%，只说明它所统计的那个阶段完成了。这个阶段是不是“文件已经可用”，要看产品怎么定义。

有些页面会把最后一点进度留给完成确认，等整个任务结束后再补到 100%。这样能避免提前显示成功，却也容易让不同阶段的等待全部堆在 99% 上。并不是所有卡在 99% 的上传都用了这种设计，具体原因仍需记录确认。

假设上传的是一个较大的视频，服务端可能要检查文件完整性、合并分片、保存文件，再进行转码。

这些步骤不一定都存在，也不一定要在同一个请求里完成。有的服务先确认上传结束，再异步处理；有的产品会等到内容可以播放才向用户显示最终成功。

从用户角度看，都叫“上传”。从排查角度看，至少应该把数据传输和后续处理分开。

如果数据早已收齐，瓶颈是转码排队，再怎么调手机网络都不会让它立即完成。反过来，最后几块数据仍在重传，也不能把它解释成服务器正在处理。

页面可以直接显示“文件上传完成，正在处理”。如果没有可靠的剩余时间，就说明当前阶段，不必编一个永远只剩一秒的倒计时。

还有一种情况更隐蔽：服务端已经把文件存好了，成功响应却在返回途中遇到网络问题。

客户端看到的是超时，服务端看到的是完成。用户点重试后，如果系统创建了一个全新任务，列表里可能出现两份相同文件。

这时仅仅延长超时不一定有用。客户端需要能够查询原任务，确认它是仍在上传、已经完成，还是确实失败。结果暂时未知时，页面也不该急着断言“上传失败”。

任务需要一个稳定身份。重试仍然对应原来的上传，客户端与服务端才有机会对上账。文件名通常不足以承担这个身份，同名文件可能不同，同一个文件也可能被用户有意上传两次。

百分比只告诉你数量，没告诉你哪些数据已经被可靠接收。

顺序上传可以记录服务端确认的位置；分片上传可能记录已完成的分片。无论哪种方式，恢复时都需要按照协议核对服务端状态，不能只相信手机关页面前留下的那个 70%。

例如 tus 断点续传协议允许客户端查询服务端当前接收偏移量，并从双方确认的位置继续发送。这展示了续传需要的基本配合：客户端询问，服务端确认，随后接着传。tus 断点续传协议

还要确认选中的仍然是原文件。用户在暂停期间修改了内容，继续拼接可能得到错误文件。上传任务也可能已过期，或者当前账号不再有权限。

所以断点续传不是“把进度条恢复到上次的位置”。它得保证剩余内容接在正确的数据后面，最后形成完整文件。

不一定。

如果界面之前显示的是已发送量，恢复后改用服务端确认量，数字可能回退一点。某一部分数据需要重新传输，也可能是恢复机制的正常成本。

真正该追问的是：回退有没有依据，是否只重传了必要部分，以及之前已经确认完成的数据有没有被无故放弃。

可以把显示进度和验收标准分开。界面需要让用户理解当前状态；测试则应检查实际重复传输了多少、最终内容是否正确。单纯要求数字永不下降，可能反而鼓励页面藏起真实进度。

如果传了很久后必须从头开始，也应说明原因。例如任务过期或本地文件已变化，比让进度突然归零更容易理解。

中途断网值得测，但最后几个阶段往往更容易漏。

其中“服务端已经完成但确认未到达”，仅靠客户端定时断网不容易精确命中。最好结合服务端记录或受控测试端点，确认本次确实停在了这个位置。

退到后台和进程被结束也要分开。前者可能继续运行，后者更依赖持久化任务信息和平台调度能力。如果产品没有承诺后台继续上传，至少应保证重新打开后的状态准确。

最后别忘了检查文件本身。列表里出现一条记录，只能说明有记录；内容是否完整、能否读取或播放，还需要验证。