简介这套基于 Spring Boot 的个人云盘管理系统是一份面向 Java 学习者、毕业设计或课程设计场景的完整项目资源覆盖用户注册登录、权限设置、文件上传下载、批量传输、树状目录、搜索标签、分享链接、协同编辑、版本管理及数据加密等典型云盘功能。包体共 782 个文件压缩包约 28.96MB以 java 源码、vue 页面、js 脚本、svg 图标、css 样式和 html 页面为主体同时包含 sql 数据库脚本、xml 配置、启动与构建批处理脚本等便于直接导入开发工具后运行调试。目前已有 90 人学习下载。资源内项目结构完整包含前端静态资源、后端控制器与服务层代码、数据库初始化脚本及一键安装、运行、构建的 bat 工具可帮助读者理解 Spring Boot 与 Vue 的整合方式也能支撑毕业论文中的功能设计、系统实现与演示截图整理。1. 从毕业设想到可运行网盘springBoot个人云盘管理系统到底在做什么如果你正在为毕业设计选型大概率会被“个人云盘管理系统”这个题目吸引——需求明确、技术栈主流、演示效果好尤其是基于springBoot的实现方案几乎成了Java方向毕设的常客。但真正动手时你会发现所谓云盘难点不在登录注册而在文件的分片上传、断点续传、秒传校验、分享链接和回收站这些看不见的细节。这篇文章就按我自己做过的一版方案来拆从技术选型、数据库设计到分片上传和秒传的核心代码再到上传超时、路径穿越、并发合并这几个最容易翻车的坑最后给你一套答辩前能拿得出手的验证方法。无论你是准备拿它做毕业论文还是单纯想给团队搭一个内网私有云盘照着这条线走能少踩一半坑。2. 选型先于编码个人云盘管理系统的技术栈怎么定2.1 存储层选型本地磁盘、MinIO 还是 OSS很多人在写“个人云盘管理系统”的时候第一反应是直接往数据库里塞文件或者用云厂商的OSS。这两种都不推荐作为毕设主方案。数据库存文件会把表撑爆、备份困难答辩时老师一问“你的文件存哪里”就露怯OSS虽然稳定但涉及费用和联网环境现场演示容易翻车。我一般建议主存储用本地磁盘配合绝对路径入库源码里预留一个StorageStrategy接口。这样论文里可以写“本系统采用可扩展的存储策略”实际实现只用最简单的FileOutputStream写盘逻辑透明、答辩讲得清。如果你想加亮点再引入MinIO做对象存储它是S3协议的开源实现本地能跑、界面直观加到springBoot项目里也就十几行配置。MinIO接入的核心配置如下适合作为选型章节的加分项minio: endpoint: http://127.0.0.1:9000 access-key: admin secret-key: admin123 bucket: cloud-diskConfiguration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(admin, admin123) .build(); } }存储层的对比直接决定你后面所有代码的写法。用本地磁盘上传就是MultipartFile.transferTo()用MinIO就要走putObject(InputStream, ObjectWriteArgs)用OSS更麻烦要引入SDK、配防盗链。提醒一下如果你论文选择MinIO做亮点过不了环境的时候必须有本地磁盘兜底方案别把全部赌注压在一个依赖外网服务的组件上。2.2 数据库表设计四张表撑起整个云盘个人云盘和百度网盘这类产品的核心区别是单用户还是多用户。既然叫“个人云盘管理系统”通常还包含用户体系所以最少需要四张表用户表、文件元数据表、分享表、回收站记录表。文件内容永远不进数据库库里只存路径、大小、MD5、所属用户这些元数据。先看最核心的文件表CREATE TABLE file_info ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 所属用户, file_name varchar(255) NOT NULL COMMENT 原始文件名, file_path varchar(500) NOT NULL COMMENT 存储相对路径, file_size bigint(20) DEFAULT 0 COMMENT 文件大小(字节), file_md5 varchar(32) DEFAULT NULL COMMENT 文件MD5用于秒传校验, parent_id bigint(20) DEFAULT 0 COMMENT 父目录id0表示根目录, is_folder tinyint(1) DEFAULT 0 COMMENT 0文件 1文件夹, deleted tinyint(1) DEFAULT 0 COMMENT 软删除标记, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_parent (user_id, parent_id), UNIQUE KEY uk_user_md5 (user_id, file_md5, parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT文件元数据表;这张表是你整个系统的地基。注意两个设计点第一file_path永远存相对路径不要存C:/Users/xxx这种绝对路径否则项目换个机器跑所有文件全部失效这是血泪经验第二MD5加上user_id和parent_id做联合唯一索引目的是给秒传用——同一个用户在同一目录传同一个文件直接判定已存在。分享表是另一个容易忽略的模块CREATE TABLE share_info ( id bigint(20) NOT NULL AUTO_INCREMENT, file_id bigint(20) NOT NULL COMMENT 被分享的文件id, share_code varchar(16) NOT NULL COMMENT 分享码或提取码, expire_time datetime DEFAULT NULL COMMENT 过期时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_share_code (share_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意share_code一定要加唯一索引并在生成时做去重校验。分享码是用户看得见摸得着的东西生成重复了会直接导致访问错乱。2.3 工程骨架与自动装配从IDEA到第一个Hello接口springBoot项目最常用的创建方式是IDEA的Spring Initializr。版本选择要克制Java 8 SpringBoot 2.7.x是最稳的组合因为网上几乎所有的资料、面试题、异常解决方案都基于这个版本段。SpringBoot 3.x要求JDK 17你的毕设环境未必支持没必要冒险。核心依赖pom.xml里只需要这几样dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency为什么用MyBatis-Plus而不是原生MyBatis因为毕设的核心是业务完整度不是SQL炫技。MyBatis-Plus的BaseMapper让你不用写任何XML就能完成单表CRUD把时间留给文件分片和断点续传这些真正体现工作量地方。论文里你可以写“本系统采用MyBatis-Plus作为持久层框架”没人会挑你毛病。自动装配的原理顺便说一句因为面试和答辩都爱问。springBoot在spring.factories里声明了EnableAutoConfiguration启动时通过Import把AutoConfigurationImportSelector导入再配合ConditionalOnClass、ConditionalOnProperty等条件注解决定哪些Bean生效。这段不用背但要能用自己的话讲出来比死记“自动装配原理八股文”强得多。工程创建好后第一个接口建议直接写上传别写Hello World因为上传是云盘的命脉越早验证越好。3. 上传下载的核心链路分片、断点续传与秒传落地3.1 分片上传前端切片、后端合并的完整闭环个人云盘如果只支持小文件演示时传个视频卡住就尴尬了。标准做法是前端把文件切成多个分片后端依次接收全部收齐后合并。前端用File.slice()切片每个分片附带序号const file document.getElementById(uploadFile).files[0]; const chunkSize 5 * 1024 * 1024; // 5MB一个分片 let start 0; let index 0; while (start file.size) { const chunk file.slice(start, start chunkSize); const formData new FormData(); formData.append(file, chunk); formData.append(fileName, file.name); formData.append(index, index); formData.append(total, Math.ceil(file.size / chunkSize)); formData.append(fileMd5, md5); // 整个文件的MD5先算好 // 用XMLHttpRequest或axios同步串行上传不要并发 await axios.post(/api/file/upload/chunk, formData); start chunkSize; index; } // 全部传完再通知后端合并 await axios.post(/api/file/upload/merge, { fileName: file.name, fileMd5: md5, total: index });后端接收分片的关键是“每个分片落独立临时文件合并时按序拼接”PostMapping(/upload/chunk) public Result uploadChunk(RequestParam(file) MultipartFile file, RequestParam(index) Integer index, RequestParam(fileMd5) String fileMd5) { String tempDir uploadRoot / fileMd5; File dir new File(tempDir); if (!dir.exists()) { dir.mkdirs(); } File chunkFile new File(tempDir, index .part); try { file.transferTo(chunkFile); } catch (IOException e) { return Result.error(分片[ index ]上传失败); } return Result.ok(分片上传成功); } PostMapping(/upload/merge) public Result mergeChunks(RequestParam(fileName) String fileName, RequestParam(fileMd5) String fileMd5, RequestParam(total) Integer total) { String tempDir uploadRoot / fileMd5; File target new File(uploadRoot / fileMd5 _ fileName); try (FileOutputStream fos new FileOutputStream(target)) { for (int i 0; i total; i) { File chunkFile new File(tempDir, i .part); byte[] bytes Files.readAllBytes(chunkFile.toPath()); fos.write(bytes); chunkFile.delete(); } File dir new File(tempDir); dir.delete(); } catch (IOException e) { return Result.error(合并失败); } // 落库插入file_info记录 FileInfo fileInfo new FileInfo(); fileInfo.setFileName(fileName); fileInfo.setFilePath(uploadRoot / fileMd5 _ fileName); fileInfo.setFileMd5(fileMd5); // ... 其他字段 return Result.ok(); }这段代码有两个参数值得较真。分片大小chunkSize为什么选5MB而不是1MB或20MB分片太小会导致HTTP请求数量过多对Tomcat连接数形成压力分片太大又失去断点续传的意义网络抖动一次重传成本高。5MB是平衡值内网甚至可以调到10MB。合并时用Files.readAllBytes一次读一整个分片如果分片设成100MB这里直接内存溢出所以分片大小不是越大越好。另一个细节合并接口必须做“幂等处理”。前端重试合并请求时如果上次已经合并成功再次执行会覆盖文件甚至报错。常见做法是落库前先查file_md5是否已存在存在则直接返回已存在标记。3.2 秒传的真相MD5校验文件内容别拿文件名校验秒传功能几乎是答辩必被问的点原理其实一句话文件内容不变MD5就不会变。上传前前端先计算整个文件的MD5后端拿到MD5去file_info表里查同一用户同一目录下如果已存在相同MD5的文件就不再传输文件内容直接把已存在的记录复制一份新元数据即可。前端计算MD5需要引入SparkMD5之类的库注意大文件要分块计算一次性读入内存会卡死浏览器const spark new SparkMD5.ArrayBuffer(); const reader new FileReader(); let currentChunk 0; const chunkSize 2 * 1024 * 1024; function processChunk() { const start currentChunk * chunkSize; const end Math.min(file.size, start chunkSize); reader.readAsArrayBuffer(file.slice(start, end)); } reader.onload function(e) { spark.append(e.target.result); currentChunk; if (currentChunk Math.ceil(file.size / chunkSize)) { processChunk(); } else { const md5 spark.end(); // 携带md5先请求秒传接口 checkQuickUpload(md5, file.name); } };后端秒传校验的逻辑PostMapping(/upload/quick) public Result quickUpload(RequestParam(fileMd5) String fileMd5, RequestParam(fileName) String fileName) { LambdaQueryWrapperFileInfo wrapper new LambdaQueryWrapper(); wrapper.eq(FileInfo::getFileMd5, fileMd5) .eq(FileInfo::getUserId, currentUserId) .eq(FileInfo::getParentId, currentParentId) .eq(FileInfo::getDeleted, 0) .last(limit 1); FileInfo existFile fileInfoMapper.selectOne(wrapper); if (existFile ! null) { // 秒传成功复制一份元数据指向同一个物理文件 // 注意物理文件不能删除因为多个记录共享它 return Result.ok(秒传成功, buildNewRecord(existFile)); } return Result.error(需正常上传); }秒传最大的坑是存储文件名的设计。如果秒传成功后新记录指向旧文件的物理路径那么旧记录一旦被删除物理文件会被连带删除新记录就变成了死链。解决方法是给物理文件用MD5直接做文件名这样同一MD5永远只有一个物理副本任何记录删除都只是删元数据物理文件靠引用计数或定时扫描来清理。我见过不少系统在这里翻车答辩前自己删一个文件再试一次秒传后的下载立刻露馅。3.3 断点续传与下载的Range请求头断点续传的下载侧其实不用自己造轮子HTTP协议原生支持Range头。浏览器下载大文件中断后再次下载会带Range: bytesxxx-服务端只需解析这个头返回206 Partial Content即可。GetMapping(/download/{fileId}) public ResponseEntityResource download(PathVariable Long fileId, RequestHeader(value Range, required false) String range) { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(fileInfo.getFilePath()); if (range ! null range.startsWith(bytes)) { String[] ranges range.substring(6).split(-); long start Long.parseLong(ranges[0]); long end ranges.length 1 ? Long.parseLong(ranges[1]) : file.length() - 1; long length end - start 1; RandomAccessFile raf new RandomAccessFile(file, r); raf.seek(start); byte[] data new byte[(int) length]; raf.read(data); raf.close(); return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) .header(Content-Range, bytes start - end / file.length()) .contentLength(length) .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(new ByteArrayResource(data)); } // 全量下载 return ResponseEntity.ok() .header(Content-Disposition, attachment; filename\ fileInfo.getFileName() \) .contentType(MediaType.APPLICATION_OCTET_STREAM) .contentLength(file.length()) .body(new FileSystemResource(file)); }这段代码的注意点有三个。第一RandomAccessFile的seek定位必须基于long文件超过2GB时int会溢出这是JDK老坑第二ByteArrayResource会把整个range读进内存所以单次range大小要限制一般限制在1MB以内否则并发下载几个大文件就把堆吃满第三Content-Disposition必须处理中文文件名直接用fileName会乱码要转成URL编码——用org.springframework.http.ContentDisposition构造可以规避编码问题。断点续传的上传侧就是上一节的分片上传两者配合起来才是完整的个人云盘文件传输方案。4. springBoot个人云盘必踩的坑超时、路径穿越与并发写坏文件4.1 大文件上传超时明明没报错前端却一直pending现象上传200MB以上的文件前端请求一直转圈几分钟后报超时后端日志看不出任何异常。原因有三层超时叠加在一起。第一层是SpringBoot的servlet容器默认没有全局超时但Tomcat的connection-timeout默认20秒仅针对连接建立不针对传输第二层是Nginx等反向代理的proxy_read_timeout默认60秒文件还没传完连接就被掐了第三层是前端axios默认无超时但浏览器本身对上传有软限制。大多数情况就是Nginx那层拦住了。解决Nginx配置里调大三个参数。server { listen 80; client_max_body_size 1024m; location / { proxy_pass http://127.0.0.1:8080; proxy_connect_timeout 300s; proxy_read_timeout 300s; proxy_send_timeout 300s; } }同时SpringBoot侧要放开文件大小限制application.yml里必须改这两个默认值spring: servlet: multipart: max-file-size: 1024MB max-request-size: 2048MB注意max-file-size是单文件上限max-request-size是单次请求总大小。分片上传时每个请求只包含一个分片所以这两个值可以设成一样。很多人在本地IDE里测没问题得益于IDE自带的端口直连一上服务器秒挂就是Nginx没调。这个坑我帮人排查过不下五次。4.2 文件名路径穿越上传个“..”。现象攻击者上传文件名为“../../../../etc/crontab”的文件下载或合并时文件被写到服务器系统目录导致任意文件覆盖。原因FileInfo的fileName字段直接拼接进了文件路径没有做任何标准化校验。Java的File构造函数不会拦截“..”符号new File(uploadRoot / fileName)会乖乖把你带到目录之外。解决路径标准化白名单校验。public String normalizeFileName(String fileName) { String normalized Paths.get(fileName).getFileName().toString(); if (normalized.contains(..)) { throw new BusinessException(非法的文件名); } if (normalized.contains(/) || normalized.contains(\\)) { throw new BusinessException(非法的文件名); } if (normalized.isEmpty()) { throw new BusinessException(文件名为空); } return normalized; }一句话原则对外展示文件名对内存储用UUID重命名物理路径里永远不要直接放原始文件名。这样既防了路径穿越又避免了同名文件覆盖问题。物理文件名用UUID原文件名存file_info的file_name字段下载时才拼接回Content-Disposition头。4.3 并发上传同一文件分片合并互相覆盖现象两个线程同时上传同一MD5的文件后端合并时出现文件内容混杂或者合并接口报“文件被占用”。原因合并逻辑没有做并发控制。线程A正在写target文件线程B也往同一个target写两个FileOutputStream同时打开后写的会覆盖先写的偏移量导致文件损坏。解决使用文件锁或ConcurrentHashMap做本机互斥。最简单可靠的是基于文件路径加锁private static final ConcurrentHashMapString, Object LOCK_MAP new ConcurrentHashMap(); public void mergeChunksWithLock(String fileMd5, String fileName) { Object lock LOCK_MAP.computeIfAbsent(fileMd5, k - new Object()); synchronized (lock) { doMerge(fileMd5, fileName); LOCK_MAP.remove(fileMd5); } }为什么不直接用synchronized(this)因为那是范围太大不同文件的合并也互相阻塞。按fileMd5粒度加锁同一文件的合并串行化不同文件并行执行。注意merge完成后要remove掉锁对象否则map里积累大量无用锁变成内存泄漏。4.4 数据库存绝对路径换个环境全部文件失效现象开发环境一切正常把项目打包部署到服务器或者换一台电脑历史上传的文件全部下载失败。原因file_info表里存的是类似D://dev/upload/xxx.jpg这样的绝对路径。环境一变路径前缀就失效文件还在但系统找不到。解决数据库一律存相对路径upload/xxx.jpg在配置里指定外部存储根目录cloud: disk: upload-dir: /data/cloud-disk业务代码里通过FileUtil拼接完整路径String fullPath uploadDir File.separator fileInfo.getFilePath();这样部署时只要保证upload-dir指向正确位置历史数据完全不用迁移。这是个人云盘从“能跑”迈向“能用”的关键一步。4.5 秒传校验张冠李戴只查文件名校验导致数据串位现象秒传接口返回成功但下载下来的文件内容和上传的文件名完全不匹配。原因秒传校验只比对fileName和fileSize忽略了MD5。两个不同文件恰好同大小同文件名被判定为同一文件。解决只信MD5不信文件名。查询条件只包含user_id、file_md5和deleted0完全不带fileName。同目录下不同名但内容相同的文件秒传时新文件名以展示为准物理文件始终只有一份。这个逻辑在3.2节代码里已经是正确的但很多人在实际写业务时为了“提高命中率”又把文件名加回了查询条件属于画蛇添足。4.6 文件预览乱码与Content-Type的玄学现象上传的txt文件在线预览时中文乱码图片能打开但浏览器不渲染。原因预览接口返回的Content-Type与文件实际类型不匹配。浏览器根据Content-Type决定渲染方式返回application/octet-stream会导致图片直接下载而不是显示。解决统一用第三方工具库判断MIME类型不用扩展名硬映射避免文件名大小写导致的分歧。GetMapping(/preview/{fileId}) public ResponseEntityResource preview(PathVariable Long fileId) { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(getFullPath(fileInfo)); MediaType mediaType MediaTypeFactory.getMediaType(fileInfo.getFileName()) .orElse(MediaType.APPLICATION_OCTET_STREAM); return ResponseEntity.ok() .contentType(mediaType) .contentLength(file.length()) .body(new FileSystemResource(file)); }预览的正确姿势是让浏览器干浏览器该干的事你只需要给对Content-Type。碰到图片不显示就去浏览器F12看响应头如果Content-Type变成了application/octet-stream说明是扩展名判断逻辑写错了这类问题基本都是半猜半查解决的真调起来十几分钟就够。5. 预览、分享与回收站把云盘从“作业”做成“产品”5.1 文件预览图片、文本能看Office文档靠什么个人云盘如果只能上传下载演示效果特别单薄。加上预览功能答辩时拉开差距的效果立竿见影。图片和文本预览最省钱也最容易。图片用上一节提到的直接返回MediaType的方式浏览器原生支持。文本预览注意编码问题统一转成UTF-8后再返回避免Windows上传的GBK文本在页面上乱码GetMapping(/preview/txt/{fileId}) public ResponseEntitybyte[] previewTxt(PathVariable Long fileId) throws IOException { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(getFullPath(fileInfo)); String content FileUtils.readFileToString(file, GBK); byte[] bytes content.getBytes(StandardCharsets.UTF_8); return ResponseEntity.ok() .contentType(MediaType.TEXT_PLAIN) .contentLength(bytes.length) .body(bytes); }注意这段代码用了GBK读取再转UTF-8看起来像是“读取-转码-读取”两遍实际上成了标准处理链先按GBK解码成Java String再按UTF-8编码成字节返回给浏览器。Office文档预览是另一个量级的问题。常见做法有两个一是集成开源项目KKFileView它本身就是SpringBoot的能预览doc、xls、pdf但强依赖OpenOffice/LibreOffice做转换环境配置极度玄学版本不对就是启动报错二是用jodconverter把Office文档转PDF再通过浏览器PDF预览。无论哪条路毕设都不建议把时间花在这里功能能跑通了就行。我见过太多人死磕Office预览最后答辩时用的还是备用电脑。5.2 分享链接与提取码短码生成的两行代码分享功能的核心是生成一个不重复的短码并设置过期时间。很多人用UUID直接作为分享码一个36位字符串贴到微信里又长又丑。更专业的做法是用62进制转换把自增ID编码成短字符串private static final String BASE62 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ; public static String encode(long num) { StringBuilder sb new StringBuilder(); while (num 0) { sb.append(BASE62.charAt((int) (num % 62))); num / 62; } return sb.reverse().toString(); }配合一张share_info表分享链接就是http://你的域名/share/{shortCode}提取码放在分享时让用户自定义4位数字。访问时先查分享是否存在、是否过期然后跳转文件详情页。这个功能加进去整个系统的产品完整性立刻上一个台阶。5.3 回收站软删除配合定时清理个人云盘的回收站不能真的把文件直接删掉。标准实现是file_info表增加deleted字段删除文件时执行UPDATE而不是DELETEDeleteMapping(/delete/{fileId}) public Result delete(PathVariable Long fileId) { FileInfo update new FileInfo(); update.setId(fileId); update.setDeleted(1); fileInfoMapper.updateById(update); return Result.ok(已移入回收站); }真正物理清理交给定时任务每天凌晨执行一次清理回收站中超过30天的记录Component Slf4j public class FileCleanTask { Scheduled(cron 0 0 2 * * ?) public void cleanExpiredFiles() { // 1. 查询所有deleted1且update_time早于30天前的记录 // 2. 判断物理文件是否被其他未删除记录引用按file_md5查 // 3. 无引用则删除物理文件有引用则只删记录 // 4. 删除file_info记录 } }这个定时任务怎么写很有讲究。同一个物理文件可能被多个记录共享秒传场景如果清理时直接删了物理文件其他记录就变成废链。所以删文件前必须先查引用计数。用file_md5分组统计未删除记录数为0才允许删除物理文件。这个逻辑放在论文里可以单独写一小节算半个小亮点。6. 论文里的“系统验证”怎么写从接口测试到并发弱网下的实测写毕业论文时“系统测试”章节如果只有“功能全部通过”这几个字答辩必被追问。你要用数据说话。6.1 用JMeter做并发上传压测JMeter压测上传接口注意两点一是要加HTTP Header Manager设置Content-Type为multipart/form-data二是要用“HTTP请求”采样器里的“文件上传”标签页选中你的测试文件。线程数设50Ramp-Up设10秒循环10次。6.2 弱网模拟的三个关键参数用JMeter的“Constant Throughput Timer”或QoS插件模拟弱网核心是限制上传带宽。一个常见配置是带宽限制200KB/s并发20线程对10MB文件做断点续传测试。6.3 用curl验证单分片和多分片的一致性写测试脚本的时候可以快一些但验证步骤不能少。拿同一个文件分别走完整上传和分片上传两条链路比对两份落盘文件的MD5是否一致。curl -F filetest.pdf http://localhost:8080/api/file/upload/chunk curl -X POST http://localhost:8080/api/file/upload/merge -F fileMd5xxx -F total2 -F fileNametest.pdf md5sum /data/cloud-disk/test.pdf6.4 写结果表结果表里至少包含并发数、平均响应时间、吞吐量、错误率、上传成功率、秒传命中率、断点续传成功率这几项。秒传命中率用同一文件重复上传100次统计断点续传成功率模拟传输中断后重试记录成功恢复次数。这几组数据凑齐论文里的系统验证部分基本就扎实了。6.5 一个值得复用的结论如果你的压测结果显示“并发50时上传成功率98%秒传命中率100%断点续传无数据损坏”那么系统性能验证的结论就可以写“该个人云盘管理系统在中等并发下能够保证文件传输的可靠性满足个人及小团队使用需求”。这句话是有依据的不是拍脑袋。落到个人习惯上我以前做毕设就是单机跑通就交答辩时老师问“你们系统能扛多少人同时传文件”我语塞了。那次之后我再做任何管理系统都会先跑一遍并发测试再写文档。如果你时间有限至少跑一组50并发看看错误率哪怕结果不理想论文里写“存在优化空间”也比拿不出数据强得多。这套方案做成什么样才算成功标准其实不高同一个文件上传下载一百次不丢字节换环境部署后旧数据还能访问并发二十个用户同时传大文件系统不卡死——做到这三点你的个人云盘毕业设计已经超过了大部分人。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/28 1:56:19 · 阅读 1.2k SpringBoot个人云盘管理系统：分片上传、秒传与断点续传实战解析
简介这套基于 Spring Boot 的个人云盘管理系统是一份面向 Java 学习者、毕业设计或课程设计场景的完整项目资源覆盖用户注册登录、权限设置、文件上传下载、批量传输、树状目录、搜索标签、分享链接、协同编辑、版本管理及数据加密等典型云盘功能。包体共 782 个文件压缩包约 28.96MB以 java 源码、vue 页面、js 脚本、svg 图标、css 样式和 html 页面为主体同时包含 sql 数据库脚本、xml 配置、启动与构建批处理脚本等便于直接导入开发工具后运行调试。目前已有 90 人学习下载。资源内项目结构完整包含前端静态资源、后端控制器与服务层代码、数据库初始化脚本及一键安装、运行、构建的 bat 工具可帮助读者理解 Spring Boot 与 Vue 的整合方式也能支撑毕业论文中的功能设计、系统实现与演示截图整理。1. 从毕业设想到可运行网盘springBoot个人云盘管理系统到底在做什么如果你正在为毕业设计选型大概率会被“个人云盘管理系统”这个题目吸引——需求明确、技术栈主流、演示效果好尤其是基于springBoot的实现方案几乎成了Java方向毕设的常客。但真正动手时你会发现所谓云盘难点不在登录注册而在文件的分片上传、断点续传、秒传校验、分享链接和回收站这些看不见的细节。这篇文章就按我自己做过的一版方案来拆从技术选型、数据库设计到分片上传和秒传的核心代码再到上传超时、路径穿越、并发合并这几个最容易翻车的坑最后给你一套答辩前能拿得出手的验证方法。无论你是准备拿它做毕业论文还是单纯想给团队搭一个内网私有云盘照着这条线走能少踩一半坑。2. 选型先于编码个人云盘管理系统的技术栈怎么定2.1 存储层选型本地磁盘、MinIO 还是 OSS很多人在写“个人云盘管理系统”的时候第一反应是直接往数据库里塞文件或者用云厂商的OSS。这两种都不推荐作为毕设主方案。数据库存文件会把表撑爆、备份困难答辩时老师一问“你的文件存哪里”就露怯OSS虽然稳定但涉及费用和联网环境现场演示容易翻车。我一般建议主存储用本地磁盘配合绝对路径入库源码里预留一个StorageStrategy接口。这样论文里可以写“本系统采用可扩展的存储策略”实际实现只用最简单的FileOutputStream写盘逻辑透明、答辩讲得清。如果你想加亮点再引入MinIO做对象存储它是S3协议的开源实现本地能跑、界面直观加到springBoot项目里也就十几行配置。MinIO接入的核心配置如下适合作为选型章节的加分项minio: endpoint: http://127.0.0.1:9000 access-key: admin secret-key: admin123 bucket: cloud-diskConfiguration public class MinioConfig { Value(${minio.endpoint}) private String endpoint; Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(endpoint) .credentials(admin, admin123) .build(); } }存储层的对比直接决定你后面所有代码的写法。用本地磁盘上传就是MultipartFile.transferTo()用MinIO就要走putObject(InputStream, ObjectWriteArgs)用OSS更麻烦要引入SDK、配防盗链。提醒一下如果你论文选择MinIO做亮点过不了环境的时候必须有本地磁盘兜底方案别把全部赌注压在一个依赖外网服务的组件上。2.2 数据库表设计四张表撑起整个云盘个人云盘和百度网盘这类产品的核心区别是单用户还是多用户。既然叫“个人云盘管理系统”通常还包含用户体系所以最少需要四张表用户表、文件元数据表、分享表、回收站记录表。文件内容永远不进数据库库里只存路径、大小、MD5、所属用户这些元数据。先看最核心的文件表CREATE TABLE file_info ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 所属用户, file_name varchar(255) NOT NULL COMMENT 原始文件名, file_path varchar(500) NOT NULL COMMENT 存储相对路径, file_size bigint(20) DEFAULT 0 COMMENT 文件大小(字节), file_md5 varchar(32) DEFAULT NULL COMMENT 文件MD5用于秒传校验, parent_id bigint(20) DEFAULT 0 COMMENT 父目录id0表示根目录, is_folder tinyint(1) DEFAULT 0 COMMENT 0文件 1文件夹, deleted tinyint(1) DEFAULT 0 COMMENT 软删除标记, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_parent (user_id, parent_id), UNIQUE KEY uk_user_md5 (user_id, file_md5, parent_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT文件元数据表;这张表是你整个系统的地基。注意两个设计点第一file_path永远存相对路径不要存C:/Users/xxx这种绝对路径否则项目换个机器跑所有文件全部失效这是血泪经验第二MD5加上user_id和parent_id做联合唯一索引目的是给秒传用——同一个用户在同一目录传同一个文件直接判定已存在。分享表是另一个容易忽略的模块CREATE TABLE share_info ( id bigint(20) NOT NULL AUTO_INCREMENT, file_id bigint(20) NOT NULL COMMENT 被分享的文件id, share_code varchar(16) NOT NULL COMMENT 分享码或提取码, expire_time datetime DEFAULT NULL COMMENT 过期时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_share_code (share_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意share_code一定要加唯一索引并在生成时做去重校验。分享码是用户看得见摸得着的东西生成重复了会直接导致访问错乱。2.3 工程骨架与自动装配从IDEA到第一个Hello接口springBoot项目最常用的创建方式是IDEA的Spring Initializr。版本选择要克制Java 8 SpringBoot 2.7.x是最稳的组合因为网上几乎所有的资料、面试题、异常解决方案都基于这个版本段。SpringBoot 3.x要求JDK 17你的毕设环境未必支持没必要冒险。核心依赖pom.xml里只需要这几样dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency为什么用MyBatis-Plus而不是原生MyBatis因为毕设的核心是业务完整度不是SQL炫技。MyBatis-Plus的BaseMapper让你不用写任何XML就能完成单表CRUD把时间留给文件分片和断点续传这些真正体现工作量地方。论文里你可以写“本系统采用MyBatis-Plus作为持久层框架”没人会挑你毛病。自动装配的原理顺便说一句因为面试和答辩都爱问。springBoot在spring.factories里声明了EnableAutoConfiguration启动时通过Import把AutoConfigurationImportSelector导入再配合ConditionalOnClass、ConditionalOnProperty等条件注解决定哪些Bean生效。这段不用背但要能用自己的话讲出来比死记“自动装配原理八股文”强得多。工程创建好后第一个接口建议直接写上传别写Hello World因为上传是云盘的命脉越早验证越好。3. 上传下载的核心链路分片、断点续传与秒传落地3.1 分片上传前端切片、后端合并的完整闭环个人云盘如果只支持小文件演示时传个视频卡住就尴尬了。标准做法是前端把文件切成多个分片后端依次接收全部收齐后合并。前端用File.slice()切片每个分片附带序号const file document.getElementById(uploadFile).files[0]; const chunkSize 5 * 1024 * 1024; // 5MB一个分片 let start 0; let index 0; while (start file.size) { const chunk file.slice(start, start chunkSize); const formData new FormData(); formData.append(file, chunk); formData.append(fileName, file.name); formData.append(index, index); formData.append(total, Math.ceil(file.size / chunkSize)); formData.append(fileMd5, md5); // 整个文件的MD5先算好 // 用XMLHttpRequest或axios同步串行上传不要并发 await axios.post(/api/file/upload/chunk, formData); start chunkSize; index; } // 全部传完再通知后端合并 await axios.post(/api/file/upload/merge, { fileName: file.name, fileMd5: md5, total: index });后端接收分片的关键是“每个分片落独立临时文件合并时按序拼接”PostMapping(/upload/chunk) public Result uploadChunk(RequestParam(file) MultipartFile file, RequestParam(index) Integer index, RequestParam(fileMd5) String fileMd5) { String tempDir uploadRoot / fileMd5; File dir new File(tempDir); if (!dir.exists()) { dir.mkdirs(); } File chunkFile new File(tempDir, index .part); try { file.transferTo(chunkFile); } catch (IOException e) { return Result.error(分片[ index ]上传失败); } return Result.ok(分片上传成功); } PostMapping(/upload/merge) public Result mergeChunks(RequestParam(fileName) String fileName, RequestParam(fileMd5) String fileMd5, RequestParam(total) Integer total) { String tempDir uploadRoot / fileMd5; File target new File(uploadRoot / fileMd5 _ fileName); try (FileOutputStream fos new FileOutputStream(target)) { for (int i 0; i total; i) { File chunkFile new File(tempDir, i .part); byte[] bytes Files.readAllBytes(chunkFile.toPath()); fos.write(bytes); chunkFile.delete(); } File dir new File(tempDir); dir.delete(); } catch (IOException e) { return Result.error(合并失败); } // 落库插入file_info记录 FileInfo fileInfo new FileInfo(); fileInfo.setFileName(fileName); fileInfo.setFilePath(uploadRoot / fileMd5 _ fileName); fileInfo.setFileMd5(fileMd5); // ... 其他字段 return Result.ok(); }这段代码有两个参数值得较真。分片大小chunkSize为什么选5MB而不是1MB或20MB分片太小会导致HTTP请求数量过多对Tomcat连接数形成压力分片太大又失去断点续传的意义网络抖动一次重传成本高。5MB是平衡值内网甚至可以调到10MB。合并时用Files.readAllBytes一次读一整个分片如果分片设成100MB这里直接内存溢出所以分片大小不是越大越好。另一个细节合并接口必须做“幂等处理”。前端重试合并请求时如果上次已经合并成功再次执行会覆盖文件甚至报错。常见做法是落库前先查file_md5是否已存在存在则直接返回已存在标记。3.2 秒传的真相MD5校验文件内容别拿文件名校验秒传功能几乎是答辩必被问的点原理其实一句话文件内容不变MD5就不会变。上传前前端先计算整个文件的MD5后端拿到MD5去file_info表里查同一用户同一目录下如果已存在相同MD5的文件就不再传输文件内容直接把已存在的记录复制一份新元数据即可。前端计算MD5需要引入SparkMD5之类的库注意大文件要分块计算一次性读入内存会卡死浏览器const spark new SparkMD5.ArrayBuffer(); const reader new FileReader(); let currentChunk 0; const chunkSize 2 * 1024 * 1024; function processChunk() { const start currentChunk * chunkSize; const end Math.min(file.size, start chunkSize); reader.readAsArrayBuffer(file.slice(start, end)); } reader.onload function(e) { spark.append(e.target.result); currentChunk; if (currentChunk Math.ceil(file.size / chunkSize)) { processChunk(); } else { const md5 spark.end(); // 携带md5先请求秒传接口 checkQuickUpload(md5, file.name); } };后端秒传校验的逻辑PostMapping(/upload/quick) public Result quickUpload(RequestParam(fileMd5) String fileMd5, RequestParam(fileName) String fileName) { LambdaQueryWrapperFileInfo wrapper new LambdaQueryWrapper(); wrapper.eq(FileInfo::getFileMd5, fileMd5) .eq(FileInfo::getUserId, currentUserId) .eq(FileInfo::getParentId, currentParentId) .eq(FileInfo::getDeleted, 0) .last(limit 1); FileInfo existFile fileInfoMapper.selectOne(wrapper); if (existFile ! null) { // 秒传成功复制一份元数据指向同一个物理文件 // 注意物理文件不能删除因为多个记录共享它 return Result.ok(秒传成功, buildNewRecord(existFile)); } return Result.error(需正常上传); }秒传最大的坑是存储文件名的设计。如果秒传成功后新记录指向旧文件的物理路径那么旧记录一旦被删除物理文件会被连带删除新记录就变成了死链。解决方法是给物理文件用MD5直接做文件名这样同一MD5永远只有一个物理副本任何记录删除都只是删元数据物理文件靠引用计数或定时扫描来清理。我见过不少系统在这里翻车答辩前自己删一个文件再试一次秒传后的下载立刻露馅。3.3 断点续传与下载的Range请求头断点续传的下载侧其实不用自己造轮子HTTP协议原生支持Range头。浏览器下载大文件中断后再次下载会带Range: bytesxxx-服务端只需解析这个头返回206 Partial Content即可。GetMapping(/download/{fileId}) public ResponseEntityResource download(PathVariable Long fileId, RequestHeader(value Range, required false) String range) { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(fileInfo.getFilePath()); if (range ! null range.startsWith(bytes)) { String[] ranges range.substring(6).split(-); long start Long.parseLong(ranges[0]); long end ranges.length 1 ? Long.parseLong(ranges[1]) : file.length() - 1; long length end - start 1; RandomAccessFile raf new RandomAccessFile(file, r); raf.seek(start); byte[] data new byte[(int) length]; raf.read(data); raf.close(); return ResponseEntity.status(HttpStatus.PARTIAL_CONTENT) .header(Content-Range, bytes start - end / file.length()) .contentLength(length) .contentType(MediaType.APPLICATION_OCTET_STREAM) .body(new ByteArrayResource(data)); } // 全量下载 return ResponseEntity.ok() .header(Content-Disposition, attachment; filename\ fileInfo.getFileName() \) .contentType(MediaType.APPLICATION_OCTET_STREAM) .contentLength(file.length()) .body(new FileSystemResource(file)); }这段代码的注意点有三个。第一RandomAccessFile的seek定位必须基于long文件超过2GB时int会溢出这是JDK老坑第二ByteArrayResource会把整个range读进内存所以单次range大小要限制一般限制在1MB以内否则并发下载几个大文件就把堆吃满第三Content-Disposition必须处理中文文件名直接用fileName会乱码要转成URL编码——用org.springframework.http.ContentDisposition构造可以规避编码问题。断点续传的上传侧就是上一节的分片上传两者配合起来才是完整的个人云盘文件传输方案。4. springBoot个人云盘必踩的坑超时、路径穿越与并发写坏文件4.1 大文件上传超时明明没报错前端却一直pending现象上传200MB以上的文件前端请求一直转圈几分钟后报超时后端日志看不出任何异常。原因有三层超时叠加在一起。第一层是SpringBoot的servlet容器默认没有全局超时但Tomcat的connection-timeout默认20秒仅针对连接建立不针对传输第二层是Nginx等反向代理的proxy_read_timeout默认60秒文件还没传完连接就被掐了第三层是前端axios默认无超时但浏览器本身对上传有软限制。大多数情况就是Nginx那层拦住了。解决Nginx配置里调大三个参数。server { listen 80; client_max_body_size 1024m; location / { proxy_pass http://127.0.0.1:8080; proxy_connect_timeout 300s; proxy_read_timeout 300s; proxy_send_timeout 300s; } }同时SpringBoot侧要放开文件大小限制application.yml里必须改这两个默认值spring: servlet: multipart: max-file-size: 1024MB max-request-size: 2048MB注意max-file-size是单文件上限max-request-size是单次请求总大小。分片上传时每个请求只包含一个分片所以这两个值可以设成一样。很多人在本地IDE里测没问题得益于IDE自带的端口直连一上服务器秒挂就是Nginx没调。这个坑我帮人排查过不下五次。4.2 文件名路径穿越上传个“..”。现象攻击者上传文件名为“../../../../etc/crontab”的文件下载或合并时文件被写到服务器系统目录导致任意文件覆盖。原因FileInfo的fileName字段直接拼接进了文件路径没有做任何标准化校验。Java的File构造函数不会拦截“..”符号new File(uploadRoot / fileName)会乖乖把你带到目录之外。解决路径标准化白名单校验。public String normalizeFileName(String fileName) { String normalized Paths.get(fileName).getFileName().toString(); if (normalized.contains(..)) { throw new BusinessException(非法的文件名); } if (normalized.contains(/) || normalized.contains(\\)) { throw new BusinessException(非法的文件名); } if (normalized.isEmpty()) { throw new BusinessException(文件名为空); } return normalized; }一句话原则对外展示文件名对内存储用UUID重命名物理路径里永远不要直接放原始文件名。这样既防了路径穿越又避免了同名文件覆盖问题。物理文件名用UUID原文件名存file_info的file_name字段下载时才拼接回Content-Disposition头。4.3 并发上传同一文件分片合并互相覆盖现象两个线程同时上传同一MD5的文件后端合并时出现文件内容混杂或者合并接口报“文件被占用”。原因合并逻辑没有做并发控制。线程A正在写target文件线程B也往同一个target写两个FileOutputStream同时打开后写的会覆盖先写的偏移量导致文件损坏。解决使用文件锁或ConcurrentHashMap做本机互斥。最简单可靠的是基于文件路径加锁private static final ConcurrentHashMapString, Object LOCK_MAP new ConcurrentHashMap(); public void mergeChunksWithLock(String fileMd5, String fileName) { Object lock LOCK_MAP.computeIfAbsent(fileMd5, k - new Object()); synchronized (lock) { doMerge(fileMd5, fileName); LOCK_MAP.remove(fileMd5); } }为什么不直接用synchronized(this)因为那是范围太大不同文件的合并也互相阻塞。按fileMd5粒度加锁同一文件的合并串行化不同文件并行执行。注意merge完成后要remove掉锁对象否则map里积累大量无用锁变成内存泄漏。4.4 数据库存绝对路径换个环境全部文件失效现象开发环境一切正常把项目打包部署到服务器或者换一台电脑历史上传的文件全部下载失败。原因file_info表里存的是类似D://dev/upload/xxx.jpg这样的绝对路径。环境一变路径前缀就失效文件还在但系统找不到。解决数据库一律存相对路径upload/xxx.jpg在配置里指定外部存储根目录cloud: disk: upload-dir: /data/cloud-disk业务代码里通过FileUtil拼接完整路径String fullPath uploadDir File.separator fileInfo.getFilePath();这样部署时只要保证upload-dir指向正确位置历史数据完全不用迁移。这是个人云盘从“能跑”迈向“能用”的关键一步。4.5 秒传校验张冠李戴只查文件名校验导致数据串位现象秒传接口返回成功但下载下来的文件内容和上传的文件名完全不匹配。原因秒传校验只比对fileName和fileSize忽略了MD5。两个不同文件恰好同大小同文件名被判定为同一文件。解决只信MD5不信文件名。查询条件只包含user_id、file_md5和deleted0完全不带fileName。同目录下不同名但内容相同的文件秒传时新文件名以展示为准物理文件始终只有一份。这个逻辑在3.2节代码里已经是正确的但很多人在实际写业务时为了“提高命中率”又把文件名加回了查询条件属于画蛇添足。4.6 文件预览乱码与Content-Type的玄学现象上传的txt文件在线预览时中文乱码图片能打开但浏览器不渲染。原因预览接口返回的Content-Type与文件实际类型不匹配。浏览器根据Content-Type决定渲染方式返回application/octet-stream会导致图片直接下载而不是显示。解决统一用第三方工具库判断MIME类型不用扩展名硬映射避免文件名大小写导致的分歧。GetMapping(/preview/{fileId}) public ResponseEntityResource preview(PathVariable Long fileId) { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(getFullPath(fileInfo)); MediaType mediaType MediaTypeFactory.getMediaType(fileInfo.getFileName()) .orElse(MediaType.APPLICATION_OCTET_STREAM); return ResponseEntity.ok() .contentType(mediaType) .contentLength(file.length()) .body(new FileSystemResource(file)); }预览的正确姿势是让浏览器干浏览器该干的事你只需要给对Content-Type。碰到图片不显示就去浏览器F12看响应头如果Content-Type变成了application/octet-stream说明是扩展名判断逻辑写错了这类问题基本都是半猜半查解决的真调起来十几分钟就够。5. 预览、分享与回收站把云盘从“作业”做成“产品”5.1 文件预览图片、文本能看Office文档靠什么个人云盘如果只能上传下载演示效果特别单薄。加上预览功能答辩时拉开差距的效果立竿见影。图片和文本预览最省钱也最容易。图片用上一节提到的直接返回MediaType的方式浏览器原生支持。文本预览注意编码问题统一转成UTF-8后再返回避免Windows上传的GBK文本在页面上乱码GetMapping(/preview/txt/{fileId}) public ResponseEntitybyte[] previewTxt(PathVariable Long fileId) throws IOException { FileInfo fileInfo fileInfoMapper.selectById(fileId); File file new File(getFullPath(fileInfo)); String content FileUtils.readFileToString(file, GBK); byte[] bytes content.getBytes(StandardCharsets.UTF_8); return ResponseEntity.ok() .contentType(MediaType.TEXT_PLAIN) .contentLength(bytes.length) .body(bytes); }注意这段代码用了GBK读取再转UTF-8看起来像是“读取-转码-读取”两遍实际上成了标准处理链先按GBK解码成Java String再按UTF-8编码成字节返回给浏览器。Office文档预览是另一个量级的问题。常见做法有两个一是集成开源项目KKFileView它本身就是SpringBoot的能预览doc、xls、pdf但强依赖OpenOffice/LibreOffice做转换环境配置极度玄学版本不对就是启动报错二是用jodconverter把Office文档转PDF再通过浏览器PDF预览。无论哪条路毕设都不建议把时间花在这里功能能跑通了就行。我见过太多人死磕Office预览最后答辩时用的还是备用电脑。5.2 分享链接与提取码短码生成的两行代码分享功能的核心是生成一个不重复的短码并设置过期时间。很多人用UUID直接作为分享码一个36位字符串贴到微信里又长又丑。更专业的做法是用62进制转换把自增ID编码成短字符串private static final String BASE62 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ; public static String encode(long num) { StringBuilder sb new StringBuilder(); while (num 0) { sb.append(BASE62.charAt((int) (num % 62))); num / 62; } return sb.reverse().toString(); }配合一张share_info表分享链接就是http://你的域名/share/{shortCode}提取码放在分享时让用户自定义4位数字。访问时先查分享是否存在、是否过期然后跳转文件详情页。这个功能加进去整个系统的产品完整性立刻上一个台阶。5.3 回收站软删除配合定时清理个人云盘的回收站不能真的把文件直接删掉。标准实现是file_info表增加deleted字段删除文件时执行UPDATE而不是DELETEDeleteMapping(/delete/{fileId}) public Result delete(PathVariable Long fileId) { FileInfo update new FileInfo(); update.setId(fileId); update.setDeleted(1); fileInfoMapper.updateById(update); return Result.ok(已移入回收站); }真正物理清理交给定时任务每天凌晨执行一次清理回收站中超过30天的记录Component Slf4j public class FileCleanTask { Scheduled(cron 0 0 2 * * ?) public void cleanExpiredFiles() { // 1. 查询所有deleted1且update_time早于30天前的记录 // 2. 判断物理文件是否被其他未删除记录引用按file_md5查 // 3. 无引用则删除物理文件有引用则只删记录 // 4. 删除file_info记录 } }这个定时任务怎么写很有讲究。同一个物理文件可能被多个记录共享秒传场景如果清理时直接删了物理文件其他记录就变成废链。所以删文件前必须先查引用计数。用file_md5分组统计未删除记录数为0才允许删除物理文件。这个逻辑放在论文里可以单独写一小节算半个小亮点。6. 论文里的“系统验证”怎么写从接口测试到并发弱网下的实测写毕业论文时“系统测试”章节如果只有“功能全部通过”这几个字答辩必被追问。你要用数据说话。6.1 用JMeter做并发上传压测JMeter压测上传接口注意两点一是要加HTTP Header Manager设置Content-Type为multipart/form-data二是要用“HTTP请求”采样器里的“文件上传”标签页选中你的测试文件。线程数设50Ramp-Up设10秒循环10次。6.2 弱网模拟的三个关键参数用JMeter的“Constant Throughput Timer”或QoS插件模拟弱网核心是限制上传带宽。一个常见配置是带宽限制200KB/s并发20线程对10MB文件做断点续传测试。6.3 用curl验证单分片和多分片的一致性写测试脚本的时候可以快一些但验证步骤不能少。拿同一个文件分别走完整上传和分片上传两条链路比对两份落盘文件的MD5是否一致。curl -F filetest.pdf http://localhost:8080/api/file/upload/chunk curl -X POST http://localhost:8080/api/file/upload/merge -F fileMd5xxx -F total2 -F fileNametest.pdf md5sum /data/cloud-disk/test.pdf6.4 写结果表结果表里至少包含并发数、平均响应时间、吞吐量、错误率、上传成功率、秒传命中率、断点续传成功率这几项。秒传命中率用同一文件重复上传100次统计断点续传成功率模拟传输中断后重试记录成功恢复次数。这几组数据凑齐论文里的系统验证部分基本就扎实了。6.5 一个值得复用的结论如果你的压测结果显示“并发50时上传成功率98%秒传命中率100%断点续传无数据损坏”那么系统性能验证的结论就可以写“该个人云盘管理系统在中等并发下能够保证文件传输的可靠性满足个人及小团队使用需求”。这句话是有依据的不是拍脑袋。落到个人习惯上我以前做毕设就是单机跑通就交答辩时老师问“你们系统能扛多少人同时传文件”我语塞了。那次之后我再做任何管理系统都会先跑一遍并发测试再写文档。如果你时间有限至少跑一组50并发看看错误率哪怕结果不理想论文里写“存在优化空间”也比拿不出数据强得多。这套方案做成什么样才算成功标准其实不高同一个文件上传下载一百次不丢字节换环境部署后旧数据还能访问并发二十个用户同时传大文件系统不卡死——做到这三点你的个人云盘毕业设计已经超过了大部分人。希望帮到你。本文还有配套的精品资源点击获取