企业官网建设流程全解析

简介：面向计科、信息安全、大数据、人工智能等计算机相关专业学生的完整毕业设计项目资料包，围绕Web云存储硬盘系统的设计与实现展开，覆盖需求分析、概念建模、数据库设计、前后端编码、论文撰写与格式修订全过程。既适合在校学生用作大作业、课程设计或毕设参考，也可帮助初学Web开发的读者了解一个完整系统从设计到落地的交付形态。压缩包共125个文件，整体约127MB，其中文档类以33个docx、8个doc和10个pdf为主，承载毕业论文、修改意见及过程记录；设计类包含23个vsdx Visio图示及pdm等建模文件，用图表呈现系统结构与数据库关系；另有20个png界面截图、sql数据库脚本与vue前端文件，直观对应实现细节。目前已有114人学习浏览。资料中既有论文初稿与修订稿，也保留了概念模型（cdm/cdb）、物理数据模型及系统设计图等过程性内容，便于对照文档理解设计思路；同时标注有修改意见、登记表等材料，还原真实毕设流程，适合作为课设答辩、毕设审查或初期项目立项演示的参考样本。

1. 课设题「web 云存储硬盘系统」到底在做什么：别把它做成网盘

每年课设和大作业里，「web 云存储硬盘系统」都是热门题目，但很多人一上手就把它做成了「网盘」，最后答辩被问两句就卡住。其实这个题目的考察点非常固定：用户怎么把文件传上去、传上去之后存在哪、文件元数据怎么管理、怎么把文件分享给别人，以及多用户之间怎么隔离。网盘只是它的一种可见形态，真正的难点在「存储」和「权限」这两个词的落地。

这篇不聊空泛的设计模式，直接给一套能抄、能改、能解释清楚的实现路线：后端用 Spring Boot 这类 web 框架，本地磁盘或对象存储当文件仓库，MySQL 管元数据表，前端用 Vue 做页面交互。新手能跟着把最小系统跑起来，熟手则能看到分片、秒传、防盗链这些加分项应该卡在哪。适合正在做课设、需要交完整代码和文档的同学，也适合想拿一套可复现方案去横向对比的人。

2. 选型与总体设计：文件服务、元数据库和对象存储怎么分工

做「web 云存储硬盘系统」时，设计部分比实现更决定答辩成败。常见做法是先把存储选型、数据表、接口三件事定下来，再写代码。这里有一个容易被忽略的点：文件的「存放」和文件的「描述」是两套系统，前者负责二进制流，后者负责文件名、大小、上传时间、用户归属这些能被检索的信息。不建议把文件内容直接塞进数据库表，除非你做的只是几十 KB 的小文本演示。

2.1 三种存储选型：本地磁盘、MinIO、对象存储，课设该用哪个

先给结论：默认选本地磁盘，时间充裕再考虑 MinIO 或云上对象存储。

如果你只有一到两周时间，本地磁盘是最稳妥的。具体做法是配置一个绝对路径的存储根目录，比如D:/cloud-storage/data或 Linux 下的/var/data/cloud-storage，上传时把文件写进这个目录，文件名用 UUID 重新生成，数据库里只保存存储路径和原始文件名。MinIO 的好处是能讲「对象存储 bucket 的概念」，但它本质上也是把文件落到磁盘，只是多了一层 API；如果老师问到生产环境怎么做，你可以说「把本地存储实现换成了 MinIO SDK」，代码里留一个接口即可。

还有一个很多人踩过的选择：用内存存储。比如把文件转成 byte[] 存到 HashMap 里，演示时确实快，但服务一重启文件全部丢失，这是课设里的大忌。文件系统至少能保证重启后数据还在。

2.2 数据表设计：用户、文件元数据、分享链接三张表够不够

