凌晨两点，传文我盯着浏览器里那个转圈的服务菊花图标，心里骂了句脏话。传文一个 2.3GB 的服务压缩包，上传到第 87% 的传文时候断了。这破网，服务又白等半小时。传文

后来我才琢磨明白，服务问题不在网，传文在我写的服务上传代码。那会儿我刚学前端，传文以为上传文件就是服务把 input 的 value 往 FormData 里一塞，然后 fetch 发出去就完事儿。传文太天真了。服务真实世界的传文网络，比你家楼下的早高峰还堵，还爱闹脾气。

web 上传文件，本质就一句话：把用户硬盘上的二进制数据，通过 HTTP 协议，搬到服务器磁盘上。但这句话背后藏着无数细节。你拿手机拍张 4K 照片，8MB，走 4G 网络，理论上几秒钟就完。可你要是传一个视频工程文件，20GB，那就不叫上传了，叫搬运。

我踩过最大的坑，是没处理大文件的分片。那会儿给一个剪辑软件做 web 版配套工具，用户得把素材传回服务器做云端渲染。第一次测试，同事扔了个 15GB 的 ProRes 视频进来，浏览器直接卡死，内存飙到 3GB。我没辙，只能查资料，最后用了分片上传——把文件切成 5MB 一块，每块独立发请求，服务器收到后按序号拼起来。这一改，内存占用跌到 200MB 以下，而且断了能续传，不用从头再来。

分片有个附带好处：能显示真实进度条。别小看这个 UI 细节。用户看到 45% 慢慢涨，心里踏实；你让他盯着一根静止的蓝条，他十有八九会刷新页面，然后你的上传进程就断了——因为你没做断点续传。

说断点续传，就得提一嘴文件指纹。我用 SparkMD5 算文件哈希，把每片的序号和哈希值存到 localStorage。下次用户重新拖同一个文件进来，先比对指纹，再从上次断掉的那片接着传。这招土，但管用。有个用户传了 6 个小时的素材，中途网断了三次，最后一次连上后居然从 92% 接着跑，他在工区群里发了三个抱拳表情。

服务器那头也别闲着。我见过有人用 Node.js 的 multer 一把梭，接收完整文件，内存直接爆炸。正经做法是流式写入——用 busboy 或者 formidable 把请求体里的数据一块块往磁盘上淌，边收边写。我后来用 Go 重写了接收端，io.Copy 一行代码搞定，但底层原理一样：别等数据全到内存里再动手。

还有个容易忽略的坑：文件类型校验。前端用 accept 属性筛掉 .exe，但那是给用户看的，防君子不防小人。真正的检查在服务端——读文件头的魔数，比如 JPEG 开头是 FFD8FF，PNG 是 89504E47。光看扩展名不靠谱，改名谁不会？

传完文件不算完事。你得给用户一个反馈——要么是下载链接，要么是预览页面。我习惯在服务器处理完后，返回一个带过期时间的临时 URL，用户点开能直接看渲染好的视频。这步做不好，前面全白搭。用户不知道你后端费了多大劲，他只关心结果能不能用。

现在每次写上传功能，我都会想起那个凌晨的菊花图标。技术方案选对了，用户根本感觉不到网络的存在。他拖个文件，喝口咖啡，回来一看，进度条满了——这才是上传该有的样子。