企业官网建设流程全解析

简介：这是一套面向高校计算机专业学生与Java初学者、用于课程设计或毕业设计的教学资源管理系统源码，基于Java语言与Spring Boot框架实现，采用MVC架构，整合Spring Security权限控制、JPA数据持久化与MySQL数据库，前端使用Vue.js构建响应式界面。系统涵盖用户管理、资源管理、权限管理、课程管理及在线互动等模块，教师可上传课件、视频、文档并跟踪学习进度，学生可在线选课、参与讨论与提交作业，适合作为教育信息化项目的完整参考实现。压缩包共1368个文件，约9.96MB，以537个js、195个less、178个css、163个png及84个html等前端资源为主，另含21个jsp、19个java源码、1个sql脚本与若干配置文件，目录结构清晰，便于按模块阅读与二次开发。目前已有46人学习下载，可帮助读者快速理解系统分层设计、权限校验与前后端交互流程，并在此基础上完成功能扩展与部署调试。

1. 教学资源管理系统：为什么 Java 技术栈依然是高校场景的稳妥选择

做过教学资源管理系统的人都有一个共识：这类项目的难点从来不在“能不能上传文件”，而在“资源怎么分类、权限怎么控、并发下载怎么扛、历史版本怎么留”。一个基于 Java 实现的教学资源管理系统，本质上是把课件、视频、题库、实验指导书这些异构资源，用统一的元数据模型管起来，再叠加角色权限和检索能力。它适合两类人：一类是课程设计或毕设阶段需要完整落地一套系统的学生开发者，另一类是要给内部培训、企业大学搭轻量资源库的工程师。选 Java 不是因为时髦，而是 Spring Boot 的生态能把文件存储、权限校验、分页检索这些脏活压到很低的代码量，后期加 Redis 缓存或对象存储也不用推倒重来。下面按“先立模型、再跑通上传下载、最后处理权限和性能”的顺序讲透。

2. 资源模型与数据库设计：先把元数据表定死再写代码

2.1 为什么资源表不能只存一个文件路径

新手最容易翻车的地方，是设计一张resource表只放id、name、url三个字段，结果做到一半发现要按课程筛选、要记录上传者、要区分资源类型、要支持多版本，只能不停ALTER TABLE。教学资源的本质是“文件 + 业务属性”，业务属性包括所属课程、资源类型（课件/视频/题库/文档）、可见范围（公开/班级/私有）、上传时间、文件大小、MIME 类型、下载次数。这些字段决定了后面检索和权限能不能做干净。

我一般会把模型拆成三张核心表：资源主表、资源分类表、资源版本表。分类表用树形结构（parent_id）支持“课程 → 章节 → 知识点”的多级归类；版本表记录同一逻辑资源的多次上传，主表只保留当前生效版本的外键。这样学生重复上传同一份课件时，不会产生一堆孤立记录，而是形成可追溯的版本链。

2.2 建表 SQL 与字段取舍

