如果你正在纠结毕业设计做什么方向，或者已经选定了文档管理这类系统却不知道怎么把它做成一套能过盲审、能应付答辩的完整项目，那这篇内容应该正好是你需要的。我见过太多同学拿着SpringBoot+Vue的模板项目改个名字就交差，结果一被问数据库为什么这样设计、权限怎么校验的就卡壳。这篇文章我会把一个基于SpringBoot+Vue+MySQL的在线文档管理系统从技术选型、数据库设计、核心功能实现到部署论文的完整链路拆开讲透，重点说清楚每一处关键选择背后的逻辑，以及那些书本上不会写的踩坑记录。

这套系统能解决的问题很实在：学校、中小企业内部需要一套支持多人协作、分级权限、文档在线预览和版本管理的平台，但市面上的商用系统要么太重要么太贵。用SpringBoot+Vue这套主流组合做毕设的优势在于：后端生态成熟、前端组件现成、MySQL适合中小规模数据场景，整体工作量可控，非常适合在几个月内独立完成，同时又有足够的深度支撑论文和答辩。

无论你是还没定题的大四学生，还是想快速上手全栈项目的在职开发者，这篇文章都会按实际动手的顺序给你捋清楚。我会把后台管理、文件上传下载、权限控制这些核心模块的关键代码思路和参数配置逻辑都讲出来，最后再附上我从实际部署和调试中整理出来的问题排查表。

1. 项目整体设计与技术选型思路

1.1 为什么是SpringBoot+Vue+MySQL这个组合

先聊一个最常见的问题：市面上的毕设题目千千万，为什么文档管理系统普遍选择这三件套？答案不在于它们各自有多牛，而在于它们组合起来的成本最低、容错率最高，并且能覆盖一个毕设需要展示的几乎所有知识点。

后端用SpringBoot，核心价值在于它把Spring那套繁琐的XML配置全部干掉，通过自动配置和起步依赖让项目几分钟内就能跑起来。对于文档管理系统这种典型的CRUD外加文件交互场景，SpringBoot的Web模块、数据访问模块、安全模块几乎都是开箱即用。你做毕设的时候不需要去理解Spring IoC容器底层是怎么Bean循环依赖的，但是你能快速把接口写出来，这就是它的工程价值。

前端选Vue，理由也很直接。现在企业里前后端分离已经是标配，你毕业以后进任何团队几乎都要面对Vue或React这类现代前端框架。Vue的响应式数据绑定和组件化开发特别适合文档管理这种界面状态多、操作反馈频繁的管理系统。加上Element UI或者Ant Design Vue这套现成的组件库，表格、弹窗、表单、上传组件都能直接拖过来用，视觉上也不会显得廉价。

MySQL没什么好争议的，文档管理系统的数据总量通常远没到需要上分布式数据库的量级。SQL语句的编写、索引的优化、事务的隔离级别这些都是面试官喜欢问的东西，在MySQL上你能亲手实践一遍，这比背题有意义得多。而且MySQL和SpringBoot之间的配合资料遍地都是，遇到问题五分钟内基本能找到解决方案。

1.2 这套系统的实际业务需求从哪来

项目要想做好，第一步不是写代码，是把需求想清楚。在线文档管理系统听起来很大，但落到实际场景里其实可以从三类用户的视角去拆解：

首先是系统管理员，他关心的是有多少人注册了这个系统、大家状态是否正常、有没有人传了些不该传的文件类型。所以你需要一个用户管理模块，支持禁用、启用账号，需要有一个可视化的文件概览看板。

其次是普通用户，他关心的是把自己手里的文档传到云端、能分类存放、能预览、能下载、能分享给别人。这意味着系统需要支持大文件上传、文档分类目录、在线预览功能和分享链接生成。

最后还有一个容易被忽略的角色：部门或者项目组的管理者。他强调多人协作时的权限边界，比如某个团队的文档只有团队成员能编辑，其他人只读，甚至完全不可见。这就要引入角色和权限的细分设计。

你把这些需求整理成一份简单的需求清单，后面的数据库设计和接口设计全部从这份清单出发，论文第一章的选题背景和第二章的需求分析也就顺理成章地写出来了。很多同学喜欢一上来就建表，结果表结构跟需求对不上，返工成本极高。我建议你先花一个晚上把角色、功能、流程理清楚，向前迈出这一小步，后面能省下好几个通宵。

