.NET程序员的20G文件上传历险记
大家好，我是甘肃的一名苦逼.NET程序员，最近接了个外包项目，客户的需求简直是要我老命啊！来给大家扒一扒这个"价值连城"的项目需求：
项目需求：地狱级难度
- 大文件上传：20G！不是20M也不是2G，是20G！想想我的小水管服务器就瑟瑟发抖
- 兼容性要求：从IE8到现代浏览器全都要支持 - “总不能把业务机器扔掉吧”，客户原话
- 文件夹结构保留：用户上传的文件夹可能有1000个分类文件，还得保持层级
- 断点续传：关了浏览器、重启电脑都不能丢进度 - 这得用上黑魔法吧？
- 加密要求：SM4、AES全都要，传输存储都要加密
- 预算：100元以内！还要求7×24小时技术支持、源代码、打包部署一条龙…
技术选型：在夹缝中求生存
既然客户点名要WebUploader或原生JS，预算又这么"慷慨"，我只能选择…
// 前端伪代码 - 用生命在兼容IE8varie8Flag=/*@cc_on!@*/false;// 判断IE8的黑魔法if(ie8Flag){alert("亲，您还在用IE8啊？给您磕头了！");// 这里要写一堆ActiveX和VBScript的兼容代码}else{// 现代浏览器可以用File API}文件夹上传的坑
网上找的代码大多只支持文件上传，文件夹上传保留层级结构？自己造轮子吧！
// 后端C#处理文件夹结构的伪代码publicvoidHandleFolderUpload(HttpPostedFilefile,stringrelativePath){// relativePath是前端传来的文件夹相对路径stringserverPath=Path.Combine("E:\\Uploads",relativePath);Directory.CreateDirectory(Path.GetDirectoryName(serverPath));file.SaveAs(serverPath);// 预算只够写伪代码了，真实项目这里还要处理各种异常}断点续传实现思路
- 前端分片计算文件哈希作为唯一标识
- 后端记录已上传的分片信息
- 用户中断后重新上传时，先查询已上传分片
// 前端断点续传逻辑functionresumeUpload(file){calculateFileHash(file).then(hash=>{$.get("/api/upload/progress?hash="+hash,function(data){// data返回已上传的分片列表uploadRemainingChunks(file,data.uploadedChunks);});});}加密传输方案
// C# SM4加密示例（简化版）publicstringSM4Encrypt(stringinput,stringkey){// 这里应该是复杂的SM4算法实现// 但预算只够写个伪代码...return"加密后的"+input+"（假装加密了）";}现实与理想的差距
客户：“这个功能很简单吧，几天能做完？”
我：（内心OS）几天？给我几个月还差不多…
表面：“这个…我需要评估一下技术可行性…”
给同行们的忠告
- 接单前一定要评估需求合理性
- IE8支持真的是个大坑，能推就推
- 文件夹上传保留层级不是那么简单
- 100元预算做这种需求…不如去要饭
最后说点掏心窝子的话：
各位同行啊，咱们程序员也要硬气一点。这种明显不合理的需求，要么加钱，要么拒绝。别为了接单把自己逼到绝路。
至于那个QQ群广告…咳咳，大家自己判断吧。反正我是不信什么"2万项目提成1万"的好事。真有这种好事，他们为什么不自己接单呢？
最后的最后：如果你真的非要做这个项目，我建议：
- 先和客户重新谈需求和预算
- 实在不行就用现成的商业解决方案（虽然超预算）
- 真要自己实现，做好加班到秃顶的准备
祝你好运吧，甘肃的程序员兄弟！
设置框架
安装.NET Framework 4.7.2
https://dotnet.microsoft.com/en-us/download/dotnet-framework/net472
框架选择4.7.2
添加3rd引用
编译项目
NOSQL
NOSQL无需任何配置可直接访问页面进行测试
SQL
使用IIS
大文件上传测试推荐使用IIS以获取更高性能。
使用IIS Express
小文件上传测试可以使用IIS Express
创建数据库
配置数据库连接信息
检查数据库配置
访问页面进行测试
相关参考：
文件保存位置，
效果预览
文件上传
文件刷新续传
支持离线保存文件进度，在关闭浏览器，刷新浏览器后进行不丢失，仍然能够继续上传
文件夹上传
支持上传文件夹并保留层级结构，同样支持进度信息离线保存，刷新页面，关闭页面，重启系统不丢失上传进度。
下载完整示例
下载完整示例