-- 资源分类表：树形结构，支持课程/章节/知识点多级 CREATE TABLE resource_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, parent_id BIGINT DEFAULT 0 COMMENT '父分类，0为根', name VARCHAR(64) NOT NULL, sort_order INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 资源主表：只保留当前生效版本 CREATE TABLE resource ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, category_id BIGINT NOT NULL COMMENT '所属分类', res_type TINYINT NOT NULL COMMENT '1课件 2视频 3题库 4文档', visibility TINYINT DEFAULT 0 COMMENT '0公开 1班级 2私有', owner_id BIGINT NOT NULL COMMENT '上传者', current_ver BIGINT COMMENT '当前版本ID', download_cnt INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_category (category_id), INDEX idx_owner (owner_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 版本表：同一资源的多次上传记录 CREATE TABLE resource_version ( id BIGINT PRIMARY KEY AUTO_INCREMENT, resource_id BIGINT NOT NULL, file_path VARCHAR(255) NOT NULL COMMENT '存储相对路径', file_size BIGINT NOT NULL, mime_type VARCHAR(64), upload_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_resource (resource_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

字段取舍上有几个点值得说清楚。visibility用 TINYINT 而不是字符串，是为了后面权限查询能直接走索引比较；file_path存相对路径而不是绝对路径，换服务器或迁移存储目录时不用改数据；download_cnt放在主表而不是版本表，因为统计口径通常是“这个资源被下载了多少次”，不区分版本。res_type和visibility的枚举值建议在代码里用常量类维护，别散落在各处魔法数字。

提示：分类表的parent_id默认 0 表示根节点，查询某分类下全部资源时要递归子分类，MySQL 8 可以用 CTE，低版本就在应用层做一次树遍历缓存。

2.3 实体类与 MyBatis-Plus 映射

@Data @TableName("resource") public class Resource { @TableId(type = IdType.AUTO) private Long id; private String title; private Long categoryId; private Integer resType; private Integer visibility; private Long ownerId; private Long currentVer; private Integer downloadCnt; private LocalDateTime createTime; }

用 MyBatis-Plus 的好处是单表 CRUD 不用写 XML，分页插件直接接Page对象。注意currentVer在插入资源时先留空，等第一个版本记录写入后再回填，避免外键指向不存在的版本。如果团队习惯 JPA，把@TableName换成@Entity、@TableId换成@Id即可，逻辑一致。

3. 文件上传与下载：从本地磁盘到分片续传的落地路径

3.1 最小可用上传接口怎么写

先跑通单文件上传，再谈分片。Spring Boot 里用MultipartFile接收，核心是校验、落盘、写版本记录三步。落盘路径按日期分目录，避免单目录文件过多导致ls卡顿。

@PostMapping("/upload") public Result<Long> upload(@RequestParam("file") MultipartFile file, @RequestParam Long categoryId, @RequestParam Integer resType) throws IOException { // 1. 基础校验：空文件、大小上限、扩展名白名单 if (file.isEmpty()) return Result.fail("文件为空"); if (file.getSize() > 200 * 1024 * 1024) return Result.fail("超过200MB"); String ext = StringUtils.getFilenameExtension(file.getOriginalFilename()); if (!ALLOW_EXT.contains(ext.toLowerCase())) return Result.fail("类型不允许"); // 2. 按日期分目录落盘，文件名用UUID防冲突 String dateDir = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyy/MM/dd")); String relative = dateDir + "/" + UUID.randomUUID() + "." + ext; Path target = Paths.get(STORAGE_ROOT, relative); Files.createDirectories(target.getParent()); file.transferTo(target.toFile()); // 3. 写资源主表 + 版本表，回填currentVer Resource res = new Resource(); res.setTitle(file.getOriginalFilename()); res.setCategoryId(categoryId); res.setResType(resType); res.setOwnerId(CurrentUser.getId()); resourceMapper.insert(res); ResourceVersion ver = new ResourceVersion(); ver.setResourceId(res.getId()); ver.setFilePath(relative); ver.setFileSize(file.getSize()); ver.setMimeType(file.getContentType()); versionMapper.insert(ver); res.setCurrentVer(ver.getId()); resourceMapper.updateById(res); return Result.ok(res.getId()); }

逻辑说明：先校验再落盘，避免非法文件占用磁盘；UUID 文件名防止同名覆盖，原始文件名存在title里供展示；先插主表拿到自增 ID，再插版本表，最后回填currentVer，三步在一个事务里更稳妥。参数上STORAGE_ROOT建议配在application.yml里，别硬编码；ALLOW_EXT用Set<String>存白名单，比每次拼字符串判断快。

3.2 大文件分片上传与断点续传

视频类资源动辄几百 MB，单请求上传容易超时。常见做法是前端把文件切成 5MB 分片，每片带fileMd5、chunkIndex、totalChunks三个参数。后端用一张临时表记录已上传分片，全部到齐后合并。

@PostMapping("/chunk") public Result<Void> uploadChunk(@RequestParam String fileMd5, @RequestParam int chunkIndex, @RequestParam MultipartFile chunk) throws IOException { // 分片存到临时目录：tmp/{fileMd5}/{chunkIndex} Path dir = Paths.get(TMP_ROOT, fileMd5); Files.createDirectories(dir); chunk.transferTo(dir.resolve(String.valueOf(chunkIndex)).toFile()); // 记录到Redis Set，key为 chunk:{fileMd5} redisTemplate.opsForSet().add("chunk:" + fileMd5, String.valueOf(chunkIndex)); return Result.ok(); } @PostMapping("/merge") public Result<Long> merge(@RequestParam String fileMd5, @RequestParam int totalChunks, @RequestParam String fileName) throws IOException { Set<String> uploaded = redisTemplate.opsForSet().members("chunk:" + fileMd5); if (uploaded == null || uploaded.size() < totalChunks) { return Result.fail("分片不完整"); } // 按序合并 Path merged = Paths.get(STORAGE_ROOT, fileMd5 + "_" + fileName); try (OutputStream out = Files.newOutputStream(merged)) { for (int i = 0; i < totalChunks; i++) { Files.copy(Paths.get(TMP_ROOT, fileMd5, String.valueOf(i)), out); } } // 清理临时分片 FileUtils.deleteDirectory(Paths.get(TMP_ROOT, fileMd5).toFile()); redisTemplate.delete("chunk:" + fileMd5); return Result.ok(saveResource(merged, fileName)); }

参数说明：fileMd5由前端对文件内容计算，作为分片会话的唯一标识，也天然支持秒传（合并前先查这个 MD5 是否已有资源）；chunkIndex从 0 开始；totalChunks用于合并时校验完整性。Redis 的 Set 结构天然去重，重复上传同一分片不会出错。合并时按索引顺序Files.copy，注意用OutputStream追加而不是每次新建文件。

注意：分片临时目录要定期清理，否则用户传一半放弃的文件会一直占空间。我一般加一个定时任务，扫描TMP_ROOT下超过 24 小时未合并的目录直接删除。

3.3 下载接口与防盗链

下载不能直接把存储路径暴露出去。正确做法是走一个受控接口，校验权限后返回Resource流，并设置Content-Disposition。

@GetMapping("/download/{versionId}") public void download(@PathVariable Long versionId, HttpServletResponse resp) throws IOException { ResourceVersion ver = versionMapper.selectById(versionId); Resource res = resourceMapper.selectById(ver.getResourceId()); // 权限校验：私有资源只有owner可下，班级资源校验班级关系 if (!permissionService.canDownload(CurrentUser.getId(), res)) { resp.setStatus(403); return; } Path file = Paths.get(STORAGE_ROOT, ver.getFilePath()); resp.setContentType(ver.getMimeType()); resp.setHeader("Content-Disposition", "attachment; filename=" + URLEncoder.encode(res.getTitle(), "UTF-8")); Files.copy(file, resp.getOutputStream()); // 下载计数+1，用Redis累加后定时回写，避免每次update行锁 redisTemplate.opsForValue().increment("dl:" + res.getId()); }

这里下载计数用 Redis 累加、定时回写数据库，是因为高频下载时每请求一次UPDATE会引发行锁竞争。Content-Disposition里的文件名要 URL 编码，否则中文名会乱码。权限校验放在流输出之前，一旦开始写响应体就没法再改状态码了。

4. 权限与检索：RBAC 模型和分页查询的工程细节

4.1 角色权限怎么设计才不臃肿

教学场景的角色通常就三类：管理员、教师、学生。管理员管分类和全量资源，教师管自己上传的资源，学生只能看公开和本班资源。用经典 RBAC 五张表（用户、角色、权限、用户角色、角色权限）对这个小系统偏重，我一般简化成用户表带role字段，权限判断写成策略方法。

public boolean canDownload(Long userId, Resource res) { User user = userMapper.selectById(userId); if (user.getRole() == Role.ADMIN) return true; if (res.getOwnerId().equals(userId)) return true; if (res.getVisibility() == 0) return true; // 公开 if (res.getVisibility() == 1) { // 班级可见 return classService.isSameClass(userId, res.getOwnerId()); } return false; // 私有 }

这种写法的好处是规则集中在一个方法里，改权限逻辑只动一处。缺点是角色多了会膨胀，所以角色超过 5 种就该换回标准 RBAC。判断顺序按“管理员 → 所有者 → 公开 → 班级 → 私有”从宽到严，短路返回，性能也好。

4.2 分页检索与多条件组合查询

资源列表页通常要支持按分类、类型、关键字、上传者组合筛选。用 MyBatis-Plus 的LambdaQueryWrapper动态拼条件，注意关键字搜索别用LIKE '%xx%'扫全表。

public Page<ResourceVO> search(ResourceQuery query, int page, int size) { LambdaQueryWrapper<Resource> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(query.getCategoryId() != null, Resource::getCategoryId, query.getCategoryId()) .eq(query.getResType() != null, Resource::getResType, query.getResType()) .eq(query.getOwnerId() != null, Resource::getOwnerId, query.getOwnerId()) .like(StringUtils.hasText(query.getKeyword()), Resource::getTitle, query.getKeyword()) .orderByDesc(Resource::getCreateTime); Page<Resource> p = resourceMapper.selectPage(new Page<>(page, size), wrapper); return p.convert(this::toVO); }

参数说明：每个eq的第一个参数是布尔条件，为 false 时该条件不拼进 SQL，这是 MyBatis-Plus 的条件构造惯例。like对title做模糊匹配，数据量上万后建议接 Elasticsearch 或至少给title建前缀索引。convert把实体转 VO，顺便填充分类名、上传者姓名，避免前端多次请求。

提示：分页查询的size要设上限，比如最大 100，否则有人传size=100000能把数据库拖垮。这个校验放在 Controller 层做。

4.3 缓存热点资源列表

首页或课程页的资源列表访问频率高、变化少，适合加缓存。用 Spring Cache 注解，key 按查询条件拼。

@Cacheable(value = "resList", key = "#query.categoryId + ':' + #query.resType + ':' + #page") public Page<ResourceVO> search(ResourceQuery query, int page, int size) { ... } @CacheEvict(value = "resList", allEntries = true) public Long upload(...) { ... }

上传、删除、改分类时清空缓存，保证一致性。allEntries = true简单粗暴但有效，资源列表缓存重建成本不高。如果并发上传频繁，可以改成按分类精确清除，但复杂度上升，小系统没必要。

5. 避坑与排查：那些让我加班到凌晨的细节

5.1 上传大文件报MaxUploadSizeExceededException

现象：传 100MB 以上视频直接 500，日志里是SizeLimitExceededException。原因是 Spring Boot 默认单文件和总请求大小都是 1MB。解决：在application.yml里显式配置。

spring: servlet: multipart: max-file-size: 500MB max-request-size: 500MB

如果前面还挂了 Nginx，记得同步改client_max_body_size，否则请求根本到不了应用。这两个地方漏一个都会翻车。

5.2 中文文件名下载后变成乱码

现象：下载的课件文件名显示成%E8%AF%BE%E4%BB%B6或问号。原因是Content-Disposition头没做编码，或者用了错误的字符集。解决：用URLEncoder.encode(name, "UTF-8")编码，并且把空格替换成%20。不同浏览器对filename*和filename的支持不一致，稳妥做法是两个都写。

5.3 分片合并后文件损坏

现象：合并出来的视频能播放但时长不对，或直接打不开。原因通常是分片没按索引顺序合并，或者某个分片上传失败但 Redis 里记了。解决：合并前校验uploaded.size() == totalChunks，合并时严格按0..totalChunks-1顺序读文件，合并后比对文件大小是否等于各分片之和。我一般还会在合并后算一次 MD5 和前端传的比对，不一致就删掉重传。

5.4 并发下载导致计数丢失

现象：download_cnt比实际下载次数少。原因是UPDATE resource SET download_cnt = download_cnt + 1在高并发下虽然原子，但和 Redis 累加回写混用时口径对不上。解决：统一走 RedisINCR，定时任务每 5 分钟把增量回写数据库，回写后用DECRBY扣掉已同步部分。别两套机制并行。

5.5 分类树递归查询慢

现象：资源列表按顶级分类筛选时，要递归查所有子分类 ID，数据量大后每次请求都卡。原因：递归查询没缓存，每次现算。解决：分类树变动极少，启动时加载全量分类到内存，构建parentId → children的 Map，递归取子分类在内存里完成。分类增删改时刷新这个缓存即可。

6. 进阶技巧：用异步与对象存储把系统撑到生产级

前面跑通的是单机版，真要在校内用起来，还得解决两个问题：文件存储的扩展性和上传后的处理耗时。我一般会把文件存储抽象成一个接口，本地磁盘和对象存储各一个实现，配置切换。

public interface StorageService { String save(InputStream in, String relativePath); InputStream load(String relativePath); void delete(String relativePath); }

本地实现用Files.copy，对象存储实现调 SDK 的putObject。业务代码只依赖接口，迁移时改配置不改代码。这个抽象在项目初期就该做，等文件散落各处再抽就晚了。

第二个技巧是上传后的异步处理。视频要转码、文档要生成缩略图、题库要解析入库，这些都不该卡在上传请求里。用 Spring 的@Async配合线程池，上传接口写完版本记录就返回，后台任务慢慢处理。

@Async("processExecutor") public void afterUpload(Long versionId) { ResourceVersion ver = versionMapper.selectById(versionId); if (ver.getMimeType().startsWith("video/")) { videoService.generateCover(ver); // 抽帧生成封面 } else if (ver.getMimeType().contains("pdf")) { docService.extractText(ver); // 抽取文本供检索 } }

线程池要显式配置，别用默认的SimpleAsyncTaskExecutor，那个每次新建线程，量大了直接 OOM。

@Bean("processExecutor") public Executor processExecutor() { ThreadPoolTaskExecutor ex = new ThreadPoolTaskExecutor(); ex.setCorePoolSize(4); ex.setMaxPoolSize(8); ex.setQueueCapacity(200); ex.setThreadNamePrefix("res-proc-"); ex.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); ex.initialize(); return ex; }

CallerRunsPolicy在队列满时让调用线程自己执行，起到背压作用，比直接丢弃任务稳妥。核心线程数按 CPU 核数配，转码这种 CPU 密集任务别开太多。

验证这套系统是否达标，我习惯看三个指标：上传 200MB 文件在 30 秒内完成、资源列表接口 P99 在 200ms 以内、并发 50 个下载请求不出现计数丢失。压测用 JMeter 或 wrk 都行，重点观察数据库连接池和线程池的排队情况。

最后说个我自己的习惯：每加一个功能，先在本地用curl把接口单独跑通，再写前端联调。教学资源管理系统这类项目，接口参数多、权限分支杂，前端报错往往掩盖了后端真实问题，先隔离验证能省下大量排查时间。希望帮到你。

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