1.3 方案优势和需要规避的坑

这套组合方案的优势非常明显。技术上足够主流，不会被质疑老套；代码量适中，即使你是从零开始，三个月的时间也足够完成核心功能。而且前后端分离的结构特别适合论文里画架构图、在答辩时展示模块化的开发思路。

但这条路也有几个典型的坑要提前说：

第一，版本兼容性问题。SpringBoot 2.x和3.x的差异很大，如果你学的时候看的是2.x教程，自己下载的却是3.x依赖，光javax到jakarta的迁移就能卡你好几天。选定了教程就要尽量跟教程统一大版本。

第二，文件存储路径别放在项目内部。很多同学贪方便把上传的文件存到项目的static目录下，这在本地跑没问题，但一旦打成jar包部署，你会发现上传的文件在重启后消失了，或者根本写不进去。正确的做法是把文件存储路径配置成操作系统的绝对路径，比如D盘的一个专用目录或者Linux下的/data/files，通过配置项动态读取。

第三，不能把在线预览做成强制下载。Iframe内嵌预览需要一个能返回PDF或者图片格式的接口，所以你在设计上传模块时，心里就要先想好预览的方案，比如用OpenOffice或者kkFileView转换格式，别等上传功能做完了才发现预览实现不了。

2. 核心功能模块拆解与数据库设计要点

2.1 核心功能模块划分

在线文档管理系统从功能面上可以划分成这么几个核心模块，每个模块对应论文中的一章和代码中的一个功能包：

用户与权限模块负责用户的注册、登录、个人信息修改，以及基于角色的菜单访问控制。权限这块我用的是主流方案：用户表、角色表、权限表加三张关联表，细粒度到按钮级别。虽然毕设评审老师不会真的点到你每个按钮去测权限，但这样设计是加分项。

文档管理模块是业务核心。包括文档上传、下载、在线预览、编辑重传、版本管理、批量删除和移动分类。上传时要校验文件大小和扩展名，重名文件如何处理、分片上传是否需要支持这些都是需要提前想清楚的细节。

分类管理模块维护一棵文档分类树，支持一级和二级分类就够了。这里要注意分类和文档是双向关联的，删分类之前必须先处理该分类下的文档，要么禁止删除，要么提示用户转移文档。

分享管理模块生成带提取码的外链，支持设置有效期。这是一种很常见的业务功能，而且背后的实现逻辑很适合写进论文，比如分享码生成算法、有效期状态判断、访问次数统计等。

系统管理模块就是用户列表、重置密码、操作日志、参数配置这些后台功能。操作日志这块容易被忽略，但如果你做了，答辩的时候这是很好的亮点，能说明你考虑了系统的可追溯性和安全性。

2.2 数据库表结构设计精讲

数据库设计是整个项目的地基，地基歪了后面写Mapper都别扭。这里我给出核心表的设计思路，你可以在概念模型基础上按自己的需求调整：

用户表（sys_user）包含用户ID、用户名、加密后的密码、昵称、邮箱、手机号、头像地址、状态字段。需要注意的细节有两个：一是密码必须存BCrypt加密后的密文，绝对不能明文存；二是逻辑删除字段要用delete_flag而不是物理删除，这样可以保留操作追踪和历史数据。

角色表（sys_role）和菜单权限表（sys_menu）是三张基础表。用户和角色多对多，角色和菜单多对多。菜单表里要有菜单类型字段区分目录、菜单和按钮。这里给一个建议：按钮权限可以不用做得太深，菜单级别的权限控制已经足够形成毕设亮点。

文档表（doc_file）是业务主表。字段设计上最基本的包括文档ID、文档名称、文件存储名（防止文件名冲突）、文件大小、文件类型、存储路径、上传者ID、所属分类ID、下载次数、创建时间。如果你要支持版本管理，就要再加一个文档版本号字段，同时设计一张文档版本子表记录每次更新的快照，包括更新时间、更新者、变更说明、文件大小和存储路径。

分享表（share_info）包含分享ID、文档ID、分享人ID、分享码、有效期、访问次数、创建时间。分享码建议用UUID截取或者哈希值生成，碰撞概率低，也不容易被恶意猜测。

为了让论文更有服务意识，我建议加一张操作日志表（sys_log），记录用户ID、操作类型、操作内容、IP地址、操作时间。SpringBoot里用AOP切面做日志记录非常顺手，这段代码不复杂，但写进论文的亮点设计和系统测试章节都是实用素材。

