文件传到99%突然卡住，上传上传进度条不动了。出错刷新页面，重新提示“上传出错，上传上传请重新上传”。出错那一刻真想砸键盘。重新

上周给客户传一个1.2G的上传上传设计稿，用的出错某网盘网页版。前三次都在90%多的重新时候断掉。第一次我以为是上传上传网络波动，重试。出错第二次换了浏览器，重新还是上传上传断。第三次我盯着进度条，出错发现它走到97%时突然跳回0，重新然后弹出红色感叹号。后来查了日志，发现是服务端在接收完文件后做校验时超时，直接把连接掐了。客户端以为没传完，但服务器那边其实已经收到了完整文件，只是没返回成功信号。这种情况重新上传就是白费流量。

很多人遇到“上传出错”第一反应是骂自己网差。不全是。我统计过自己近半年的上传失败案例，大概四成出在服务端。比如某次传视频到协作平台，文件明明只有800M，服务器却返回“413 Request Entity Too Large”。查了文档才发现，那个接口单文件限制是500M，但前端没做拦截，非要等你传完才告诉你超了。这种设计挺坑人的。

还有一种更隐蔽的：分片上传时，某一片丢了。客户端以为传完了所有分片，服务端合并时发现缺了一片，于是整个任务失败。你重新上传，它又从第一片开始传。我试过用开发者工具看网络请求，发现第37片（每片5M）返回了500错误，但前端没重试那片，直接标记整体失败。手动重传那一片？普通用户根本没这入口。

那怎么办？我的习惯是，先别急着点“重新上传”。打开浏览器F12，看Network面板。如果看到某个请求状态是(failed)或者pending很久，记下它的URL和参数。有时候手动构造一个PUT请求把缺失的分片补上去，比整个重传快得多。当然这需要一点技术底子。普通用户的话，换个上传方式更实际——比如用客户端而不是网页，或者用支持断点续传的工具。我后来把那个1.2G的文件切成三个400M的压缩包，分三次传，一次都没失败。虽然麻烦，但比反复卡在99%强。

服务端的问题用户改不了。但你可以改自己的策略。别跟一个不稳定的接口死磕。我现在的做法：超过200M的文件，先看平台有没有专用上传工具；没有的话，自己切分；切分后如果还失败，换网络环境（比如从WiFi切到手机热点）再试一次。通常换IP能绕过某些服务端的限流或缓存问题。上次传一个报错“server重新上传”的PDF，切到热点后一次过。服务端那边可能只是某个节点抽风，换个入口就正常了。

说回开头那个设计稿。最后我是用命令行工具curl分片传的，每片传完等两秒再传下一片，避开服务端的并发限制。传完花了十一分钟，比网页版反复重试半小时强。上传出错不一定是你的错，但重新上传之前，先想想有没有更聪明的办法。别让一个红色感叹号浪费你一晚上。