把文件拖进浏览器窗口，网页进度条走完，上传服务器返回一个链接——这就是软件网页上传软件最朴素的形态。2005年我做个人站长时，网页上传一个2MB的上传图片要等半分钟，还得装Flash插件。软件现在用Fetch API配合FormData，网页几行代码就能跑通，上传但背后的软件坑一点没少。

浏览器不是网页文件系统。用户选中的上传文件被封装成File对象，继承自Blob，软件只能通过FileReader或URL.createObjectURL读取。网页我见过有人直接把File塞进JSON.stringify，上传结果拿到一个空对象。软件正确的做法是用FormData包装，让浏览器自动设置multipart/form-data边界。下面这段代码我用了三年，没出过问题：

const fd = new FormData(); fd.append('file', fileInput.files[0]); fetch('/upload', {  method: 'POST', body: fd });

但真实场景远比这复杂。去年帮一个客户做后台，他们要求上传进度条、断点续传、大文件分片。进度条靠XMLHttpRequest的upload.onprogress事件，fetch到现在也没有原生支持。分片更麻烦——把文件切成5MB的块，每块单独上传，服务端合并。前端要计算哈希做秒传，浏览器里跑SparkMD5，一个1GB的文件算完哈希要十几秒，用户早关页面了。后来改用抽样哈希，只算头尾和中间几块，碰撞概率极低，速度提升到两秒内。

兼容性是个绕不开的话题。IE11还在某些内网环境活着，它不支持FormData.append传Blob，得用ActiveXObject或者Flash。2020年我维护过一个政府项目，客户坚持用IE，最后只能降级成iframe模拟异步上传，页面不刷新，但拿不到真正的进度。现在Chrome占了七成份额，Edge换Chromium内核后，情况好了很多，但Safari对File API的支持总慢半拍，比如input type=file的accept属性在iOS上经常被忽略。

安全方面，前端能做的很有限。文件类型校验靠MIME和扩展名，但都能伪造。我习惯在服务端用file命令查真实类型，或者读文件头魔数。图片上传还要防XSS，有人把.php改成.jpg传上去，服务端如果不检查就执行了。另外，上传目录绝对不能有执行权限，这是铁律。见过一个案例，攻击者上传了一个.htaccess文件，把.jpg解析成PHP，整个站就沦陷了。

性能优化有个小技巧：用Web Worker做文件切片和哈希计算，避免阻塞UI。还有，上传前压缩图片，canvas.toBlob可以指定质量参数，把5MB的JPEG压到500KB，肉眼几乎看不出区别。视频就算了，前端转码不现实，老老实实传原文件。

最后说个反直觉的观察：很多团队花大力气做上传组件，却忽略了服务端接收逻辑。Nginx默认client_max_body_size只有1MB，超过就返回413，前端进度条卡在99%然后报错。调大这个值，再配好PHP的upload_max_filesize和post_max_size，能省掉一半的调试时间。上传这件事，前端是面子，后端是里子，缺一个都跑不起来。