表之间的关联关系用ER图展示在论文里，这就是第三章概要设计最漂亮的一张图。建表时统一使用InnoDB引擎，utf8mb4字符集，主键用自增Long型，时间字段统一用datetime，这样规范不容易出错。

2.3 数据库设计中的几个关键决策

既然是基于MySQL，就要充分利用它的特性。推荐你在经常查询的字段上建立索引，比如用户表的状态字段、文档表的创建时间和文档分类ID。但要避免对每个字段都加索引，索引越多写入越慢，这个平衡点在毕设阶段不需要太强的优化，建几个常用索引展示你懂这块就够了。

事务设计上，删除一个分类时如果同时要转移该分类下所有文档到默认分类，涉及多张表的UPDATE操作，就必须用@Transactional注解让这些操作处于同一个事务中，要么全部成功，要么全部回滚。在论文事务控制章节里，这是一个很好的例子。

还有一点值得特别注意：文件上传本身不要和数据库记录放在同一个事务里。先保存文件到磁盘，再插入数据库记录，顺序反了会导致磁盘出现无用的孤儿文件。你不用纠结这个问题多深，能答清楚就行。

3. 前后端核心实操过程与配置细节

3.1 后端工程搭建与关键依赖配置

后端的目录结构按Maven标准布局，groupId用com.example就能满足毕设要求，artifactId用统一的模块名。pom.xml里最核心的依赖就几样：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok和JWT相关的依赖。MyBatis-Plus值得一提，它帮你把单表的CRUD代码全部生成好，你不用手写那些重复的Mapper XML，这一点能节约大量时间，而且它自带的分页插件在文档列表分页时非常好用。

application.yml里需要配几项关键内容，每项都有它的道理：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/doc_system?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 50MB max-request-size: 100MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleteFlag logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: your-secret-key-here expire: 7200000

数据库连接串里serverTimezone=Asia/Shanghai这个参数如果你是新手很容易漏，漏了之后系统时间会差8个小时，日期字段全部错乱。multipart的这两行是让系统支持大文件上传，你要是不配，默认1MB的限制会让你传个PPT都失败。MyBatis-Plus的逻辑删除配置也很关键，这样你执行delete操作时它只做update，从全局保证了数据不物理丢失。

JWT密钥需要你自己定义一串足够复杂的字符串，过期时间单位是毫秒，7200000就是两小时。毕设系统里两小时过期是合理的，太短了用户老是重新登录，太长了有安全风险。写完登录接口后你必须测试一下JWT在过期后是否返回401状态码，并让前端知道去跳转登录页，否则用户会卡在一个没有提示的假死页面上。

3.2 认证与权限控制的代码思路

我不建议用Spring Security，虽然它是行业标准，但学习曲线对毕设来说太陡了。更多人选择用拦截器加JWT的方式，逻辑清晰且完全满足业务需求。

实现思路是这样的：用户登录成功后，后端根据用户ID和用户名生成一个JWT Token返回给前端。前端每次请求都在请求头里带上这个Token，后端写一个拦截器拦截除登录、注册以外的所有接口，解析Token拿到当前用户信息，然后塞进ThreadLocal里供当前请求使用。

关键的校验逻辑里，你要记得验证Token是否过期、签名是否正确。拦截器的注册通过WebMvcConfigurer的addInterceptors方法完成。给需要放行的路径留一个白名单，包括登录接口、注册接口、文档预览接口和分享访问接口，这样别人不需要登录就能点开你分享出去的链接查看文档。

权限控制方面，后端在需要权限的接口上做角色判断。比如删除用户只有管理员能调，文档列表普通用户和管理员都能看。这里不需要做到Spring Security那种注解级权限，但你自己心里要清楚：前端隐藏按钮只是用户体验层面的处理，真正拦人必须在后端。答辩时如果你能说出这句话，专业度立刻不一样。

3.3 文件上传与下载的实现细节

文件上传接口是文档系统的门面。前端选择文件后通过Axios以multipart/form-data方式POST到后端接口，后端用MultipartFile接收文件，处理逻辑分四步：

第一步校验文件大小和扩展名，大小限制已经在yml配了，扩展名这块我建议维护一个白名单集合，包含doc、docx、xls、xlsx、ppt、pptx、pdf、txt、zip这些常见类型，防止用户上传可执行文件或脚本文件。

