去年帮一个朋友修他那个老掉牙的企业站，后台传图片永远卡在99%，服务器上临时文件夹里全是半截文件。他问我是不是ASP太老了该换了。我说你先别急着换语言，把上传大小限制改改看。结果改完web.config里那行maxRequestLength，问题没了。这事儿让我觉得有必要把ASP上传这件事从头捋一遍——不是教科书那种捋，是踩过坑的那种。

ASP上传的核心其实就一句话：客户端把文件塞进HTTP请求体，服务端从请求流里把二进制数据抠出来。听起来简单，做起来全是细节。早期经典ASP没有内置的上传组件，大家用Request.BinaryRead配合Request.TotalBytes手动解析。那段代码我至今记得，要自己找boundary分隔符，要处理回车换行，还得小心别把文件头和尾搞混。写一次就不想写第二次。

后来ASP.NET出来了，FileUpload控件把这事封装得挺舒服。但舒服归舒服，坑一个没少。最典型的就是那个maxRequestLength，默认4MB。你传个手机拍的照片都可能超。更气人的是，超了之后页面直接抛异常，用户看到的是一屏黄页，体验极差。我习惯在global.asax里抓Application_Error，判断是不是超长请求，然后跳到一个友好提示页。这招不优雅，但管用。

还有个容易被忽略的点：上传目录的权限。IIS那个应用程序池账户，默认是ApplicationPoolIdentity，对网站根目录下的文件夹往往只有读权限。你代码写得再对，文件就是写不进去。我见过有人折腾一下午，最后发现是NTFS权限没给写。解决办法要么给文件夹加写权限，要么把上传目录放到网站根目录外面，用虚拟目录映射。后者更安全，推荐。

大文件上传是另一个战场。ASP.NET默认把整个请求体缓冲到内存或临时文件，传个500MB的视频，服务器内存直接爆。这时候得用流式处理，或者干脆上分片上传。分片上传的思路不复杂：前端把文件切成2MB一块，逐块POST，服务端按序号拼接。但实现起来要考虑断点续传、并发控制、临时文件清理。我做过一个项目，用户传4GB的数据库备份，就是用分片加MD5校验，传完再合并。那套代码现在还在用。

安全方面，别信客户端验证。什么accept属性、JavaScript检查扩展名，都是纸糊的。服务端必须重新检查文件类型——不是看扩展名，是看文件头魔数。有人把.asp改成.jpg传上来，你要是直接按原名保存，服务器就等着被挂马吧。我习惯把上传的文件重命名为GUID，扩展名根据魔数白名单映射，比如JPEG就存成.jpg，其他一律拒绝。上传目录还要禁用脚本执行权限，IIS里配置一下请求筛选，双保险。

最后说个真实案例。某次帮人排查一个上传后图片显示不全的问题，代码看着没问题，文件大小也对。后来发现是Response.BinaryWrite输出时没设置Content-Length，浏览器按默认长度截断了。加上Response.AddHeader("Content-Length", file.Length.ToString())就好了。这种问题查起来费劲，但知道了就很简单。

ASP上传这事，说到底是跟HTTP协议和服务器配置打交道。语言本身不复杂，复杂的是边界情况和安全细节。把限制调大、权限给对、类型验严、大文件分片，基本就能覆盖九成场景。剩下的那一成，靠日志和耐心。