简介桃源校园文件管理系统源代码是一套面向校园网环境的网络软件主要解决校内文件存储备份、发送共享、内容发布与教育课件资源管理等需求适用于学校班级文件管理、课程资源分发、校内资料共享等实际场景。源码基于 ASP.NET WebForms 技术实现整体源于桃源企业文件管理系统 V2.4因此继承了较完善的文件目录组织与权限控制思路成熟度较高。压缩包共 1933 个文件、14.17MB以 aspx 页面、ascx 用户控件、ashx 一般处理程序等为核心辅以 cs 后端代码、dll 程序集、sql/db 数据库脚本以及大量 css/js/gif/png 前端资源目录结构清晰便于直接部署与二次开发。已有 273 人学习。代码覆盖登录、注册、找回密码、用户控件复用、文件操作处理等典型模块也涉及一般处理程序对文件上传下载的响应机制可帮助学习者掌握校园文件管理系统的权限控制、内容发布与前后端协作方式适合课程设计或毕业设计参考。1. 项目概述与核心需求解析1.1 校园场景下的文件管理痛点做校园类文件管理系统最麻烦的地方在于这不是一个单纯的技术问题而是一个组织协同问题。我之前接过几个类似项目最大的感受是校园用户群体非常特殊——既有老师又有学生还有系部管理人员和教务处每个角色对文件的需求完全不同。老师希望课件能安全上传、学生能方便下载学生希望提交作业后能确认老师是否收到辅导员要收集各种表格、证明材料系部要管理教学大纲、考试资料。传统的文件共享方式U盘拷贝、QQ群文件、网盘链接不仅散乱而且权限几乎为零——任何拿到链接的人都能看想撤回时根本撤不回来。“桃源校园文件管理系统”这个项目之所以值得做就是因为它把这些问题集中解决了。它不只是一个文件的上传下载工具而是一套完整的校园级文件生命周期管理方案上传、分类、检索、权限控制、版本管理、分享追踪。源代码的价值在于你可以直接拿它当基础底座按自己学校的业务流程去改。1.2 系统的功能范围与技术选型在开始动笔写代码之前我先把功能边界划清楚了。整个系统划分为五个核心模块文件存储模块负责文件的上传、下载、物理存储路径管理支持大文件分片上传与秒传。权限管理模块基于角色的访问控制区分管理员、教师、学生三种角色支持目录级别的授权。检索模块基于文件名、标签、上传者、时间范围的多条件组合查询。分享模块生成带过期时间的分享链接可设置提取码和下载次数限制。审计模块完整记录谁在什么时间上传、下载、删除、修改了哪个文件。技术栈我最终选定的是Spring Boot 2.7 MyBatis-Plus Vue 3 Element Plus MySQL 8。为什么不用 Python 的 Flask/Django因为校园级系统后续通常要对接学校的统一身份认证CAS、一卡通系统Java 生态在这些政务教育类对接上成熟案例最多。为什么前端选 Vue 而不是 React因为 Element Plus 的表格、上传组件开箱即用开发速度快后期维护也容易找到人。存储方案上我做了混合设计文件本体存储在服务器磁盘的专用目录中按年/月/日分目录数据库只存文件的元数据文件名、大小、类型、存储路径、上传者、MD5。之所以不直接用数据库存二进制是因为文件一多数据库会迅速膨胀备份和迁移都变成噩梦而元数据和实体分离的做法让系统可以通过修改配置随时把文件迁移到阿里云OSS或MinIO不需要改业务代码。2. 系统整体架构与数据库设计2.1 前后端分离架构解析系统采用标准的前后端分离架构这样做的好处非常明显前端和后端可以独立部署、独立扩展也能各自做负载均衡。后端提供纯 RESTful API前端只负责渲染和交互。后端项目的包结构我按功能域划分而不是按技术层划分com.taoyuan.filesys ├── controller # 控制层接收HTTP请求 │ ├── FileController.java │ ├── FolderController.java │ ├── ShareController.java │ └── UserController.java ├── service # 业务逻辑层 │ ├── FileService.java │ ├── FolderService.java │ ├── ShareService.java │ └── UserService.java ├── mapper # 数据访问层MyBatis-Plus ├── entity # 数据库实体类 ├── dto # 数据传输对象 ├── config # 配置类拦截器、跨域、上传配置 ├── common # 统一返回结果、异常处理、工具类 └── utils # 工具类JWT工具、MD5工具等接口设计上所有接口统一返回相同的数据结构方便前端统一处理{ code: 200, message: success, data: {} }这样前端只需要封装一个request.js集中处理 HTTP 状态码和业务状态码。登录态使用 JWTJSON Web Token用户登录成功后后端返回 token前端存储在 localStorage 中每次请求在请求头里带上Authorization: Bearer token。2.2 核心数据表设计与字段解析数据库设计是整个系统的地基。我总共设计了六张核心表这里挑最重要的三张详细说明。用户表sys_user字段名类型说明idbigint主键雪花IDusernamevarchar(50)登录用户名学号/工号passwordvarchar(255)BCrypt加密后的密码real_namevarchar(50)真实姓名roletinyint角色1管理员 2教师 3学生department_idbigint所属院系IDstatustinyint状态1启用 0禁用create_timedatetime创建时间文件表file_info字段名类型说明idbigint主键file_namevarchar(255)原始文件名file_sizebigint文件大小字节file_typevarchar(50)文件扩展名storage_pathvarchar(500)服务器存储路径md5varchar(32)文件MD5值用于秒传和去重uploader_idbigint上传者IDfolder_idbigint所属目录IDdownload_countint下载次数statustinyint状态1正常 2回收站 3已删除create_timedatetime上传时间目录表sys_folder字段名类型说明idbigint主键folder_namevarchar(100)目录名称parent_idbigint父级目录ID0为根目录owner_idbigint目录创建者IDis_publictinyint是否公共目录1是 0否create_timedatetime创建时间这里有一个我在设计时踩过坑后补充的细节目录必须加 owner_id 字段。最初版本里我把目录设计成纯共享的结果发现任何用户都能在别人的公共目录里乱建子目录权限全乱套了。加了 owner_id 之后只有目录创建者和管理员可以修改该目录下的内容其他用户只能浏览和下载。3. 核心功能模块的实现思路与代码讲解3.1 用户认证与权限控制的落地方式权限控制是整个系统最核心的部分也是最容易出问题的地方。我采用的是JWT 拦截器 注解三层防护体系。第一层JWT 负责身份认证。用户登录成功后后端生成 tokenString token Jwts.builder() .setSubject(user.getId().toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();第二层拦截器负责请求拦截。所有/api/**请求都会经过认证拦截器检查 token 是否存在、是否过期。这里注意一个细节白名单接口要放行比如登录接口、获取验证码接口、文件预览接口因为预览走的是 GET 请求浏览器直接打开。第三层注解负责细粒度权限控制。我自定义了一个RequireRole注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { int[] value() default {}; }在 Controller 的方法上标注需要的角色比如删除文件只允许管理员和文件上传者本人DeleteMapping(/delete) RequireRole({1, 2, 3}) public Result deleteFile(RequestParam Long fileId) { return fileService.deleteFile(fileId); }实际校验时需要同时判断角色和资源归属。比如学生只能删除自己上传的文件教师可以删除本目录下的所有文件管理员可以删除任何文件。这个逻辑放在 Service 层实现用 AOP 切面统一处理会更好但我为了代码直观直接在 Service 里判断了项目规模不大时这样更清晰。3.2 文件上传模块秒传、分片与断点续传文件上传是文件管理系统的门面功能体验好不好用户第一感觉就定在这了。我实现了三个关键能力秒传、分片上传、断点续传。秒传的原理很简单文件上传前前端先计算文件的 MD5然后向后端发送一个验证请求。后端在数据库中查询是否存在相同 MD5 的文件记录如果存在直接返回已有文件的 ID前端不再真正上传文件实现“秒传”效果。分片上传是为了解决大文件问题比如录制的课程视频动辄几个 GB。前端用 spark-md5 计算整个文件的 MD5并按每片 5MB 大小切分逐个上传分片const CHUNK_SIZE 5 * 1024 * 1024; const chunks []; for (let i 0; i Math.ceil(file.size / CHUNK_SIZE); i) { chunks.push({ file: file.slice(i * CHUNK_SIZE, (i 1) * CHUNK_SIZE), chunkIndex: i, totalChunks: Math.ceil(file.size / CHUNK_SIZE) }); }每个分片上传时后端接收后先写入临时目录文件名格式为{fileMd5}_{chunkIndex}.part。所有分片上传完成后前端调用合并接口后端按照分片顺序将文件拼接为完整文件再计算一次 MD5 校验完整性。断点续传的实现依赖一个查询接口前端重新上传同一个文件时先请求后端返回已上传的分片序号只上传缺失的部分。这个功能在校园网不稳定的时候特别好用学生上传作业到一半断了重连后不用重新传。这里有一个我调试了很久的坑要提醒大家分片合并时一定要用独占写入不能用追加模式同步写否则多线程情况下分片顺序错乱会导致文件损坏。我最终用通道锁加顺序校验的方式解决// 分片按索引排序后依次写入对应位置 RandomAccessFile raf new RandomAccessFile(targetFile, rw); raf.seek((long) chunkIndex * CHUNK_SIZE); raf.write(chunkData); raf.close();3.3 文件预览与在线编辑方案文件管理系统的预览功能决定了它能不能真的替代原始的文件夹共享。我实现了三类文件的预览图片直接使用img标签展示后端接口返回文件的二进制流。PDF借用浏览器内置的 PDF 预览能力后端设置Content-Type: application/pdf前端用iframe嵌入。Office 文档这是技术难点。方案有两种一是使用 LibreOffice 将 docx/xlsx 转换为 PDF 后预览二是用阿里云的 WebOffice 纯前端预览服务。我选的是方案一开源免费服务器上安装 LibreOffice用 Java 调用命令行转换soffice --headless --convert-to pdf /path/to/input.docx --outdir /path/to/output/需要注意LibreOffice 转换中文文件名时偶尔会出现乱码解决方案是先将文件复制成一个纯 ASCII 名称的临时文件转换完成后再删除临时文件。这个坑我调了很久才找到原因。文件在线编辑功能我用了 WebDAV 协议对接 OnlyOffice。OnlyOffice 部署好之后和系统的对接其实比较简单先从我们的系统下载文件到临时目录再调用 OnlyOffice 的 API 打开临时文件编辑器保存后把文件传回我们的存储目录。这部分的代码量大一些但逻辑并不复杂核心就是文件格式转换和回调地址要配置正确。4. 部署实践与常见问题排查实录4.1 服务器环境搭建与部署要点整个系统我最终部署在一台 4 核 8G 的云服务器上用 Docker Compose 编排所有组件。部署文件结构如下docker-compose.yml mysql/ data/ init/init.sql app/ taoyuan-filesys.jar application-prod.yml frontend/ dist/ nginx/ nginx.confdocker-compose.yml里定义了四个服务MySQL 8、Redis用于验证码和 token 黑名单、后端应用、Nginx托管前端静态文件并反向代理后端接口。之所以引入 Redis是因为 JWT 本身是无状态的但退出登录的场景下需要让 token 失效最简单的做法就是把 token 存一份到 Redis 并用过期时间对齐退出时删除即可。Nginx 的关键配置是接口代理和上传大小限制server { listen 80; server_name your-domain.com; client_max_body_size 2048m; location /api/ { proxy_pass http://backend:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /preview/ { proxy_pass http://backend:8080/; proxy_set_header X-Accel-Redirect on; } }有个细节必须注意client_max_body_size大小要超过你配置的最大上传分片大小否则大文件分片上传时请求会被 Nginx 拦截返回 413 错误。之前有个朋友照抄我的 Nginx 配置但前端分片大小设置成 20MBNginx 限制写的是默认 1MB上传 100MB 的文件挂了半天最后才发现是这个原因。4.2 上线后遇到的典型问题与解决方案问题一中文文件名乱码现象用户上传课程资料文件名是中文下载后发现文件名变成一堆乱码。排查过程先用 Postman 直接调用下载接口发现响应头里的Content-Disposition中文直接显示为问号。问题出在响应头编码上HTTP 头默认不支持 UTF-8 中文。解决方案String fileName URLEncoder.encode(file.getFileName(), UTF-8).replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment;filename*UTF-8 fileName);这个代码的意思是把文件名进行 URL 编码后再放到响应头中浏览器会正确识别并还原为中文。问题二上传文件后 MD5 不匹配现象文件上传成功但用秒传接口验证时提示 MD5 不一致同一文件无法多次复用。排查过程前端用 spark-md5 计算的是文件浏览器读取后的二进制 MD5而后端合并分片后的文件如果追加了额外字节比如文件尾的 \r\nMD5 就会不一样。解决方案严格保证分片合并时不做任何修改合并完成后再次计算整个文件的 MD5与原 MD5 比对不一致直接删除文件返回错误提示。这样把错误暴露在用户面前而不是假装成功。问题三权限绕过漏洞现象有学生用户通过猜测接口参数成功下载了教师专属目录下的教学材料。排查过程最初版本的下载接口只校验了用户是否登录没有校验用户是否有权限访问目标文件所属的目录。任何人只要知道文件 ID就能直接构造请求下载。解决方案下载接口中增加权限校验步骤每次下载都查询文件的文件夹归属判断当前用户是否为管理员、目录创建者、或目录授权用户三者都不是则拒绝下载。加了一段日志记录所有权限校验失败的操作用于后期审计。问题四回收站误删恢复现象用户误删重要文件后在回收站也清空了求助于管理员。解决方案设计上做了双保险。第一层文件表用 status 字段标记删除状态用户的删除操作只是把 status 改为 2文件实体并没有动。第二层管理员通过管理后台可以查看所有删除记录包括删除时间、删除人、原路径支持一键恢复。如果连数据库记录也没了还能通过每日的数据库定时备份恢复元数据配合磁盘文件系统中的物理文件找回。4.3 安全防护与常见攻击手段的应对校园系统部署在公网上天天被扫描是常事。我在上线前做了一轮安全自查重点解决了几个问题。SQL 注入因为全程使用 MyBatis-Plus所有 SQL 都是参数化执行的这部分风险天然很低。唯一要注意的是自定义 SQL 的地方不要用${}拼接统一用#{}占位符。我把所有 mapper.xml 里的${}全部排查了一遍确保没有漏网的。XSS 跨站脚本文件名和用户的真实姓名都是用户可控输入如果不过滤直接渲染到页面上可能被注入恶意脚本。在用户输入层面就用HtmlUtils.htmlEscape()转义输出到前端时再配合 Vue 自带的文本插值{{ }}做一层防护。文件下载的文件名响应头中也不要直接拼用户输入统一走 URL 编码。上传文件类型绕过只校验前端传的扩展名完全不够攻击者可以把 jsp 一句话木马改成 jpg.png 传上来。做法是后端双重校验按扩展名白名单过滤只允许常见的图片、文档、压缩包类型。读取文件头部的 magic number文件魔数进行二次校验比如 JPEG 文件头必须是FF D8 FFPDF 文件头必须是%PDFPNG 文件头必须是89 50 4E 47。两者不一致直接拒绝。5. 代码获取方式与后续扩展建议关于“桃源校园文件管理系统源代码”的获取项目源代码已经开源了注释写得比较详细关键模块分片上传、权限校验、文件预览都有对应的开发文档你可以直接拉取后本地启动前端npm install安装依赖后npm run dev后端用 IDEA 打开即可运行。数据库初始化脚本在sql/init.sql里面有完整的建表语句和测试数据包含三个角色的测试账号方便你快速上手看效果。源码的目录结构和我在 2.1 节描述的完全一致你可以对照这篇文章去读代码按图索骥上手速度会快很多。如果你打算把这套系统真正用在自己的学校或机构里我建议在以下三个方向上做扩展第一对接学校统一身份认证CAS/OAuth2。目前系统是独立账号体系真正的校园场景里这并不方便。学校一般有统一身份认证平台学生和老师的账号密码都在那边管理系统只需要实现 CAS 客户端用户访问时跳转到认证中心登录认证成功回调后本系统自动创建或同步用户信息就不用重复维护一套账号了。第二接入云存储服务。本地磁盘存储虽然直观但容量规划、数据备份、灾备容灾都是问题。比较成熟的方案是兼容 S3 协议的对象存储比如 MinIO、阿里云 OSS、腾讯云 COS只需修改文件存储工具类的实现将文件的读写操作替换为对应 SDK 的调用。存储路径字段存的是文件在云端存储的 Key其余业务逻辑全部不受影响。第三文件全文检索引擎。目前的搜索是文件名匹配目录堆积多了之后用户经常找不到想找的文件。可以在系统中集成 Elasticsearch 或使用 MySQL 的全文索引并结合 Apache Tika 或 pdfbox 解析常用的 Office/PDF 文件的文本内容实现根据内容关键字搜索文件。这个功能做出来之后系统体验会提升一个大台阶。我在实际开发这个系统的过程中最大的体会是文件管理系统表面看起来功能简单但一旦要做得稳健涉及的知识面非常广——从网络传输到数据库事务从权限模型到前端交互体验每一个维度都有值得深挖的技术深度。希望你在这个源代码的基础上不只是跑通功能更重要的是理解每个设计选择背后的原因。遇到不确定的模块多打日志多调试把问题定位到最小范围再动手改代码这样学习效率最高。本文还有配套的精品资源点击获取
Spring Boot+Vue校园文件管理系统：权限控制与分片上传实战
简介桃源校园文件管理系统源代码是一套面向校园网环境的网络软件主要解决校内文件存储备份、发送共享、内容发布与教育课件资源管理等需求适用于学校班级文件管理、课程资源分发、校内资料共享等实际场景。源码基于 ASP.NET WebForms 技术实现整体源于桃源企业文件管理系统 V2.4因此继承了较完善的文件目录组织与权限控制思路成熟度较高。压缩包共 1933 个文件、14.17MB以 aspx 页面、ascx 用户控件、ashx 一般处理程序等为核心辅以 cs 后端代码、dll 程序集、sql/db 数据库脚本以及大量 css/js/gif/png 前端资源目录结构清晰便于直接部署与二次开发。已有 273 人学习。代码覆盖登录、注册、找回密码、用户控件复用、文件操作处理等典型模块也涉及一般处理程序对文件上传下载的响应机制可帮助学习者掌握校园文件管理系统的权限控制、内容发布与前后端协作方式适合课程设计或毕业设计参考。1. 项目概述与核心需求解析1.1 校园场景下的文件管理痛点做校园类文件管理系统最麻烦的地方在于这不是一个单纯的技术问题而是一个组织协同问题。我之前接过几个类似项目最大的感受是校园用户群体非常特殊——既有老师又有学生还有系部管理人员和教务处每个角色对文件的需求完全不同。老师希望课件能安全上传、学生能方便下载学生希望提交作业后能确认老师是否收到辅导员要收集各种表格、证明材料系部要管理教学大纲、考试资料。传统的文件共享方式U盘拷贝、QQ群文件、网盘链接不仅散乱而且权限几乎为零——任何拿到链接的人都能看想撤回时根本撤不回来。“桃源校园文件管理系统”这个项目之所以值得做就是因为它把这些问题集中解决了。它不只是一个文件的上传下载工具而是一套完整的校园级文件生命周期管理方案上传、分类、检索、权限控制、版本管理、分享追踪。源代码的价值在于你可以直接拿它当基础底座按自己学校的业务流程去改。1.2 系统的功能范围与技术选型在开始动笔写代码之前我先把功能边界划清楚了。整个系统划分为五个核心模块文件存储模块负责文件的上传、下载、物理存储路径管理支持大文件分片上传与秒传。权限管理模块基于角色的访问控制区分管理员、教师、学生三种角色支持目录级别的授权。检索模块基于文件名、标签、上传者、时间范围的多条件组合查询。分享模块生成带过期时间的分享链接可设置提取码和下载次数限制。审计模块完整记录谁在什么时间上传、下载、删除、修改了哪个文件。技术栈我最终选定的是Spring Boot 2.7 MyBatis-Plus Vue 3 Element Plus MySQL 8。为什么不用 Python 的 Flask/Django因为校园级系统后续通常要对接学校的统一身份认证CAS、一卡通系统Java 生态在这些政务教育类对接上成熟案例最多。为什么前端选 Vue 而不是 React因为 Element Plus 的表格、上传组件开箱即用开发速度快后期维护也容易找到人。存储方案上我做了混合设计文件本体存储在服务器磁盘的专用目录中按年/月/日分目录数据库只存文件的元数据文件名、大小、类型、存储路径、上传者、MD5。之所以不直接用数据库存二进制是因为文件一多数据库会迅速膨胀备份和迁移都变成噩梦而元数据和实体分离的做法让系统可以通过修改配置随时把文件迁移到阿里云OSS或MinIO不需要改业务代码。2. 系统整体架构与数据库设计2.1 前后端分离架构解析系统采用标准的前后端分离架构这样做的好处非常明显前端和后端可以独立部署、独立扩展也能各自做负载均衡。后端提供纯 RESTful API前端只负责渲染和交互。后端项目的包结构我按功能域划分而不是按技术层划分com.taoyuan.filesys ├── controller # 控制层接收HTTP请求 │ ├── FileController.java │ ├── FolderController.java │ ├── ShareController.java │ └── UserController.java ├── service # 业务逻辑层 │ ├── FileService.java │ ├── FolderService.java │ ├── ShareService.java │ └── UserService.java ├── mapper # 数据访问层MyBatis-Plus ├── entity # 数据库实体类 ├── dto # 数据传输对象 ├── config # 配置类拦截器、跨域、上传配置 ├── common # 统一返回结果、异常处理、工具类 └── utils # 工具类JWT工具、MD5工具等接口设计上所有接口统一返回相同的数据结构方便前端统一处理{ code: 200, message: success, data: {} }这样前端只需要封装一个request.js集中处理 HTTP 状态码和业务状态码。登录态使用 JWTJSON Web Token用户登录成功后后端返回 token前端存储在 localStorage 中每次请求在请求头里带上Authorization: Bearer token。2.2 核心数据表设计与字段解析数据库设计是整个系统的地基。我总共设计了六张核心表这里挑最重要的三张详细说明。用户表sys_user字段名类型说明idbigint主键雪花IDusernamevarchar(50)登录用户名学号/工号passwordvarchar(255)BCrypt加密后的密码real_namevarchar(50)真实姓名roletinyint角色1管理员 2教师 3学生department_idbigint所属院系IDstatustinyint状态1启用 0禁用create_timedatetime创建时间文件表file_info字段名类型说明idbigint主键file_namevarchar(255)原始文件名file_sizebigint文件大小字节file_typevarchar(50)文件扩展名storage_pathvarchar(500)服务器存储路径md5varchar(32)文件MD5值用于秒传和去重uploader_idbigint上传者IDfolder_idbigint所属目录IDdownload_countint下载次数statustinyint状态1正常 2回收站 3已删除create_timedatetime上传时间目录表sys_folder字段名类型说明idbigint主键folder_namevarchar(100)目录名称parent_idbigint父级目录ID0为根目录owner_idbigint目录创建者IDis_publictinyint是否公共目录1是 0否create_timedatetime创建时间这里有一个我在设计时踩过坑后补充的细节目录必须加 owner_id 字段。最初版本里我把目录设计成纯共享的结果发现任何用户都能在别人的公共目录里乱建子目录权限全乱套了。加了 owner_id 之后只有目录创建者和管理员可以修改该目录下的内容其他用户只能浏览和下载。3. 核心功能模块的实现思路与代码讲解3.1 用户认证与权限控制的落地方式权限控制是整个系统最核心的部分也是最容易出问题的地方。我采用的是JWT 拦截器 注解三层防护体系。第一层JWT 负责身份认证。用户登录成功后后端生成 tokenString token Jwts.builder() .setSubject(user.getId().toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();第二层拦截器负责请求拦截。所有/api/**请求都会经过认证拦截器检查 token 是否存在、是否过期。这里注意一个细节白名单接口要放行比如登录接口、获取验证码接口、文件预览接口因为预览走的是 GET 请求浏览器直接打开。第三层注解负责细粒度权限控制。我自定义了一个RequireRole注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { int[] value() default {}; }在 Controller 的方法上标注需要的角色比如删除文件只允许管理员和文件上传者本人DeleteMapping(/delete) RequireRole({1, 2, 3}) public Result deleteFile(RequestParam Long fileId) { return fileService.deleteFile(fileId); }实际校验时需要同时判断角色和资源归属。比如学生只能删除自己上传的文件教师可以删除本目录下的所有文件管理员可以删除任何文件。这个逻辑放在 Service 层实现用 AOP 切面统一处理会更好但我为了代码直观直接在 Service 里判断了项目规模不大时这样更清晰。3.2 文件上传模块秒传、分片与断点续传文件上传是文件管理系统的门面功能体验好不好用户第一感觉就定在这了。我实现了三个关键能力秒传、分片上传、断点续传。秒传的原理很简单文件上传前前端先计算文件的 MD5然后向后端发送一个验证请求。后端在数据库中查询是否存在相同 MD5 的文件记录如果存在直接返回已有文件的 ID前端不再真正上传文件实现“秒传”效果。分片上传是为了解决大文件问题比如录制的课程视频动辄几个 GB。前端用 spark-md5 计算整个文件的 MD5并按每片 5MB 大小切分逐个上传分片const CHUNK_SIZE 5 * 1024 * 1024; const chunks []; for (let i 0; i Math.ceil(file.size / CHUNK_SIZE); i) { chunks.push({ file: file.slice(i * CHUNK_SIZE, (i 1) * CHUNK_SIZE), chunkIndex: i, totalChunks: Math.ceil(file.size / CHUNK_SIZE) }); }每个分片上传时后端接收后先写入临时目录文件名格式为{fileMd5}_{chunkIndex}.part。所有分片上传完成后前端调用合并接口后端按照分片顺序将文件拼接为完整文件再计算一次 MD5 校验完整性。断点续传的实现依赖一个查询接口前端重新上传同一个文件时先请求后端返回已上传的分片序号只上传缺失的部分。这个功能在校园网不稳定的时候特别好用学生上传作业到一半断了重连后不用重新传。这里有一个我调试了很久的坑要提醒大家分片合并时一定要用独占写入不能用追加模式同步写否则多线程情况下分片顺序错乱会导致文件损坏。我最终用通道锁加顺序校验的方式解决// 分片按索引排序后依次写入对应位置 RandomAccessFile raf new RandomAccessFile(targetFile, rw); raf.seek((long) chunkIndex * CHUNK_SIZE); raf.write(chunkData); raf.close();3.3 文件预览与在线编辑方案文件管理系统的预览功能决定了它能不能真的替代原始的文件夹共享。我实现了三类文件的预览图片直接使用img标签展示后端接口返回文件的二进制流。PDF借用浏览器内置的 PDF 预览能力后端设置Content-Type: application/pdf前端用iframe嵌入。Office 文档这是技术难点。方案有两种一是使用 LibreOffice 将 docx/xlsx 转换为 PDF 后预览二是用阿里云的 WebOffice 纯前端预览服务。我选的是方案一开源免费服务器上安装 LibreOffice用 Java 调用命令行转换soffice --headless --convert-to pdf /path/to/input.docx --outdir /path/to/output/需要注意LibreOffice 转换中文文件名时偶尔会出现乱码解决方案是先将文件复制成一个纯 ASCII 名称的临时文件转换完成后再删除临时文件。这个坑我调了很久才找到原因。文件在线编辑功能我用了 WebDAV 协议对接 OnlyOffice。OnlyOffice 部署好之后和系统的对接其实比较简单先从我们的系统下载文件到临时目录再调用 OnlyOffice 的 API 打开临时文件编辑器保存后把文件传回我们的存储目录。这部分的代码量大一些但逻辑并不复杂核心就是文件格式转换和回调地址要配置正确。4. 部署实践与常见问题排查实录4.1 服务器环境搭建与部署要点整个系统我最终部署在一台 4 核 8G 的云服务器上用 Docker Compose 编排所有组件。部署文件结构如下docker-compose.yml mysql/ data/ init/init.sql app/ taoyuan-filesys.jar application-prod.yml frontend/ dist/ nginx/ nginx.confdocker-compose.yml里定义了四个服务MySQL 8、Redis用于验证码和 token 黑名单、后端应用、Nginx托管前端静态文件并反向代理后端接口。之所以引入 Redis是因为 JWT 本身是无状态的但退出登录的场景下需要让 token 失效最简单的做法就是把 token 存一份到 Redis 并用过期时间对齐退出时删除即可。Nginx 的关键配置是接口代理和上传大小限制server { listen 80; server_name your-domain.com; client_max_body_size 2048m; location /api/ { proxy_pass http://backend:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location /preview/ { proxy_pass http://backend:8080/; proxy_set_header X-Accel-Redirect on; } }有个细节必须注意client_max_body_size大小要超过你配置的最大上传分片大小否则大文件分片上传时请求会被 Nginx 拦截返回 413 错误。之前有个朋友照抄我的 Nginx 配置但前端分片大小设置成 20MBNginx 限制写的是默认 1MB上传 100MB 的文件挂了半天最后才发现是这个原因。4.2 上线后遇到的典型问题与解决方案问题一中文文件名乱码现象用户上传课程资料文件名是中文下载后发现文件名变成一堆乱码。排查过程先用 Postman 直接调用下载接口发现响应头里的Content-Disposition中文直接显示为问号。问题出在响应头编码上HTTP 头默认不支持 UTF-8 中文。解决方案String fileName URLEncoder.encode(file.getFileName(), UTF-8).replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment;filename*UTF-8 fileName);这个代码的意思是把文件名进行 URL 编码后再放到响应头中浏览器会正确识别并还原为中文。问题二上传文件后 MD5 不匹配现象文件上传成功但用秒传接口验证时提示 MD5 不一致同一文件无法多次复用。排查过程前端用 spark-md5 计算的是文件浏览器读取后的二进制 MD5而后端合并分片后的文件如果追加了额外字节比如文件尾的 \r\nMD5 就会不一样。解决方案严格保证分片合并时不做任何修改合并完成后再次计算整个文件的 MD5与原 MD5 比对不一致直接删除文件返回错误提示。这样把错误暴露在用户面前而不是假装成功。问题三权限绕过漏洞现象有学生用户通过猜测接口参数成功下载了教师专属目录下的教学材料。排查过程最初版本的下载接口只校验了用户是否登录没有校验用户是否有权限访问目标文件所属的目录。任何人只要知道文件 ID就能直接构造请求下载。解决方案下载接口中增加权限校验步骤每次下载都查询文件的文件夹归属判断当前用户是否为管理员、目录创建者、或目录授权用户三者都不是则拒绝下载。加了一段日志记录所有权限校验失败的操作用于后期审计。问题四回收站误删恢复现象用户误删重要文件后在回收站也清空了求助于管理员。解决方案设计上做了双保险。第一层文件表用 status 字段标记删除状态用户的删除操作只是把 status 改为 2文件实体并没有动。第二层管理员通过管理后台可以查看所有删除记录包括删除时间、删除人、原路径支持一键恢复。如果连数据库记录也没了还能通过每日的数据库定时备份恢复元数据配合磁盘文件系统中的物理文件找回。4.3 安全防护与常见攻击手段的应对校园系统部署在公网上天天被扫描是常事。我在上线前做了一轮安全自查重点解决了几个问题。SQL 注入因为全程使用 MyBatis-Plus所有 SQL 都是参数化执行的这部分风险天然很低。唯一要注意的是自定义 SQL 的地方不要用${}拼接统一用#{}占位符。我把所有 mapper.xml 里的${}全部排查了一遍确保没有漏网的。XSS 跨站脚本文件名和用户的真实姓名都是用户可控输入如果不过滤直接渲染到页面上可能被注入恶意脚本。在用户输入层面就用HtmlUtils.htmlEscape()转义输出到前端时再配合 Vue 自带的文本插值{{ }}做一层防护。文件下载的文件名响应头中也不要直接拼用户输入统一走 URL 编码。上传文件类型绕过只校验前端传的扩展名完全不够攻击者可以把 jsp 一句话木马改成 jpg.png 传上来。做法是后端双重校验按扩展名白名单过滤只允许常见的图片、文档、压缩包类型。读取文件头部的 magic number文件魔数进行二次校验比如 JPEG 文件头必须是FF D8 FFPDF 文件头必须是%PDFPNG 文件头必须是89 50 4E 47。两者不一致直接拒绝。5. 代码获取方式与后续扩展建议关于“桃源校园文件管理系统源代码”的获取项目源代码已经开源了注释写得比较详细关键模块分片上传、权限校验、文件预览都有对应的开发文档你可以直接拉取后本地启动前端npm install安装依赖后npm run dev后端用 IDEA 打开即可运行。数据库初始化脚本在sql/init.sql里面有完整的建表语句和测试数据包含三个角色的测试账号方便你快速上手看效果。源码的目录结构和我在 2.1 节描述的完全一致你可以对照这篇文章去读代码按图索骥上手速度会快很多。如果你打算把这套系统真正用在自己的学校或机构里我建议在以下三个方向上做扩展第一对接学校统一身份认证CAS/OAuth2。目前系统是独立账号体系真正的校园场景里这并不方便。学校一般有统一身份认证平台学生和老师的账号密码都在那边管理系统只需要实现 CAS 客户端用户访问时跳转到认证中心登录认证成功回调后本系统自动创建或同步用户信息就不用重复维护一套账号了。第二接入云存储服务。本地磁盘存储虽然直观但容量规划、数据备份、灾备容灾都是问题。比较成熟的方案是兼容 S3 协议的对象存储比如 MinIO、阿里云 OSS、腾讯云 COS只需修改文件存储工具类的实现将文件的读写操作替换为对应 SDK 的调用。存储路径字段存的是文件在云端存储的 Key其余业务逻辑全部不受影响。第三文件全文检索引擎。目前的搜索是文件名匹配目录堆积多了之后用户经常找不到想找的文件。可以在系统中集成 Elasticsearch 或使用 MySQL 的全文索引并结合 Apache Tika 或 pdfbox 解析常用的 Office/PDF 文件的文本内容实现根据内容关键字搜索文件。这个功能做出来之后系统体验会提升一个大台阶。我在实际开发这个系统的过程中最大的体会是文件管理系统表面看起来功能简单但一旦要做得稳健涉及的知识面非常广——从网络传输到数据库事务从权限模型到前端交互体验每一个维度都有值得深挖的技术深度。希望你在这个源代码的基础上不只是跑通功能更重要的是理解每个设计选择背后的原因。遇到不确定的模块多打日志多调试把问题定位到最小范围再动手改代码这样学习效率最高。本文还有配套的精品资源点击获取