第二步生成存储文件名。用UUID作为新文件名加原始扩展名，这样能彻底避免同名文件互相覆盖的问题。存储目录按月分文件夹，比如2025/06/，这样当文件量上来之后，目录里不会堆几千个文件导致打开都卡。

第三步把文件通过transferTo方法写到磁盘指定路径。这个路径从配置里读取，不要在代码里写死。

第四步向数据库doc_file表插入记录，存储文件名、原始文件名、大小、类型、路径、上传者这些信息。响应给前端一个包含文件ID和访问URL的封装对象。

下载功能需要注意一个坑：如果只是把文件路径拼接成URL返回给前端，用浏览器直接访问，虽然方便但没法做下载次数统计和权限拦截。正确做法是后端提供一个/download接口，根据前端传来的文件ID从库里查记录，校验权限后用HttpServletResponse将文件流写给前端。代码里要特别注意Content-Disposition响应头需要做URLEncoder编码，否则中文文件名下载下来是乱码。

3.4 前端Vue页面搭建与接口对接

前端用Vue CLI或者Vite创建工程，Vite现在更主流，启动速度快，配置也简单。安装vue-router和axios以及UI组件库后，把工程结构按views、components、router、utils、api分包。

页面规划上，登录页和注册页是一组；主布局拉一个左侧菜单栏、顶部导航栏和内容区；文档列表页是核心页面，用表格展示文档名、大小、上传人、上传时间、操作按钮，操作按钮区放预览、下载、分享、编辑、删除、移动；分类管理页用树形控件展示分类层级；分享管理页展示我发出的和他人分享给我的；系统管理页放用户列表和日志列表。

前后端对接时有一个常见的痛点，就是请求响应结构。你一定要在前端axios的响应拦截器里统一处理业务状态码。比如后端约定返回结构是{code: 200, message: '操作成功', data: 结果}，前端拦截器判断code是否为200，不是就弹出错误消息，是就直接把data返回给页面使用。统一封装这块做好了，后续每个页面写代码都会轻松得多。

文件预览的实现我多说一句：不同类型文件需要不同处理方案。PDF和图片直接通过新窗口访问URL就能预览；Office系列的doc和docx，一种方案是后端用工具转换成PDF再预览，另一种方案是集成现成的开源预览服务。毕设阶段你选择把后端文档在线转换为PDF的方式，代码量可控，而且论文里有技术亮点可以写。

3.5 本地联调与打包部署

本地开发时启动后端，SpringBoot项目默认端口8080；启动前端工程跑在8081端口，通过vue.config.js的devServer.proxy配置把/api转发到后端8080，这样开发时就没有跨域问题。到这里前后端联调基本就通了。

部署阶段最稳妥的方案是云服务器上装好JDK、MySQL、Nginx环境，前端打包生成dist目录里的静态文件放到Nginx的html目录下，后端打包成jar包用java -jar命令启动运行。Nginx需要配置两个关键部分：一是http模块里配好前端静态资源路由，二是location /api/的代理转发，把接口请求转发到后端端口。要求不高的话也可以把前后端打成一个包，但用Nginx分离的方式更贴近企业实际部署方式，部署文档也能写得更有内容。

There's also a specific detail worth sharing: after backend packaging, don't forget to configure the file upload path to a directory across from the jar package, for example /www/docSystem/files/. If left as a relative path, you may find the system runs fine on one machine but the upload path remains relative to wherever the startup command happens to be.

4. 常见问题与排查技巧实录

4.1 数据库连接与环境启动问题

一个出现频率最高的现象是后端启动报Access denied for user。这通常不是代码问题，而是MySQL里没有创建对应的用户或者密码不匹配。你可以先用Navicat命令行工具手动连接MySQL确认账号密码没问题，再去排查配置文件的URL拼写。还有一个容易掉进去的坑是时区问题：如果不加serverTimezone参数，高版本的MySQL驱动会直接报错，加了之后又发现时间差8小时，那就是时区值选错了，Asia/Shanghai才是对的。

另一个让我记忆深刻的状况是：后端启动成功但前端请求全部404，页面转圈转个不停。这种问题分两步排查：先打开浏览器开发者工具的Network面板，看请求到底打到哪个地址了，如果请求走的确实是代理地址，再确认后端控制台有没有对应的接口访问日志。九成的情况是devServer的proxy配置没生效，或接口路径少了/api前缀。

