SSM个人网盘系统毕业设计：文件上传下载与秒传实现全攻略

简介一套基于SSM框架的个人网盘系统毕业设计资料包面向计算机相关专业毕业生及需要快速上手云存储项目的开发者。资源内含完整毕业论文与可运行程序源码论文依次覆盖绪论、开发工具、可行性分析、系统功能设计、数据库逻辑与物理结构设计、各功能模块详细实现及系统测试完整呈现从需求到交付的开发脉络源码中实现了用户注册登录、主控页面、文件夹创建、文件分享、回收站及下载等典型网盘业务可作为毕设参考、答辩演示或二次开发蓝本。压缩包共1683个文件约77.21MB包含大量png、html、css、js前端资源以及jar、class、java等后端源码与依赖另附SQL数据库脚本整体目录结构清晰便于在IDEA中导入运行与学习。目前已有1920人学习下载是实践性与规范性兼备的实用资源。1. 云存储毕业设计基于SSM个人网盘系统这个题目到底在考察什么“云存储毕业设计基于SSM个人网盘系统”几乎是每年毕设流传最广的题目形态之一后端框架固定为 SSMSpring SpringMVC MyBatis交付物是论文加程序源码核心是一个能上传、下载、管理文件的个人网盘。很多同学一看“云存储”三个字就被唬住以为要上分布式、要买服务器集群其实把它拆开看就是一个带文件树的 Web CRUD 系统难点不在算法而在文件流处理和表结构设计。它适合有点 Java 基础、但还没独立做过完整项目的人用来打底也能让想冲高分的同学在秒传、断点续传、OSS 接入这些点上做出亮点。我下面按自己带毕设的惯用方案把这个题目拆成可以直接照着建库、写代码、答辩的完整链路。2. 个人网盘系统的数据库建模三张表撑起整个 SSM 毕设2.1 功能清单先砍到能毕业用户、目录、上传、下载、秒传就够了拿到这个题目第一反应是“网盘什么都要有”回收站、分享、多人在线编辑、文件夹压缩下载、网速限流……如果照着商业网盘做三个月都写不完。我的建议是砍功能砍到能自圆其说、能在答辩现场跑通、又比普通 CRUD 多那么一点点。最稳的组合是五个功能注册登录、目录树管理新建文件夹、重命名、删除、文件上传、文件下载、秒传。分享链接可以做成加分项但不要放在核心依赖上。目录树管理很容易被误解成“文件夹就是数据库里的一条记录”实际也确实是不过它要和页面上展示的层级关系对应好。个人网盘不适合用递归做得很深默认支持两层就好根目录下是文件夹和文件文件夹里再放文件。这样前端渲染简单数据库查询也只有一个 parentId 就能解决。上传时如果没有指定父目录默认落到根目录新建文件夹时插入一条 is_dir1 的记录拿到返回的 id 作为下次上传的 parentId。这里需要想清楚一个问题文件上传后到底存哪里在我的方案里数据库只存目录树和文件元数据真正的文件二进制内容放到服务器磁盘的一个专用目录二者通过 filePath 字段关联。这样的好处是论文里可以写“存储逻辑与业务逻辑分离”坏处是删除文件时容易漏掉磁盘上的实体文件这会在后面避坑章节重点说。2.2 数据库表设计user、file_info、share 三张表的建表 SQL网上很多 SSM 网盘项目会把文件表设计成树形结构然后用 parent_id 关联自身这没问题。我更推荐再加一个 file_path 字段存物理路径因为 MyBatis 写递归查询比较麻烦直接从磁盘映射拿文件反而好调试。下面是我惯用的建表 SQLCREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(64) NOT NULL COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT MD5 加盐后的密码, salt VARCHAR(32) DEFAULT NULL COMMENT 盐值, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE file_info ( id BIGINT NOT NULL AUTO_INCREMENT, user_id INT NOT NULL, parent_id BIGINT DEFAULT 0 COMMENT 父目录 id0 表示根目录, file_name VARCHAR(255) NOT NULL COMMENT 用户看到的文件名, file_path VARCHAR(512) DEFAULT NULL COMMENT 磁盘物理路径目录为空, file_size BIGINT DEFAULT 0, file_type VARCHAR(64) DEFAULT NULL COMMENT 文件扩展名目录存 dir, md5 VARCHAR(64) DEFAULT NULL COMMENT 文件内容 MD5, is_dir TINYINT DEFAULT 0 COMMENT 1 为目录, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_parent (user_id, parent_id), KEY idx_user_md5 (user_id, md5) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE share ( id BIGINT NOT NULL AUTO_INCREMENT, file_id BIGINT NOT NULL, user_id INT NOT NULL, share_code VARCHAR(16) NOT NULL COMMENT 提取码, expire_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_share_code (share_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明密码字段我用 64 位是因为 MySQL 的 MD5 函数输出 32 位但我们要在 Java 里做“MD5 随机盐”拼接后长度可能到 56 位留点余量。file_name 用 varchar(255) 对多数文件没问题如果遇到特别长的文件名上传时要裁剪。file_type 不要用文件名的最后一个点号去猜很多文件名没有扩展名建议保存时统一小写空扩展名给一个 unknown。md5 字段建了联合索引但没做唯一约束原因是不同用户上传同内容文件时秒传只对当前用户生效全局唯一会带来跨用户删除时引用计数的麻烦。2.3 存储目录规则物理路径不要和用户文件名绑死常见做法是在服务器上建一个固定目录作为存储根比如/data/disk或E:/disk_data下面按用户 id 分一级目录再按年月分二级目录。最终一个文件落盘后的路径是这样拼出来的/data/disk/{userId}/{yyyyMM}/{uuid}{ext}这个规则里最关键的一点磁盘文件名用 UUID而不是用户上传时原来的文件名。原因有两个。第一重名文件会互相覆盖比如用户先传一个2024总结.pdf删掉后再传另一个内容完全不同的2024总结.pdf如果磁盘也按这个名字存第二次上传就会把旧文件覆盖。第二中文文件名和特殊字符在 Linux 文件系统上虽然能创建但在下载响应头里处理很麻烦还可能被攻击者利用做路径拼接。那么用户看到的文件名怎么保留存在 file_info 表的 file_name 字段里。数据库记录的是“用户视角”磁盘路径是“物理视角”两者通过 file_path 关联。客户端下载时我们读 file_name 写进 Content-Disposition 响应头而磁盘读取只用 file_path 字段这样就把展示和存储彻底解耦了。这也是答辩时一个很容易被老师追问的设计点答好能在“你将每个细节都想过”上加分。目录记录不需要物理路径is_dir1 的记录的 file_path 置空file_size 置 0。查询时前端传一个 parentIdMyBatis 返回这个父目录下的全部子节点后端按 is_dir 排序即可。整个逻辑就是一张自关联表没必要用左右值嵌套模型。3. SSM 核心实现上传、下载、秒传、目录操作的最小可跑代码3.1 工程结构按 SSM 三层拆controller/service/mapper 一个都不能少SSM 个人网盘的代码结构并不复杂优先保证分层干净因为老师的第一页代码就是看包名和类的职责。我的习惯是 controller 里不写业务逻辑只做参数接收和结果包装service 里处理文件流、事务和存储策略mapper 层只对表做增删改查。包结构如下com.example.disk ├── controller │ ├── UserController.java │ └── FileController.java ├── service │ ├── FileService.java │ ├── StorageService.java │ └── impl │ ├── FileServiceImpl.java │ └── LocalStorageServiceImpl.java ├── mapper │ ├── UserMapper.java │ ├── FileMapper.java │ └── FileMapper.xml ├── entity │ ├── User.java │ └── FileInfo.java └── common ├── Result.java └── BizException.javaspring-mvc.xml 里要开启注解驱动、静态资源放行、上传解析器。上传解析器是 SSM 网盘最容易配置错的地方很多项目忘了配或者配得太小前端一传大文件就报 500。最小配置如下context:component-scan base-packagecom.example.disk / mvc:annotation-driven / mvc:resources mapping/static/** location/static/ / bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namemaxUploadSize value104857600 / property namedefaultEncoding valueUTF-8 / /bean注意这个 maxUploadSize 的单位是字节104857600 就是 100MB。如果你打算演示上传 1GB 的大文件光调这个还不够还得留意 Tomcat 的 maxSwallowSize否则上传中断时会在控制台看到 Connection reset 的报错。这一点放到避坑章节展开。3.2 MultipartFile 上传接口先落临时文件再算 MD5别对着流反复读上传接口的常规思路是拿 MultipartFile 直接转储到目标目录但为了做秒传我们必须在落盘前算出文件内容的 MD5。很多人会写成先 file.getInputStream() 算一次 hash再 file.transferTo(dest) 写一次盘。这个做法在大部分 Tomcat 环境下能跑但某些容器里 MultipartFile 的输入流不支持重复读取会莫名其妙丢数据。我更推荐下面这种“先临时文件、再正式转存”的写法RequestMapping(/upload) ResponseBody public Result upload(RequestParam(file) MultipartFile multipartFile, RequestParam(value parentId, defaultValue 0) Long parentId, HttpSession session) { Long userId (Long) session.getAttribute(userId); String originalFilename multipartFile.getOriginalFilename(); if (originalFilename null || originalFilename.length() 0) { throw new BizException(文件名不能为空); } // 1. 先保存到系统临时目录 File tempFile File.createTempFile(upload_, .tmp); multipartFile.transferTo(tempFile); // 2. 基于临时文件算 MD5 String md5; try (InputStream in new FileInputStream(tempFile)) { md5 DigestUtils.md5DigestAsHex(in); } // 3. 查当前用户是否已存在相同内容文件 FileInfo exist fileMapper.selectByUserAndMd5(userId, md5); if (exist ! null) { insertFileRecord(userId, parentId, originalFilename, null, multipartFile.getSize(), md5, 0); tempFile.delete(); return Result.ok(秒传成功); } // 4. 正常存储得到物理路径后写一条 file_info String physicalPath storageService.store(tempFile, userId, originalFilename); insertFileRecord(userId, parentId, originalFilename, physicalPath, multipartFile.getSize(), md5, 0); tempFile.delete(); return Result.ok(上传成功); }逻辑说明第一步为什么不用 transferTo 直接存到最终目录因为最终路径要依赖 MD5 和存储策略来确定先用临时文件隔离“接收请求”和“持久化存储”两个阶段只要正式转存时报错临时文件可以随时删不会在网盘目录里留半截脏文件。第二步算 MD5 读的是磁盘文件不是 MultipartFile 的流彻底避开了流不可重复读的问题。第三步用 userId md5 查重查到了只加一条记录不上传实体没查到就走正常存储。参数说明File.createTempFile 生成的临时文件在系统临时目录Linux 下是 /tmpWindows 下是 %TEMP%要确保目录有足够空间如果网盘单文件上限是 100MB临时文件也需要同样的磁盘配额。insertFileRecord 方法里目录记录的 file_path 传 null文件记录才传 physicalPath。这里还要注意 originalFilename 里的路径信息有些浏览器旧版本会传 “C:\fakepath\xxx”只取最后一次分隔符后的部分。3.3 下载与预览用 response 输出流别把整个文件读进内存下载接口的错误实现是把文件读成 byte[] 再通过 ResponseEntity 返回比如 ByteArrayResource。这在 10MB 的小文件上没问题但你演示的时候不可能只传小文件一旦文件 500MBJVM 堆直接被打爆。正确做法是拿到磁盘 File 后用 InputStream 往 HttpServletResponse 的输出流里写同时用 IOUtils.copy 做流拷贝。RequestMapping(/download) public void download(RequestParam(fileId) Long fileId, HttpServletResponse response, HttpSession session) { Long userId (Long) session.getAttribute(userId); FileInfo info fileMapper.selectByIdAndUser(fileId, userId); if (info null || info.getIsDir() 1) { response.setStatus(404); return; } File file new File(info.getFilePath()); if (!file.exists()) { response.setStatus(404); return; } response.setContentType(application/octet-stream); response.setHeader(Content-Disposition, attachment;filename URLEncoder.encode(info.getFileName(), UTF-8)); response.setContentLengthLong(file.length()); try (InputStream is new FileInputStream(file); OutputStream os response.getOutputStream()) { IOUtils.copy(is, os); os.flush(); } catch (IOException e) { log.error(download failed, fileId{}, fileId, e); } }核心点有两个第一个是查询时带上 userId防止用户越权下载别人网盘里的文件这是我见过最多的安全漏洞一套代码里所有涉及 file_id 的接口都必须做这个判断。第二个是文件名编码URLEncoder.encode 在浏览器里会把空格变成 “”严格来说应该用 ContentDisposition 的 filename* 参数但对毕设演示已经够了重点是不要直接把文件名拼到 header 里那是真会乱码的。如果要支持图片预览可以在 download 方法里加一个 onLine 参数为 true 时把响应头的 Content-Disposition 从 attachment 改成 inline并设置图片的 MIME type。预览功能不适合大文件只建议对图片和 pdf 开放否则前端页面会因为加载一个大视频直接卡死。3.4 秒传的 MD5 判定先查后插数据库唯一索引比 Redis 更贴近毕设秒传的实现原理不复杂上传时把文件算一遍 MD5如果当前用户名下已经有相同 MD5就不再写实体文件只在 file_info 表插入一条新记录。这个方案在商业网盘里会配合 Redis 或者分布式数据库做全局去重但对毕设来说MySQL 的一张表足够关键是先查后插时要注意并发场景。FileMapper.xml 里的查询和插入可以这样写select idselectByUserAndMd5 resultTypeFileInfo SELECT id, user_id, parent_id, file_name, file_path, file_size, file_type, md5, is_dir, create_time FROM file_info WHERE user_id #{userId} AND md5 #{md5} AND is_dir 0 LIMIT 1 /select insert idinsertFileRecord useGeneratedKeystrue keyPropertyid INSERT INTO file_info (user_id, parent_id, file_name, file_path, file_size, file_type, md5, is_dir) VALUES (#{userId}, #{parentId}, #{fileName}, #{filePath}, #{fileSize}, #{fileType}, #{md5}, #{isDir}) /insert参数说明LIMIT 1 很关键因为一个用户可能多次上传同一个文件file_info 里有多条 name 不同的记录但 md5 都一样查询任意一条即可。selectByUserAndMd5 不能只查 md5 而不管 user_id否则不同用户的秒传会被误伤。正常流程是用户 A 上传了文件 a用户 B 再传同一个文件时应该为 B 也创建一条 file_info 记录如果全局去重B 的目录里就看不到这个文件了。秒传插入后file_info 表会出现两条 file_path 指向同一个物理文件的记录。删除时要做到引用计数只有当同一个 user_id file_path 的记录全部删完后才允许删除磁盘实体文件。这里用了一个比较简单的 delete 策略删除文件记录时先统计当前 path 在本表里的记录条数等于 1 才删磁盘文件。代码如下int count fileMapper.countByFilePath(info.getFilePath()); fileMapper.deleteByIdAndUser(fileId, userId); if (count 1) { storageService.delete(info.getFilePath()); }注意这个逻辑有小概率丢文件两个用户正在同时秒传同一个文件都查到了 count2各自删除自己的记录后谁都没有再删磁盘文件于是留下孤儿文件。这是没加数据库行锁带来的并发问题毕设演示基本遇不到但如果论文里写“支持并发秒传”就得提前想好锁方案最简单的做法是给 file_info 按 file_path 加一把悲观锁或者干脆在 count 统计时用 SELECT FOR UPDATE。4. 云存储选型本地磁盘、服务器 NFS 还是阿里云存储桶 OSS4.1 毕设语境下的“云存储”到底是什么很多同学被题目里的“云存储”卡住觉得不接阿里云 OSS 就算跑题。实际上在毕业设计语境里云存储指的是“文件不在浏览器本地而是集中存储在远端服务器通过 Web 接口访问”你用自己的服务器磁盘也一样成立。论文里只需要写清楚本系统将文件内容层与业务层解耦采用统一存储接口设计支持本地磁盘存储与云对象存储两种实现。这样既老实又能把选择题变成加分项。如果老师说“必须接到真正的云存储桶”这时候才需要上阿里云 OSS。阿里云提供对象存储服务术语里把文件叫对象把顶层容器叫存储桶Bucket你只需要把上传文件从“写到本地磁盘”改成“PUT 到 OSS Bucket”。对 SSM 项目来说改动量其实不大把 StorageService 从接口实现类切换成 OssStorageServiceImpl控制层完全不用改。这就是为什么设计 StorageService 接口这么重要。4.2 阿里云存储桶接入 OSS最小配置和最小上传代码假设你已经创建了一个 Bucket拿到 AccessKey ID、AccessKey Secret 和 Endpoint 后最小可用的存储服务实现大概是这个样子Service(ossStorageService) public class OssStorageServiceImpl implements StorageService { Value(${oss.endpoint}) private String endpoint; Value(${oss.accessKeyId}) private String accessKeyId; Value(${oss.accessKeySecret}) private String accessKeySecret; Value(${oss.bucketName}) private String bucketName; private OSS client; PostConstruct public void init() { client new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret); } Override public String store(File tempFile, Long userId, String originalFilename) { String dateDir new SimpleDateFormat(yyyyMM).format(new Date()); String ext FileNameUtil.getExtension(originalFilename); String objectKey user_ userId / dateDir / UUID.randomUUID() (ext.length() 0 ? : . ext); PutObjectResult result client.putObject(bucketName, objectKey, tempFile); log.info(oss upload result: {}, result.getETag()); return objectKey; } Override public InputStream open(String filePath) throws IOException { OSSObject ossObject client.getObject(bucketName, filePath); return ossObject.getObjectContent(); } Override public void delete(String filePath) { client.deleteObject(bucketName, filePath); } }代码说明store 方法返回的不是本地绝对路径而是 OSS 里的 objectKey这是相对 Bucket 的虚拟路径。下载时就不要再 new File(filePath) 了改成 client.getObject 拿流再往 response 里写代码主体和本地下载一样。OssStorageServiceImpl 里最容易被忽略的是 PostConstruct 创建 client很多人会每次上传都 new 一个 OSSClient不仅慢还会因为连接没释放导致文件句柄泄漏。参数说明objectKey 的命名规则尽量和本地存储保持一致都是“用户维度 时间维度 随机文件名”这样数据在 OSS 控制台里也是有序的答辩时打开 Bucket 给老师看很有说服力。endpoint 的取值要注意区分公网和内网如果 Tomcat 也部署在阿里云 ECS 上可以改用内网 endpoint不走公网流量费。AccessKey 千万别硬编码到代码里毕设源码是要提交的泄露后可能被拿去刷流量应该放到 jdbc.properties 类似的环境配置里并且提交前把 key 换成自己的演示值。4.3 我用本地磁盘方案的原因和取舍我自己带毕设时会先问清楚学校对“云存储”的硬性要求。如果题目只是宽泛的“云存储毕业设计”我会用本地磁盘因为幕后跑得稳演示环境断网也能用还不用申请云资源。如果学校要求必须体现对象存储那么本地磁盘版和 OSS 版可以做成两套 StorageService 实现默认走本地答辩前一小时切换到 OSS。这里不推荐为了“看起来高级”而上 MinIO 或者 FastDFS。MinIO 本质是私有化对象存储部署它等于在毕设里多引入一个依赖进程答辩环境内存不足直接崩FastDFS 是老一代分布式文件系统架构上确实能讲很多但和 SSM 集成时 tracker 和 storage 两套节点的配置足够让你翻车。OSS 的好处是全托管、上传稳定坏处是需要网络和账号适合大多数人的就是代码里做一个存储抽象层论文里论证可扩展性演示时用本地磁盘。存储方案成本部署复杂度演示稳定性答辩加分本地磁盘目录0低高断网可用中阿里云 OSS 存储桶按量付费中依赖网络高且技术选型更“现代”MinIO / FastDFS低高资源占用不可控高但容易中途翻车5. 避坑个人网盘最容易翻车的 5 个地方5.1 中文文件名下载后乱码或文件打不开现象上传“项目文档.docx”下载后文件名变成一堆百分号%E9%A1%B9%E7%9B%AE%E6%96%87%E6%A1%A3.docx或者干脆是乱码。原因Content-Disposition 这个响应头是 RFC 2616 时代的产物对非 ASCII 字符没有可靠定义。直接把 UTF-8 文件名拼进去老版本 Chrome 不认Firefox 会对 URL 编码做二次解码出现乱码。解决写成attachment; filename*UTF-8URL编码后的文件名并把原来的 filename 也保留一份纯 ASCII 兜底。String encodedName URLEncoder.encode(info.getFileName(), UTF-8).replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment; filename\ encodedName \; filename*UTF-8 encodedName);参数说明%20 是空格在 URL 编码里的正确形式URLEncoder.encode 默认把空格变在 Content-Disposition 里是非法字符必须转掉。这是最容易忽略的小坑。5.2 同级目录同名文件互相覆盖现象在同一个目录上传两次2024.pdf第一次的文件消失了数据库只有一条记录磁盘文件被莫名其妙覆盖。原因存储路径直接用了rootPath / fileName。第二次上传时同名文件把磁盘文件覆盖了但 file_info 表还插了新记录指向同一个物理路径。如果第一次记录的下载接口被调用也能拿到第二个文件的内容。解决物理文件名强制用 UUID 或 MD5 命名用户文件名只存数据库。磁盘文件一旦写好就不允许覆盖需要更新内容时先写新文件再删旧文件。5.3 上传一半断网留下 0 字节脏文件现象前端上传一个 1GB 文件传到 700MB 时页面报错。数据库里出现一条 0 字节或半截文件记录磁盘目录里躺着一个读不了的文件。原因上传接口直接file.transferTo(target)文件流还没写完事务已经提交了记录或者 controller 里文件保存和数据库插入不同步先插了库落盘时抛异常。解决文件先写到临时文件成功后再 rename 到最终目录数据库在 rename 成功后才插入。同时给文件表加一个“文件状态”字段0 表示上传中1 表示完整。如果坚持不做状态字段就把上传设计成“写临时文件 - md5 校验大小 - move - insert”四步insert 失败后删除物理文件。5.4 路径穿越恶意传../../把服务器文件下载走现象正常下载没问题但有人把 fileId 猜出来后下载接口返回了一个不在存储目录范围内的文件比如application.yml。原因有的简化实现是new File(rootPath / fileName)fileName 里带了..。重点不是数据库而是任何形式的用户输入拼接进磁盘路径都会成为后门。下载时直接通过文件名取文件而不是通过 file_id 查库校验是这类漏洞的根源。解决下载入口只允许传 fileId数据库在查询时同时校验 user_id 和 is_dir磁盘绝对路径在代码里不要用文件名拼只使用 file_info.file_path 字段file_path 入库前再做一次规范化确保不以..开头。更稳的做法是在 Service 层把 filePath 限制在 rootPath 前缀下String canonicalPath targetFile.getCanonicalPath(); if (!canonicalPath.startsWith(new File(rootPath).getCanonicalPath())) { throw new BizException(非法文件路径); }5.5 秒传误判不同内容撞出同一个 MD5现象上传一个合法文件系统提示秒传成功但下载下来内容不同。原因MD5 是摘要算法不是唯一标识存在碰撞可能。更常见的是代码里只查了 md5 没查文件大小或者查询条件写成了全局 md5把一个完全不同用户的内容误当作当前用户的文件。解决查秒传时用user_id md5 file_size三个条件定位文件大小几乎可以消除正常碰撞。也可以在 FileInfo 表里对 (user_id, md5, file_size) 建唯一索引数据库层面兜底。如果是答辩时被老师问“MD5 碰撞怎么办”能答出“加 file_size 约束”就已经比分高一大截。6. 答辩和验收用这三个功能证明系统值得 90 分6.1 演示顺序设计把秒传放在第一个让评委第一次见就记住答辩演示不要从登录开始走流程评委已经看麻木了。先上传一个几兆的测试图片立刻再传一次同一个文件页面上出现“秒传成功”这时评委往往会把头抬起来。随后再做一次 100MB 文件的正常上传展示进度条最后下载刚上传的文件双击打开确认内容一致。这套顺序 3 分钟就能做完覆盖了上传、存储、下载、去重四条链路。6.2 论文里的三张图E-R 图、用例图、时序图论文里技术含量最高的三张图分别是数据库 E-R 图展示 user、file_info、share 三张表的关系上传时序图展示从 MultipartFile 到临时文件、MD5 计算、秒传判断、落盘的完整过程用例图把用户和系统的交互画成登录、上传、下载、删除、分享。这里强调一点时序图要按我们上面写的“先临时文件再算 MD5”来画别画成教科书式的直接保存评委看你代码时会对上号。6.3 最后一招启动自检把“清理孤儿文件”做成隐藏加分项我在每个网盘项目里都会加一个应用启动任务扫描存储根目录找到哪些磁盘文件在 file_info 表里已经没有任何记录了放入待清理队列并生成日志。这样既能在答辩时说“这个系统有自愈能力”又能在演示前替我自动清掉测试残留。实现很简单实现 ApplicationRunner 接口即可Component public class DiskCheckRunner implements ApplicationRunner { Autowired private FileMapper fileMapper; Value(${disk.rootPath}) private String rootPath; Override public void run(ApplicationArguments args) throws Exception { ListFile orphans OrphanFileScanner.scan(rootPath, path - fileMapper.countByFilePath(path) 0); log.info(scan done, orphan count{}, orphans.size()); } }这个逻辑看着简单但能把“存储一致性问题”讲成一个闭环启动校验 清理日志 引用计数删除答辩老师再往下追问你还有东西可讲。当年我答辩前半小时在服务器上跑了一遍这个扫描把测试产生的几十个脏文件清理干净演示时磁盘干干净净老师问“你用什么保证存储不泄漏”我就把这段启动自检讲给他听项目拿了那组的最高分。这个习惯我后面每次交项目前都会用希望帮到你。本文还有配套的精品资源点击获取