资源上传环节详情

资源上传环节，资源是上传整个系统里最不起眼却最容易翻车的地方。我见过太多项目，环节前期架构吹得天花乱坠，详情最后死在“传个文件”这一步上。资源

先讲个真实案例。上传上个月帮朋友排查一个内部工具，环节用户反馈“传大文件必失败”。详情查了半天，资源发现他们用的上传是老式表单提交，PHP默认上传限制2MB，环节前端连个进度条都没有——用户点了上传，详情页面转圈三十秒，资源然后弹出一个“服务器错误”。上传这不是环节技术问题，是设计问题。上传环节的体验，直接决定用户愿不愿意继续用你的产品。

上传的核心矛盾就两个：可靠性和反馈。可靠性指文件不能传一半丢，反馈指用户得知道“现在到底传没传完”。

先说可靠性。HTTP协议本身是无状态的，文件传一半断了，服务器不会自动续传。所以现代方案基本都走分片上传——把大文件切成几MB的小块，每块独立传，传完在服务端合并。这招对网络抖动特别管用，断网重连后只补传失败的碎片就行。但分片有个坑：切片大小和并发数的平衡。切太小，请求数量暴增，服务端压力大；切太大，单块失败重传的成本又高。我习惯按文件大小动态调整，10MB以下直接整传，超过10MB再走分片，每片定在4MB左右，并发控制在3个请求。这个组合在普通办公网络下表现最稳。

再谈反馈。进度条不是装饰品，它是用户焦虑的解药。但很多人做进度条只算了上传字节数，没算服务端处理时间。结果就是进度条卡在99%不动，用户以为卡死了，实际是服务端在写库。正确做法是，前端进度显示到95%就停住，等服务器返回最终确认再跳到100%。这多出来的5%，是给服务端留的“消化时间”。

还有个细节容易被忽略——文件校验。上传完成后，客户端得算一遍文件的MD5或SHA-1，跟服务端存完后再算的哈希比对。不一致就重传。别嫌麻烦，网络传输偶尔会丢字节，尤其大文件。我见过一个生产事故，用户传了个1.2GB的压缩包，下载解压时提示CRC错误，就是因为上传时少传了几个字节，而服务端没校验。

上传中的临时状态也得处理干净。文件传一半，用户取消了，或者浏览器崩了，服务端要能回收这些临时文件。不然隔几个月，磁盘被一堆残缺文件占满，运维半夜爬起来清盘，骂娘的心都有。解决方案很简单，给临时文件设个生命周期，比如24小时后自动清理。

最后说个反直觉的观察：很多人以为上传是网络问题，其实是服务器IO问题。文件先写磁盘还是先写内存，差别很大。小文件直接写磁盘没问题，大文件最好先落内存缓冲，再异步刷盘。不然并发一高，磁盘忙不过来，上传请求全排队，前端等得花儿都谢了。我见过最狠的做法，是把上传服务单独拆出去，跟业务服务器物理隔离，这样即使上传量大爆炸，也不影响主站接口响应。

上传这活儿，看着简单，实则每个环节都得抠细节。分片大小、并发数、进度计算、校验策略、临时清理，哪一步没想清楚，线上迟早给你颜色看。别信“上传就是调个接口”那种鬼话，真踩过坑的人，都知道这里水深得很。