4.2 文件上传与预览的经典连环坑

文件上传失败在我接触过的毕设项目里是重灾区。第一种报错是unexpected end of file，多半是Nginx默认的client_max_body_size太小，只有1MB，你在Nginx配置里加一行client_max_body_size 100m再重载配置就能解决。第二种报错是磁盘路径不存在，transferTo直接抛IOException，处理方式很简单，写代码时先判断目录是否存在，不存在就用Files.createDirectories先创建。第三种报错就是文件传上去了但数据库没记录，响应时间特别长，要检查事务注解是不是把文件保存和数据库写入圈进了同一个事务，如果是就拆开。

预览在线的文档经常出现中文文件名乱码问题。根子在于下载响应头Content-Disposition里的filename，对中文必须用URLEncoder.encode处理，浏览器端再decodeURIComponent回来。你还要注意编码后不要重复encode，否则前端会很困惑。

4.3 常见问题速查表

我把实际调试中遇到的高频问题整理成一张速查表，方便你照着排查。

4.4 提升答辩通过率的技术亮点

毕设答辩和平时做项目有个不太一样的地方：老师看的不仅是你做出来了没有，更看重你会不会讲思路、有没有思考过更深度的问题。建议你在已有的功能上准备三个加分亮点，每个都不需要花太多工作量，但能明显拉高答辩评价。

第一是系统日志的AOP实现。用切面注解把用户主要操作记录到日志表，开发量不大，但能展示你对系统可维护性和安全审计的思考。答辩时可以主动阐述日志对追溯和异常排查的价值，而不是被动等着老师提问。

第二是分享外链的有效期控制与访问次数统计。这个功能虽然简单，但它涉及业务状态的动态判断与并发下的自增处理，回答好这个问题能展示你的严谨性。批量删除的回收站设计就更日常了，实现上只需要在删除时将状态置为回收状态，列表查询时过滤掉这条记录，清空回收站时再真正删除物理数据和磁盘文件。这类细节能体现产品思维的完整性。

第三是并发控制。文档管理会有多人同时编辑同一份文件的场景，你可以用MySQL的行锁或者乐观锁版本号机制去处理版本冲突，这个概念写到论文里相当拿得出手，期末答辩时老师如果问工作量怎么保证，你可以指着流程图和时间线说明每个功能点的推进周期。

5. 论文撰写重点与部署文档实践

5.1 毕业论文的结构安排

毕设论文的结构基本是大同小异的八股文框架，但框架虽然固定，内容仍要基于你的真实项目来写才经得起审查。论文的摘要和绪论部分要突出实际应用价值和当前痛点：纸质文档或本地分散式管理难度大、缺乏协作与权限机制、查询共享不便，线上文档管理系统能有效解决这些问题。

文献综述和系统开发相关技术介绍部分，不要大篇幅抄教材，重点去铺垫SpringBoot的自动配置机制、Vue的响应式原理、MySQL的InnoDB引擎特性。这些铺垫要和后面的系统设计形成呼应，而不是凑字数用的理论堆砌。比如你后面用了MyBatis-Plus的逻辑删除，那这里就应该提一嘴它在数据恢复和审计中的价值。

需求分析章节里可以放用例图、用例表，描述每个角色的操作权限与目标。概要设计章节放架构图、技术架构图、功能结构图和ER图，这是论文的骨架。详细设计章节放核心模块的类图、时序图和数据库表结构说明，把典型接口的请求与响应消息列出来。系统实现章节配合截图展示功能和关键代码片段。测试章节按测试阶段分类，方法上要按功能模块去写，用表格形式把测试用例、期望结果和实际结果列出来，这样比通篇文字描述清晰得多。

最后在总结与展望段落里，不要用没有信息量的套话比如“系统功能基本实现，运行正常但还有不足”就划过去。你可以很具体地写“当前系统暂未支持全文内容检索，后续可以引入搜索引擎服务实现文档内容的深度检索；文档预览目前仅支持服务端转换之后的文件查看，对格式兼容性要求高的场景还需要引入专门的组件化在线预览服务”。这些内容具体、可落地，比你空泛地说“未来还要完善”要有说服力太多。

5.2 部署文档怎么组织才实用