对于课设规模，三张表足够：用户表、文件元数据表、分享链接表。这里给一套可以直接用的建表 SQL，采用 utf8mb4 字符集。

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) NOT NULL UNIQUE COMMENT '登录名', password_hash VARCHAR(128) NOT NULL COMMENT 'BCrypt 哈希后的密码', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 COMMENT '软删除标记' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE file_meta ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '归属用户，做数据隔离', file_name VARCHAR(255) NOT NULL COMMENT '用户看到的原始文件名', file_size BIGINT NOT NULL COMMENT '字节数，前端展示和配额用', storage_path VARCHAR(512) NOT NULL COMMENT '相对存储根目录的路径', file_md5 VARCHAR(64) DEFAULT NULL COMMENT '上传时算的 MD5，做秒传和去重', parent_id BIGINT DEFAULT 0 COMMENT '父目录ID，0 表示根目录', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, deleted TINYINT DEFAULT 0 COMMENT '软删除，回收站依赖这个字段', KEY idx_user_parent (user_id, parent_id), KEY idx_md5 (file_md5) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='文件元数据表'; CREATE TABLE share_link ( id BIGINT PRIMARY KEY AUTO_INCREMENT, file_id BIGINT NOT NULL COMMENT '哪个文件', token VARCHAR(64) NOT NULL UNIQUE COMMENT '分享码，网址里那个随机串', expire_at DATETIME NOT NULL COMMENT '过期时间，永不过期给个很大的日期', created_by BIGINT NOT NULL COMMENT '创建人', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分享链接表';

注意几个设计决策：第一，file_meta里存storage_path而不是全路径，这样换存储根目录不用改库；第二，file_md5加上索引，后面做「秒传」就是一条 SELECT 的事；第三，parent_id用于 文件树/目录结构，很多人把目录也当文件存，用is_dir字段区分，但课设只做「文件夹 + 文件列表」的话，给每条记录一个父目录 ID 就够了。用户和文件之间有user_id外键逻辑，但不建议物理外键，课设项目删数据时物理外键会带来一堆互斥问题。

2.3 接口与鉴权：RESTful 路径、状态码和 JWT 拦截器

接口设计不要太花哨，按资源风格来就好。下面这份接口清单是我经常用的，覆盖了课设的必做点：上传、列表、下载、删除、分享。

鉴权用 JWT 而不是 Session，原因很简单：前后端分离后，Session 要处理 CORS 携带 Cookie 的复杂配置，JWT 只要在请求头里带Authorization: Bearer xxx，后端写一个拦截器统一校验即可。登录接口返回 token，前端存到 localStorage，每次请求由 axios 拦截器自动添加到 header。拦截器里放行/api/auth/**和/api/share/**，其余接口都要求有效 token，这就是最基础的用户数据隔离。

3. 手写一个可运行的核心：上传下载与分片合并的完整链路

课设项目的核心链路只有一条：文件从浏览器到服务器，再从服务器回浏览器。中间涉及 MultipartFile 解析、磁盘写入、数据库记录、下载响应头设置。这一章会给出可以直接搬过去的最小代码，并解释每个参数为什么这么设。

3.1 Spring Boot 上传最小链路：MultipartFile 到本地磁盘

假设你已经建好了 Spring Boot 项目并引入spring-boot-starter-web，用下面的 Controller 加上一个存储服务类，就能跑通第一个上传接口。

@RestController @RequestMapping("/api/files") public class FileController { private final FileStorageService storageService; public FileController(FileStorageService storageService) { this.storageService = storageService; } @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file, @RequestParam(value = "parentId", required = false, defaultValue = "0") Long parentId) { if (file.isEmpty()) { return Result.error("文件不能为空"); } FileMeta meta = storageService.store(file, parentId); return Result.ok(meta); } }

MultipartFile是 Spring 封装的上传文件对象。需要注意：Spring Boot 默认会用内存或临时目录承接上传流，文件超过阈值后自动落盘，所以业务代码里不需要手动开流读取，直接交给transferTo就能把临时文件移动或复制到目标位置。parentId是可选的，默认 0 表示根目录。下面看存储服务实现：

@Service public class FileStorageService { private final Path storageRoot = Paths.get( System.getProperty("cloud.storage.root", "/data/cloud-storage")); public FileMeta store(MultipartFile file, Long parentId) { String originalName = file.getOriginalFilename(); String ext = StringUtils.getFilenameExtension(originalName); String storedName = UUID.randomUUID() + "." + ext; Path target = storageRoot.resolve(storedName); try { Files.createDirectories(storageRoot); file.transferTo(target); } catch (IOException e) { throw new BusinessException("文件写入失败: " + e.getMessage()); } FileMeta meta = new FileMeta(); meta.setFileName(originalName); meta.setFileSize(file.getSize()); meta.setStoragePath(storedName); meta.setParentId(parentId); // 这里调用 mapper 插入数据库，省略 return meta; } }

核心逻辑：把原始文件名和扩展名拆开，用 UUID 生成存储名，避免中文文件名、重名文件导致的路径冲突。storageRoot从系统属性读取，默认值是/data/cloud-storage。这里有个血泪经验：不要用相对路径./data。如果你在 IDE 里启动项目，工作目录是项目根目录，相对路径没问题；但如果部署时用 jar 包启动，工作目录变成了 jar 所在目录，路径一变，你上传的文件会出现在意想不到的地方，而且服务重启后容易找不到。使用绝对路径，并通过application.yml里的cloud.storage.root配置覆盖，才是可复现的。

application.yml里两个参数必须显式设置：

spring: servlet: multipart: max-file-size: 100MB max-request-size: 200MB

默认最大上传文件只有 1MB，不调这个配置，传一个稍大的 PPT 就会报MaxUploadSizeExceededException。max-file-size限制单个文件，max-request-size限制一次请求里的全部内容总和。做课设，这两个参数通常调到 100MB/200MB，同时要确认操作系统的/tmp目录有足够空间，因为 Spring 处理大文件时会在临时目录写中间文件。

3.2 大文件分片上传：前端切片、后端合并与并发控制

如果你只做到单文件上传，答辩时老师很可能追问：文件超过 100MB 怎么办？答案用分片。分片思路是前端把文件切块，逐个上传，后端收齐后合并。前端核心代码：

const CHUNK_SIZE = 5 * 1024 * 1024; // 5MB 分片，避免请求过多 const file = document.getElementById('fileInput').files[0]; const totalChunks = Math.ceil(file.size / CHUNK_SIZE); async function uploadChunks() { for (let i = 0; i < totalChunks; i++) { const start = i * CHUNK_SIZE; const chunk = file.slice(start, start + CHUNK_SIZE); const formData = new FormData(); formData.append('chunk', chunk); formData.append('index', i.toString()); formData.append('total', totalChunks.toString()); formData.append('fileMd5', fileMd5); // 上传前计算整个文件的 MD5 await axios.post('/api/files/chunk', formData); } // 全部完成后通知后端合并 await axios.post('/api/files/merge', { fileName: file.name, fileSize: file.size, fileMd5: fileMd5 }); }

分片大小 5MB 是一个平衡点：分片越小请求越多，容易触发浏览器并发连接限制；分片越大又失去分片意义。每个分片带index和total，后端用这些信息判断是否收齐。fileMd5是整个文件的 MD5，有两个用途：作为分片临时目录名，以及做最后的秒传判断素材。MD5 计算可以用 SparkMD5 库，在文件选择后异步算，几 GB 文件可能会卡几秒，建议放到 Web Worker 里。

后端接收分片的逻辑：

@PostMapping("/chunk") public Result receiveChunk(@RequestParam("chunk") MultipartFile chunk, @RequestParam("index") int index, @RequestParam("total") int total, @RequestParam("fileMd5") String fileMd5) throws IOException { Path chunkDir = storageRoot.resolve("chunks_" + fileMd5); Files.createDirectories(chunkDir); chunk.transferTo(chunkDir.resolve(index + ".part")); long uploaded = Files.list(chunkDir).count(); if (uploaded == total) { return Result.ok("chunk_ready"); } return Result.ok("chunk_ok"); } @PostMapping("/merge") public Result merge(@RequestBody MergeRequest request) throws IOException { Path chunkDir = storageRoot.resolve("chunks_" + request.getFileMd5()); Path mergedFile = storageRoot.resolve(UUID.randomUUID() + ".tmp"); try (OutputStream out = Files.newOutputStream(mergedFile)) { for (int i = 0; i < request.getTotal(); i++) { Files.copy(chunkDir.resolve(i + ".part"), out); } } // 合并完成，删除分片目录，写入文件元数据 FileMeta meta = fileMetaService.createFromMergedFile(request, mergedFile); return Result.ok(meta); }

合并时按index顺序把.part文件依次写入同一个输出流。这里有个「后端要不要做并发控制」的问题：如果前端串行上传，后端不需要额外加锁，因为同一时刻只有一个分片写入。如果你为了让上传更快而并行上传分片，后端就要用分布式锁或数据库唯一索引来防止分片丢失。课设做串行上传足够，答辩时能说出「串行保证顺序，并发需要额外处理幂等」这句话就够了。

合并完成后，mergedFile是临时文件名，最终元数据里的storage_path应该再替换成 UUID 命名的正式路径。合并后立刻把分片目录删掉，否则一次大文件上传会留下几十个临时文件。

3.3 下载响应与分享链接：Content-Disposition 和参数签名

下载接口比上传简单，但两个细节经常翻车：中文文件名乱码、下载被第三方盗链。前者用Content-Disposition处理，后者用签名参数。

@GetMapping("/download/{id}") public ResponseEntity<Resource> download(@PathVariable Long id) throws Exception { FileMeta meta = fileMetaService.getById(id); Path path = storageRoot.resolve(meta.getStoragePath()); Resource resource = new FileSystemResource(path); String encoded = URLEncoder.encode(meta.getFileName(), StandardCharsets.UTF_8) .replace("+", "%20"); return ResponseEntity.ok() .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename*=UTF-8''" + encoded) .contentType(MediaType.APPLICATION_OCTET_STREAM) .contentLength(meta.getFileSize()) .body(resource); }

filename*=UTF-8''是 RFC 5987 标准写法，浏览器会正确解码中文文件名。如果你只用filename=文件名，Windows 浏览器可能显示乱码。URLEncoder.encode之后要把+替换成%20，因为空格在路径里应该是%20而不是+。

分享链接的签名做法：生成分享记录时，把文件 ID、过期时间戳、随机 token 组合后存库；访问时后端校验 token 是否存在、是否过期。不需要对 URL 本身做复杂加密，因为 token 本身就是随机字符串。加上过期时间，分享接口就完整了。前端拿到 token 后拼成/api/share/{token}，再用 qrcode 插件生成二维码，扫码后可以用手机访问下载页。

4. 前端与交互：Vue 3 页面、上传进度条和分享链接的实现

后端把接口交出后，前端页面的体验决定了课设的完成度。老师验收时不会只看接口，他们会打开页面，上传文件、刷新、下载、分享，走一遍完整流程。所以前端最少要有文件列表、上传按钮、进度条、删除和分享入口。

4.1 页面骨架：表格 + 文件夹路径，别用花哨的卡片流

文件管理类的页面，推荐用表格而不是卡片瀑布流。原因：文件列表需要展示文件名、大小、上传时间、操作按钮，表格天然适合这种结构化信息；卡片流在文件数量多时会让页面冗长。给每个目录增加一个「在当前文件夹上传」的功能，就实现了文件夹概念。数据来源是/api/files/list?parentId=xxx，接口返回当前目录下的文件和子目录标记。我一般会在file_meta里加一个is_dir字段，或者用parent_id递归查询，前端渲染时对目录显示「进入」按钮，对文件显示「下载/删除/分享」按钮。

刷新保持目录状态：用vue-router的 query 参数，比如/list?parentId=123，这样刷新页面不会退回根目录。如果不用路由，用全局变量存currentParentId也能跑，但刷新就丢了，体验会打折。

4.2 上传进度条与取消请求：onUploadProgress + AbortController

上传进度是云存储项目的脸面。axios 提供了onUploadProgress，它能拿到浏览器底层上报的loaded和total，不需要后端额外配合。

const controller = new AbortController(); async function uploadFile(file) { const formData = new FormData(); formData.append('file', file); formData.append('parentId', currentParentId.value.toString()); try { await axios.post('/api/files/upload', formData, { timeout: 0, // 大文件上传不能走默认超时 onUploadProgress: (event) => { if (event.total) { progress.value = Math.round((event.loaded / event.total) * 100); } }, signal: controller.signal }); } catch (error) { if (axios.isCancel(error)) { console.log('上传已取消'); } } } function cancelUpload() { controller.abort(); }

必须设置timeout: 0，因为 axios 默认 0 是不超时，但如果你在创建实例时设置了默认 10 秒超时，大文件上传必挂。onUploadProgress的event.total是当前请求体的总字节数，包含 multipart 的头部和文件，所以进度到 100% 时不代表服务器已经写完，只代表浏览器把数据发完了。要更精确可以等后端返回后再把进度固定到 100%。

4.3 分享二维码与有效期：后端校验比前端更可靠

分享功能的前端很简单：点击「分享」按钮，弹出对话框，选择有效期（1 天 / 7 天 / 永久），调用/api/share，拿到 token 后生成二维码。这个接口如果只做前端校验，用户可以手动改系统时间绕过，所以有效期判断必须放在后端。

后端拿到分享记录后，用文件 ID 拼接一个访问地址，前端用qrcode库渲染：

import QRCode from 'qrcode'; QRCode.toCanvas(canvasRef.value, shareUrl, { width: 200, margin: 2, errorCorrectionLevel: 'M' });

errorCorrectionLevel: 'M'是二维码容错级别，M 级别足够扫描，同时不会让二维码太密。分享出去的页面要隐藏文件列表，只展示一个下载按钮，并且后端对/api/share/{token}的下载接口做独立校验，不要求登录 token，只校验分享 token 和过期时间。这样才真正实现了「不登录也能下载」。

5. 云存储硬盘系统避坑清单：五个让课设翻车的典型问题

这一章集中写我在帮别人调这个课设时遇到的高频问题。每条都是「现象 → 原因 → 解决」的套路，你可以直接对照自己的项目排查。

1. 上传稍大的文件就报 413 或 500。现象：超过默认限制就报MaxUploadSizeExceededException，或者请求直接超时。原因：Spring Boot 默认max-file-size只有 1MB，同时 Nginx 默认client_max_body_size是 1MB，两者任意一个没调都会限制上传。解决：后端在application.yml里把max-file-size和max-request-size调大；如果用了 Nginx 反向代理，在 server 块里加上client_max_body_size 200m;。注意max-request-size要大于等于max-file-size，否则多个文件同时上传时总请求体超限。

2. 下载时中文文件名全变%E4%B8%AD%E6%96%87或乱码。现象：浏览器下载的附件名是百分号编码，或者干脆是乱码。原因：前端拿到下载链接直接window.location.href = url，没有经过任何编码处理；或者后端只写了filename=中文而没有filename*。解决：后端用我上面给出的filename*=UTF-8''写法，前端下载时用 axios 以 blob 方式请求，再从响应头里解析文件名。后者更稳，因为 blob 方式不会触发浏览器直接打开 PDF、图片文件。

3. 前后端分离后，接口请求被浏览器拦截。现象：控制台报CORS policy错误，请求发出去了但响应被浏览器拦下。原因：前端端口（比如 5173）和后端端口（比如 8080）不一致，形成了跨域。解决：后端配置一个CorsFilter，允许前端 origin 和所有常用方法。注意：allowedOrigins("*")和allowCredentials(true)不能同时用，浏览器不允许这样的组合。开发环境用http://localhost:5173，生产环境换成实际域名。

@Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:5173"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); }

4. 重启后文件丢失或路径找不到。现象：上传成功，但重启服务后列表里的文件下载全部 404；或者上传时直接报NoSuchFileException。原因：使用了相对路径，比如new File("upload/")，它在 IDE 里工作正常，但换到 jar 包运行时目录变成系统临时目录；或者用了@CrossOrigin但没配置实际文件存储路径。解决：把存储根目录配置成绝对路径，写入application.yml，启动时打印日志输出路径和是否存在。前端能忍受，但要接受「项目运行目录变化导致文件找不到」这类翻车，必须在开发时就避开。

5. 删除文件后数据库记录还在，或者文件被删但记录没删。现象：删除接口返回成功后，刷新列表文件还在；或者列表没了，但下载接口还能从磁盘把文件读出来。原因：删除时先删了文件，然后数据库操作失败，文件没了但记录还在；或者反过来。数据库操作可以放在事务里，但文件系统操作无法回滚，所以跨系统的数据一致性是课设里最大的黑匣子。建议方案：删文件时先在数据库把记录标记为deleted=1，这一步是事务保护的；然后异步删除磁盘文件，并由一个定时任务定期扫描deleted=1且落盘超过 1 天的记录，真正删文件并把数据库记录物理删除。这样用户看到的「删除」是软删除，后台能保证最终一致。

6. 让答辩更硬的进阶用法：秒传、软删除和并发压测

这一章讲三个能让答辩加分的小动作，它们都不需要大量代码，但能明显体现你对「web 云存储硬盘系统」主题的理解深度。

6.1 秒传：用已有 MD5 元数据跳过文件写入

上传接口在接收文件前先按file_md5查数据库：如果当前用户已经上传过同一 MD5 的文件，并且原始文件还在磁盘上，就直接返回一条新的元数据记录，不写磁盘。实现只需在上传接口入口加一段逻辑：

if (fileMd5 != null) { FileMeta existing = fileMetaMapper.findByMd5(fileMd5); if (existing != null && Files.exists(storageRoot.resolve(existing.getStoragePath()))) { return Result.ok(FileMeta.copyForUser(existing, currentUserId)); } }

注意copyForUser要生成新的记录，不能直接返回别人的文件引用，否则会导致多用户间 ID 混乱。秒传算是「文件去重」的简化版，答辩时能解释清楚这个分支，老师会觉得你不只是写了 CRUD。

6.2 软删除与回收站

回收站是一个不到 100 行但性价比极高的功能。在file_meta里已经有deleted字段，列表接口只查deleted=0；删除操作改为UPDATE file_meta SET deleted=1 WHERE id=#{id}；回收站列表查deleted=1；恢复操作再改回deleted=0。真正的磁盘删除交给定时任务。这样答辩时你可以讲「文件数据保留期策略」，比直接硬删高级很多。

6.3 用 curl 脚本做并发压测验证

课设文档里能放几张压测截图，是让整套方案落地的有力证据。不需要用 JMeter，一个 bash 循环就能模拟并发上传：

for i in {1..20}; do curl -s -F "file=@./test_$i.txt" \ -H "Authorization: Bearer $TOKEN" \ http://localhost:8080/api/files/upload & done wait echo "并发上传完成"

后台运行 20 个并发请求，观察后端日志里有没有线程阻塞、文件是否有损耗。更严谨的验证是上传后下载回来，计算两份文件的 MD5 做对比：md5sum original.txt downloaded.txt。这个结果可以直接放进实验报告，说明系统在并发场景下没有产生文件损坏。我自己的习惯是每次改完存储逻辑都跑一遍这个脚本，防的是 Nginx 或 Tomcat 连接数限制这种玄学问题。希望这些经验能让你少走一段弯路，把时间花在真正能展示能力的功能上。

本文还有配套的精品资源，点击获取