部署文档的目标是让一个从没碰过你这项目的人，按照文档从零部署到一台干净的服务器上。我习惯按这样的顺序组织：环境准备（JDK版本、MySQL版本、Nginx版本）、创建数据库导入SQL、后端配置修改说明（数据库密码、JWT密钥、文件上传路径）、后端打包与启动命令、前端构建说明、Nginx配置样例、访问测试。

部署文档里最容易出问题的是路径写得太随意。建议大目录和文件示例全部写成“项目部署目录统一放在/opt/docSystem”，数据库名写成doc_system，端口统一8080。每一步配置命令都给出完整可复制的命令行代码，包括创建目录、解压、启动服务这些基础操作。如果你用云服务器，防火墙和安全组放行8080和80端口这件事，很多人会忘记写，但这个坑一旦踩了，外部怎么都访问不了。

5.3 答辩预演的核心问题准备

答辩老师大概率会从架构、安全、并发这三个方向提问。架构方向的问题是：SpringBoot+Vue前后端分离的好处是什么？你可以答前端静态资源由Nginx承载、后端接口独立进程部署、两者通过HTTP或HTTPS通信，开发上并行且部署上解耦。

安全方向的问题更好准备：密码为什么要加密存储，而不能用明文？脱敏回答即可，避免多余讲解。文件上传的非法内容是怎么拦截的？这个可以从扩展名白名单、大小限制和文件内容类型校验三个层面展开。分享外链的有效期是怎么控制的？可以提数据库记录过期时间加上查询时用时间条件判断，同时附上定时任务的兜底方案或延迟清理策略。

并发方向的问题属于加分区间：多个用户同时下载一个文件会不会有问题？这里可以分点回答，文件流读取各自独立互不影响，下载次数字段用自增方式完成并发安全。文档同时编辑冲突如何解决？不熟悉的同学可以直接说用乐观锁版本号实现，后端更新时加上版本号比对条件，匹配不上就提示文件已在别处被修改，请稍后重试。

其实到答辩这个环节，项目本身能跑通是首要前提，讲解时冷静清楚、对表结构了如指掌，整个表现比技术深度更能打动评审老师。把上面这些想清楚，你已经比大多数同组同学准备得充分了。

6. 从项目完成到经验沉淀的几点建议

整套系统做完之后，我建议你逼迫自己做一次完整的重构复盘。不要急着把项目丢进压缩包就算完事，你把当初设计数据库时的草稿打开，对照最终表结构，看看哪些字段当时加了但实际用得少，哪些字段后来才发现必须加。这个切入点能让你的论文结论更加真诚，也是你真正从做项目变成懂项目的那一步。

代码层面，试着把你的接口返回类统一成一个Result类型，把异常处理统一放到全局异常处理器里，把工具类单独抽到一个包中。这些动作看起来跟功能无关，但会让你的代码评审好过很多，也直接体现工程素养。目录结构建议划分成controller、service、mapper、entity、config、common这几个标准包，按业务模块建立子目录，class命名不要太随意，例如DocFileController这种命名方式的一致性是很多人忽视的隐性加分项。

资料归档阶段，把项目的数据库建表脚本存放在独立sql目录中，把所有的依赖版本号在pom.xml里用properties属性管理起来，把接口文档导出成Markdown附在项目说明里。将来做数据恢复、换设备运行、再扩展功能时，你会为现在的整理动作庆幸。

如果你还有余力，可以从两个方向尝试扩展这个系统：一是把静态文档管理升级为协作空间概念，让用户拥有多个项目空间，空间内共享文档；二是接入第三方云存储对象存储服务，把文件上传后的存储策略改为云端，而本地只存元数据。这些扩展不会让你毕设翻车，反而会让论文的展望部分显得更有前瞻性。最后我还是想说一句：别把技术选型的价值放在“用什么框架”上，而要去复盘“为什么要在这个场景里这样选”。这套项目做完，你收获的不应该只是一份能查重的论文和一段能运行的代码，还应该是对信息架构、权限模型、文件处理这条主线的一次完整认知升级。

在实际操作过程里，最让我印象深刻的教训是：永远不要为了图省事把上传文件放在临时目录或者项目内相对路径下，宁可第一次就把存储目录抽象出来单独维护，也不要等到答辩前一天因为重启服务丢失文件而手忙脚乱。每个功能模块宁可慢一点写清楚，也不要贪图快而跳步，前面省的时间后面全都会在排查问题里加倍补回来。