1. 项目概述与背景1.1 这是一个什么项目能解决什么问题又见到这个经典搭配了——SpringBoot Vue MyBatis MySQL。说实话在2025年这个时间节点这套技术栈仍然是国内Java后端的主流配置尤其是对刚入行的朋友和在校学生来说这套组合基本上是面试聊项目时最稳妥的选择。这个教学资源库管理系统通俗点说就是给学校或培训机构做一个“内部资源网盘”。老师可以把课件PPT、教学视频、实验指导书、试题试卷上传上去学生可以按课程、按分类去检索下载管理员负责审核资源、管理用户、维护分类。就这么一套东西看起来简单但把用户体系、文件上传下载、搜索分页、权限控制、审核流全串起来了前后端都有完整的落地点所以这类项目在毕业设计、课程设计、简历项目里一直很受欢迎。我在实际带人的过程中发现很多人拿到这类项目源码后要么看不懂模块之间的调用关系要么部署起来各种报错更常见的是不知道面试时怎么把这个项目讲出深度。所以这篇文章我就按自己做实际项目管理时的思路把需求拆解、表结构设计、核心流程实现、部署踩坑这些环节完整走一遍。文章里涉及的细节是基于教学中常见实践做的一些补充不是网上那种只贴代码不解释的做法。1.2 适合谁来学习和参考如果你属于下面这几类人这个项目值得花时间吃透在校学生准备毕业设计或课程设计需要一套能跑通、能讲清楚、能通过答辩的完整系统。初级Java开发简历里缺一个拿得出手的全栈项目想通过一个具体项目把SpringBoot、MyBatis、Vue这些知识点串成体系。需要快速交付的管理人员学校信息中心或培训机构的老师需要快速搭一套资源管理平台不需要太多花哨功能重在稳定可用。这套系统的业务边界其实非常清晰——“用户-资源-审核”是三个核心域往外扩展就是分类管理、统计看板、个人收藏。边界清晰意味着代码结构容易看懂也意味着你拿到源码后能快速定位到某个功能在哪改这种“掌控感”对学习来说很重要。2. 核心需求拆解与技术选型背后的思考2.1 用户角色与功能划分做管理系统第一件事不是写代码而是先把角色和权限理清楚。这个系统我按实际使用场景拆成了三种角色每种角色看到的界面和能做的操作都不一样角色核心权限典型操作学生浏览、搜索、下载资源预览、点赞、收藏、评论教师上传资源、管理自己的资源上传课件、修改资源信息、查看下载量管理员全系统管理用户管理、资源审核、分类维护、数据统计这里要特别说一下权限设计不能简单地在用户表里加一个“role”字段就完事。虽然这个系统规模不大直接判断角色也能跑得通但考虑到后续可能会扩展“助教”“校外专家”之类的新角色我在设计时采用了RBAC基于角色的访问控制模型来做。具体到实现层面不一定非要引入Spring Security那一套复杂的东西用一个JWT拦截器加自定义注解项目里已经够用了。这种“够用就好”的思路是实际开发里很关键的一点判断力。很多初学者容易走极端要么什么都不加直接在Controller里写死判断要么一上来就堆Spring Security加OAuth2结果自己都搞不清楚配置是什么意思。实际做法应该是在满足当前需求的前提下留一点扩展余地等真需要的时候再平滑升级。2.2 技术选型为什么还是这三件套先聊后端。SpringBoot的选型理由几乎没有争议内嵌Tomcat、自动化配置、生态成熟、招人容易。市面上绝大多数Java项目都是这套玩法遇到问题搜索引擎一搜一大把答案这本身就是一种隐形价值。MyBatis和JPA之间我果断选了MyBatis。原因有三第一这类管理系统的SQL虽然不复杂但涉及多表关联查询、条件动态拼接的场景不少MyBatis的XML文件里写动态SQL非常顺手第二国内大部分高校的数据库课程和Java课程都以MyBatis为主你拿这套去面试和答辩沟通成本最低第三MyBatis半自动化的特性反而给了我们SQL优化空间出问题时可以直接定位到SQL语句本身不需要去猜ORM生成的是什么玩意儿。前端选Vue原因更简单——入门曲线平缓、中文资料丰富、单文件组件开发体验好。管理系统这种“表格加表单”为主的项目Vue的响应式数据绑定能让代码量少写三分之一以上。数据库层面MySQL是这个量级项目的默认答案。开源免费、文档全、和Navicat等图形化工具配合起来效率高。系统同时提供了数据库初始化脚本用Navicat导入就能用不需要折腾命令行导入那些事。2.3 单体架构还是微服务这是一个伪命题很多人一拿到项目就问“为什么不用Spring Cloud拆微服务”。对这种资源管理系统来说微服务是典型的过度设计。想想看你的用户量可能是几百人并发峰值可能就是选课那两天用一个单体应用加合理的SQL索引性能完全够用。拆成微服务反而引入了服务注册发现、配置中心、分布式事务这一大堆复杂度开发和部署成本翻好几倍收益几乎为零。我之前见过一个学生毕业设计非要用微服务把用户、资源、评论拆成三个服务最后答辩时讲不清楚服务间怎么通信的反而被老师问住了。架构选型的核心逻辑永远是“复杂度匹配业务规模”一个几百人用的教学资源库单体架构加前后端分离就是最优解。2.4 为什么前后端分离是对的这个项目采用前后端分离前端Vue跑在8080端口后端SpringBoot跑在8081端口通过HTTP接口通信。这样做的好处最直接的一点是开发时可以并行——前端同学只需要拿接口文档Swagger自动生成就可以Mock数据开发不需要等后端接口完全写好。部署时前端打包成静态文件丢给Nginx后端打成Jar包独立运行两边互不影响。但同时也要明白前后端分离会带来一个必然要处理的问题跨域和鉴权。跨域需要在后端配置CORS鉴权则用JWT解决。这个项目里把这两块的配置都做进去了我会在后面详细讲怎么落地。3. 数据库设计与核心实现3.1 数据库表结构一张表一张表地过表结构设计直接决定了后面写业务代码时是舒服还是痛苦。这套系统的核心表我列一下sys_user 用户表 resource_info 资源信息主表 resource_file 资源文件表 resource_category 资源分类表 resource_comment 评论表 resource_favorite 收藏表 audit_record 审核记录表重点说resource_info这张表它是整个系统的中枢。我设计的核心字段包括id主键自增title资源标题description资源描述category_id分类ID关联resource_categoryuploader_id上传人ID关联sys_userstatus资源状态0草稿 1待审核 2已上架 3已驳回 4已下架download_count下载量cover_url封面图路径create_time/update_time创建和更新时间这里有个设计细节值得展开说资源状态字段。我没有用简单的布尔值来标识“是否审核通过”而是用了状态码。为什么因为资源在系统中是有生命周期的老师先传了保存成草稿然后提交审核管理员审核通过后上架如果后面课件内容过时可以下架审核不过的还能驳回让老师改。这些状态流转用布尔字段根本表达不出来用状态码就能很清晰地管理。对应地审核记录单独拆了一张audit_record表。每次管理员审核操作都会插入一条记录包含审核人、审核时间、审核意见。这样好处很明显系统里出现的每一条资源状态变更都有迹可循如果哪天出了问题需要追溯是谁在什么时候做了什么操作直接查表就行。这个设计在面试时提到会是一个加分点。3.2 用户登录与JWT鉴权全流程登录模块是这类型管理系统绕不开的起点。这套系统用的是JWTJSON Web Token做无状态鉴权流程分几步用户在登录页输入账号密码请求打到后端的/api/auth/login接口后端用MyBatis查询用户表用BCrypt算法校验密码校验通过后用用户ID、用户名、角色生成一个Token返回给前端前端把Token存在本地localStorage之后每一次接口请求都在Header里带上Authorization: Bearer token后端配置拦截器除了登录接口和获取验证码的接口外所有请求都要校验Token有效性考虑密码安全这里要插一句很实在的建议数据库里存的密码绝对不要是明文。项目里用的BCrypt加密算法它是Spring Security内置的也可以单独引入spring-security-crypto。BCrypt的厉害之处在于它自带盐值同一个密码每次加密出来的结果都不同而且计算速度刻意设计得比较慢能有效抵御暴力破解。相比简单的MD5加盐方案BCrypt的安全性高一个量级。Token过期时间我设置在2小时。这个值是有讲究的——太短了用户动不动就被踢下线体验很差太长了安全风险增加。2小时对教学场景是一个比较平衡的值。前端在Axios的响应拦截器里判断后端返回的401状态码一旦发现Token过期就自动跳转回登录页省去了用户手动清除缓存的麻烦。3.3 核心链路资源上传与审核闭环资源上传是整个系统最核心的功能也是事务和状态流转最容易出错的地方。完整流程这样走第一步教师登录后进入“我的资源”页面点击上传。前端用Element-UI的Upload组件提交方式设成multipart/form-data。这里输出的是一个包含文件二进制数据和资源元信息标题、描述、分类的混合表单。第二步后端接收并处理。Controller层用一个DTO对象接收元信息用MultipartFile接收文件。然后调用Service层Service层里做三件关键事把文件写到存储目录并生成唯一的存储文件名用UUID加原始后缀名避免文件名冲突组装resource_info记录并插入数据库初始状态设为“待审核”把文件路径和资源ID关联写入resource_file表。这里有一个特别容易踩的坑文件突然消失了数据库记录还在。原因是实际存储路径和代码里写的相对路径不一致。我自己习惯的做法是用绝对路径配置在application.yml里定义file.upload-path生产环境直接指到服务器上一个专用目录。这样排查问题时路径清清楚楚不会出现找不到文件的尴尬。第三步管理员审核。管理员在后台看到一个“待审核”列表点开可以预览资源信息。审核通过就把status改成2已上架不通过就改成3已驳回并填写驳回原因。教师在前端就能看到审核状态和原因改完可以重新提交。这个闭环在工作流引擎里属于简单审批流但小学生都知道杀鸡不用牛刀——直接写在Service层一个audit()方法里事务控制在方法级别传入审核结果和审核意见先更新资源状态再插入审核记录所有数据操作在一个事务里完成要么全成功要么全失败逻辑非常清晰。3.4 MyBatis动态SQL的精髓应用服务端代码有个地方是体现功力的——资源搜索。搜索条件通常包含关键词模糊匹配、分类筛选、时间范围、状态筛选、排序方式五六个条件而且这些条件里可能有也可能没有。如果用JPA写这种动态查询要多写不少代码。MyBatis的where加if标签在这种场景下简直是天生为这种需求准备的。我贴一段典型的Mapper XML写法select idsearchResources resultTypecom.example.vo.ResourceVO SELECT r.*, c.name AS category_name, u.real_name AS uploader_name FROM resource_info r LEFT JOIN resource_category c ON r.category_id c.id LEFT JOIN sys_user u ON r.uploader_id u.id where if testkeyword ! null and keyword ! AND r.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND r.category_id #{categoryId} /if if teststatus ! null AND r.status #{status} /if /where ORDER BY r.create_time DESC /select注意几个小细节CONCAT(%, #{keyword}, %)这里不推荐直接写%${keyword}%用${}存在SQL注入风险#{}预编译才安全。LEFT JOIN而不是INNER JOIN是为了保证即使分类或用户被删了资源记录仍然能查出来。3.5 前端路由与权限控制的落地Vue前端部分除了页面组件有两块基础设施是必须提前做好的路由守卫和请求封装。路由配置里我给每个路由的meta上加了roles字段标明哪个角色可以访问。比如“学生后台”这个路由只有student角色能见“审核管理”这个路由只有admin角色能见。然后在全局前置守卫里统一做校验router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() return } if (!token) { next(/login) return } const userRole store.state.user.role if (to.meta.roles !to.meta.roles.includes(userRole)) { next(/403) return } next() })Axios封装这里除了上面提到的统一携带Token还要做统一错误处理。比如后端返回500时统一弹一个错误提示而不是让每个页面各自处理错误。实际开发中我发现很多人项目的重复代码非常多光“Token过期跳登录”这个逻辑就写了好几遍。做一个统一的Axios实例在拦截器里处理认证和异常能省下非常多的重复劳动。4. 实测过程中遇到的坑建议收藏4.1 事务失效文件传了数据库没记录事务这个东西配置错一步就等于没配置。我见过太多人在上传资源这个接口里犯错文件用MultipartFile.transferTo()写到磁盘然后resourceMapper.insert()插入数据库但Service方法上没有加Transactional注解或者加在了一个没有被Spring管理的方法上。结果就是文件写成功了数据库插入失败了垃圾文件堆积在服务器上。排查这类问题建议先确认注解有没有加在public方法上其次是确认调用是否经过了Spring代理——同一个类内部的this.xxx()调用不会走代理所以事务不生效。事务这块的坑我建议把这几个基础问题背清楚Transactional失效的几种经典场景、REQUIRED和REQUIRES_NEW的区别、为什么不能用try-catch吞掉异常后再让事务回滚。4.2 MyBatis返回null导致前端组件渲染异常项目里有个很经典的问题按ID查询资源详情的时候如果ID传了一个不存在的值后端Mapper返回nullController没做判空直接返回给前端。前端拿到的数据是{...}这种空结构页面组件里如果写了resource.title这种取值就会直接报错“Cannot read properties of null”白屏一片。这类问题好排查但根子在于后端接口设计不够健壮。建议Controller层统一做空值校验查不到数据就返回一个明确的错误码不要返回null。前端的Axios拿到错误码后统一展示“数据不存在”的提示体验会好很多。4.3 文件上传大小限制导致大视频传不上去项目默认的SpringBoot上传大小限制是1MB但教学资源里经常有几十上百兆的视频文件。第一次部署的人经常传个课件就报错以为是自己代码问题其实只要在配置文件里调大限制就行spring: servlet: multipart: max-file-size: 200MB max-request-size: 200MB还有配套的一个问题Nginx反向代理时也有client_max_body_size限制默认是1MB。如果你用了Nginx转发请求到后端光改SpringBoot是不够的还要在Nginx配置里加上client_max_body_size 200m;这两个都得改少一个都会出现“小文件能传大文件报413或500”的情况。4.4 时间字段类型不一致导致JSON格式化异常用了MyBatis加MySQL插入一条包含create_time的记录后前端拿到的时间字符串可能长这样2025-03-12T08:30:45带一个莫名其妙的字母T。这是Java 8的LocalDateTime直接序列化产生的默认格式和前端期望的2025-03-12 08:30:45不一致。解决办法有两个一是在application.yml里做全局配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8二是用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解在实体类的日期字段上。我建议项目里统一用第一种全局方案省得每个字段都得加注解。4.5 分页查询的count结果不准如果分页用了PageHelper插件在多表LEFT JOIN的情况下count语句有可能计算不准确。原因是PageHelper的count是自动生成的某些情况下它会把你SQL里的JOIN带给左边表的去重效果给算进去。实际解决办法是复杂分页查询不要偷懒用PageHelper自动count改成手写count查询语句或者在Mapper里面单独写一个countResources方法逻辑和列表查询保持一致分页参数单独处理。很多时候“老司机不翻车”并不是技术多高深而是该手写的地方不偷懒。5. 部署上线全流程实录5.1 后端环境准备与打包本地开发跑通之后部署到服务器是另一套活儿。后端部署需要的东西比较固定JDK 8或11项目用的是JDK 8兼容性最好MySQL 8.0Maven打包命令在项目根目录执行mvn clean package -DskipTests打出来的Jar包在target目录下。部署时我习惯建一个专门的部署目录把application.yml里的数据库连接信息改成生产环境的地址和账号密码。启动命令nohup java -jar resource-server.jar --server.port8081 server.log 21 这里要注意项目里配置文件和数据库账号密码属于敏感信息生产环境建议用环境变量覆盖不要在源码里写死生产数据库的明文密码。启动完成后用curl http://localhost:8081/api/health验证后端是否正常。如果接口能返回正常结果说明后端已经跑起来了。5.2 前端构建与Nginx部署前端部署更简单在Vue项目目录下执行npm run build构建完成后dist目录里就是打包好的静态资源。把dist目录整个上传到服务器Nginx配置的站点根目录然后修改Nginx配置把/api开头的请求转发到后端server { listen 80; server_name your-domain.com; location / { root /var/www/resource-system/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这一行很关键——它保证Vue Router的history模式在刷新页面时不会404。之前有个学生部署完发现从首页点进详情页没问题但直接刷新详情页就404就是因为没加这一行他的Vue路由用的是history模式刷新时浏览器直接请求服务器路径服务器找不到对应文件就404了。微调之后重新加载Nginx配置nginx -s reload整个系统从浏览器输入域名就可以访问了。5.3 上线前的数据初始化部署完成后还有一步容易忽略初始化基础数据。比如管理员账号、资源分类、默认配置。项目中提供了一个schema.sql和一个data.sql分别建表和插入初始化数据。用Navicat执行一遍就行。一个实用建议在data.sql里把管理员账号密码提前写好密码用BCrypt加密后的结果存进去。这样可以保证首次登录就能用管理员账号进入系统不用再去数据库里手动改密码。初始化数据的同时建议顺便核对一下MySQL时区设置是否用的SYSTEM如果不是插入的时间字段可能和实际差8个小时。这个问题的解法是在MySQL连接串上显式加上serverTimezoneAsia/Shanghai。6. 核心问题排查技巧与实战心得6.1 排查思路日志、接口、数据三步定位项目出问题后我的排查顺序基本是固定的第一步看日志。后端日志文件里有没有异常堆栈前端浏览器控制台有没有报错网络请求的状态码是多少。第二步调接口。用Postman或Swagger直接调用出问题的接口确认问题在前端还是后端。这一步能排除大量“看起来是后端问题实际是前端没传对参数”的乌龙。第三步查数据。数据库里数据记录的状态和内容是怎样的是压根没写进去还是写进去了但查不出来。这套“日志—接口—数据”三步法90%的系统性问题都能定位。剩下的10%基本是环境差异、缓存、并发这类硬骨头把问题现象完整记录下来带着日志去找答案比瞎猜有效得多。6.2 资源数据错乱和脏数据预防上线初期最容易出现的另一类问题是因为用户反复操作产生的脏数据。比如取消收藏但记录没删干净用户删除资源但文件没同步删除审核驳回但资源状态没及时回退。解决思路有两个方向一是数据库层加必要的唯一约束和外键关系二是在Service层写业务逻辑时多做“幂等检查”——比如收藏操作插入前先查一下是否已经收藏过避免出现同一个用户对同一个资源插入多条收藏记录。幂等性这个概念听起来高大上其实就是“同一个操作重复执行多次结果都一样”写接口时多想一步就能避免很多数据问题。6.3 性能优化从SQL到Redis的提升路径资源管理系统在初期几百个用户、几千条资源的情况下性能其实不构成瓶颈。但聊到优化方向面试中这是必考点。大致的优化路径是SQL索引优化。给resource_info表的category_id、status、create_time字段加上普通索引查询效率提升非常明显。最基础但最有效。减少无效查询。热门分类下资源的搜索和列表接口能合并的查询就合并避免在一个循环里反复调数据库。引入Redis做缓存。把热点分类树、系统配置、用户会话缓存到Redis里。资源详细内容这类低频变化数据也可以做30秒短缓存。但不要无脑把所有接口都加缓存——资源列表被人改了就更新缓存这种一致性维护成本往往比缓存收益更高。文件存储替换。当文件越来越大本地磁盘不够用时会自然想到把资源文件迁移到对象存储比如MinIO或者云服务商的对象存储。这个渐进式演进方式比一上来就上全套分布式架构要务实得多。6.4 面试中如何把这个项目讲出亮点拿这个项目去面试时最大的误区是上来就背功能清单“我们这个系统有登录、上传、下载、审核、评论……”面试官听这种话已经听了上千遍了毫无记忆点。正确的方式是以方案取舍和问题解决为主线比如“登录这块我为什么用JWT而不是Session因为前后端分离下Session有跨域和扩展性问题JWT无状态更适合这种场景。”“审核状态我为什么用状态码而不是布尔字段因为资源有草稿、待审核、已上架、已驳回多个状态布尔表达不了。”“上传文件时我遇到过事务失效的问题排查后确认是因为方法没走Spring代理从那之后凡是多表写操作我都检查一遍事务配置。”“分页查询在JOIN的时候count不准我把它改成了手写count准确性和性能都更好。”这些问题一旦聊起来面试官自然能从“这个项目是不是你做的”过渡到“这个人的技术判断力怎么样”这才是项目经验真正值钱的地方。7. 个人实操后的三个建议项目完全跑通之后我个人最深的感触有三点。第一点遇到问题不要先怀疑框架先怀疑自己的使用方式。很多看起来是SpringBoot、MyBatis的“bug”最后查出来都是配置文件写错、注解漏加、路径不对这类低级问题。把日志看仔细、把请求链路理清楚绝大多数问题都能自己解决。第二点源码阅读很重要尤其是你能改的源码。这个项目拿到后建议不要只跑起来看一眼至少把pom.xml里关键的依赖关系理一遍把自己的代码从头到尾读一遍。能讲清楚“为什么这么写”才敢说这个项目算你的。我建议可以先改一个小功能比如把密码加密从MD5升到BCrypt或者给查询列表加上排序功能从“能跑”进步到“能改”是走向“能设计”的第一步。第三点扩展的方向想清楚再动手。如果你想让这个项目看起来更有竞争力可以考虑往下面几个方向扩展一是用MinIO替换本地存储二是用Redis加缓存三是用ElasticSearch做全文检索四是给教师端加数据可视化看板统计资源下载趋势。这些方向每一个单拆开都能成为面试时深入聊的点也比堆砌多个小功能更聚焦。但别一次全加挑一个方向做深做透收获会更大。
1. 项目概述与背景1.1 这是一个什么项目能解决什么问题又见到这个经典搭配了——SpringBoot Vue MyBatis MySQL。说实话在2025年这个时间节点这套技术栈仍然是国内Java后端的主流配置尤其是对刚入行的朋友和在校学生来说这套组合基本上是面试聊项目时最稳妥的选择。这个教学资源库管理系统通俗点说就是给学校或培训机构做一个“内部资源网盘”。老师可以把课件PPT、教学视频、实验指导书、试题试卷上传上去学生可以按课程、按分类去检索下载管理员负责审核资源、管理用户、维护分类。就这么一套东西看起来简单但把用户体系、文件上传下载、搜索分页、权限控制、审核流全串起来了前后端都有完整的落地点所以这类项目在毕业设计、课程设计、简历项目里一直很受欢迎。我在实际带人的过程中发现很多人拿到这类项目源码后要么看不懂模块之间的调用关系要么部署起来各种报错更常见的是不知道面试时怎么把这个项目讲出深度。所以这篇文章我就按自己做实际项目管理时的思路把需求拆解、表结构设计、核心流程实现、部署踩坑这些环节完整走一遍。文章里涉及的细节是基于教学中常见实践做的一些补充不是网上那种只贴代码不解释的做法。1.2 适合谁来学习和参考如果你属于下面这几类人这个项目值得花时间吃透在校学生准备毕业设计或课程设计需要一套能跑通、能讲清楚、能通过答辩的完整系统。初级Java开发简历里缺一个拿得出手的全栈项目想通过一个具体项目把SpringBoot、MyBatis、Vue这些知识点串成体系。需要快速交付的管理人员学校信息中心或培训机构的老师需要快速搭一套资源管理平台不需要太多花哨功能重在稳定可用。这套系统的业务边界其实非常清晰——“用户-资源-审核”是三个核心域往外扩展就是分类管理、统计看板、个人收藏。边界清晰意味着代码结构容易看懂也意味着你拿到源码后能快速定位到某个功能在哪改这种“掌控感”对学习来说很重要。2. 核心需求拆解与技术选型背后的思考2.1 用户角色与功能划分做管理系统第一件事不是写代码而是先把角色和权限理清楚。这个系统我按实际使用场景拆成了三种角色每种角色看到的界面和能做的操作都不一样角色核心权限典型操作学生浏览、搜索、下载资源预览、点赞、收藏、评论教师上传资源、管理自己的资源上传课件、修改资源信息、查看下载量管理员全系统管理用户管理、资源审核、分类维护、数据统计这里要特别说一下权限设计不能简单地在用户表里加一个“role”字段就完事。虽然这个系统规模不大直接判断角色也能跑得通但考虑到后续可能会扩展“助教”“校外专家”之类的新角色我在设计时采用了RBAC基于角色的访问控制模型来做。具体到实现层面不一定非要引入Spring Security那一套复杂的东西用一个JWT拦截器加自定义注解项目里已经够用了。这种“够用就好”的思路是实际开发里很关键的一点判断力。很多初学者容易走极端要么什么都不加直接在Controller里写死判断要么一上来就堆Spring Security加OAuth2结果自己都搞不清楚配置是什么意思。实际做法应该是在满足当前需求的前提下留一点扩展余地等真需要的时候再平滑升级。2.2 技术选型为什么还是这三件套先聊后端。SpringBoot的选型理由几乎没有争议内嵌Tomcat、自动化配置、生态成熟、招人容易。市面上绝大多数Java项目都是这套玩法遇到问题搜索引擎一搜一大把答案这本身就是一种隐形价值。MyBatis和JPA之间我果断选了MyBatis。原因有三第一这类管理系统的SQL虽然不复杂但涉及多表关联查询、条件动态拼接的场景不少MyBatis的XML文件里写动态SQL非常顺手第二国内大部分高校的数据库课程和Java课程都以MyBatis为主你拿这套去面试和答辩沟通成本最低第三MyBatis半自动化的特性反而给了我们SQL优化空间出问题时可以直接定位到SQL语句本身不需要去猜ORM生成的是什么玩意儿。前端选Vue原因更简单——入门曲线平缓、中文资料丰富、单文件组件开发体验好。管理系统这种“表格加表单”为主的项目Vue的响应式数据绑定能让代码量少写三分之一以上。数据库层面MySQL是这个量级项目的默认答案。开源免费、文档全、和Navicat等图形化工具配合起来效率高。系统同时提供了数据库初始化脚本用Navicat导入就能用不需要折腾命令行导入那些事。2.3 单体架构还是微服务这是一个伪命题很多人一拿到项目就问“为什么不用Spring Cloud拆微服务”。对这种资源管理系统来说微服务是典型的过度设计。想想看你的用户量可能是几百人并发峰值可能就是选课那两天用一个单体应用加合理的SQL索引性能完全够用。拆成微服务反而引入了服务注册发现、配置中心、分布式事务这一大堆复杂度开发和部署成本翻好几倍收益几乎为零。我之前见过一个学生毕业设计非要用微服务把用户、资源、评论拆成三个服务最后答辩时讲不清楚服务间怎么通信的反而被老师问住了。架构选型的核心逻辑永远是“复杂度匹配业务规模”一个几百人用的教学资源库单体架构加前后端分离就是最优解。2.4 为什么前后端分离是对的这个项目采用前后端分离前端Vue跑在8080端口后端SpringBoot跑在8081端口通过HTTP接口通信。这样做的好处最直接的一点是开发时可以并行——前端同学只需要拿接口文档Swagger自动生成就可以Mock数据开发不需要等后端接口完全写好。部署时前端打包成静态文件丢给Nginx后端打成Jar包独立运行两边互不影响。但同时也要明白前后端分离会带来一个必然要处理的问题跨域和鉴权。跨域需要在后端配置CORS鉴权则用JWT解决。这个项目里把这两块的配置都做进去了我会在后面详细讲怎么落地。3. 数据库设计与核心实现3.1 数据库表结构一张表一张表地过表结构设计直接决定了后面写业务代码时是舒服还是痛苦。这套系统的核心表我列一下sys_user 用户表 resource_info 资源信息主表 resource_file 资源文件表 resource_category 资源分类表 resource_comment 评论表 resource_favorite 收藏表 audit_record 审核记录表重点说resource_info这张表它是整个系统的中枢。我设计的核心字段包括id主键自增title资源标题description资源描述category_id分类ID关联resource_categoryuploader_id上传人ID关联sys_userstatus资源状态0草稿 1待审核 2已上架 3已驳回 4已下架download_count下载量cover_url封面图路径create_time/update_time创建和更新时间这里有个设计细节值得展开说资源状态字段。我没有用简单的布尔值来标识“是否审核通过”而是用了状态码。为什么因为资源在系统中是有生命周期的老师先传了保存成草稿然后提交审核管理员审核通过后上架如果后面课件内容过时可以下架审核不过的还能驳回让老师改。这些状态流转用布尔字段根本表达不出来用状态码就能很清晰地管理。对应地审核记录单独拆了一张audit_record表。每次管理员审核操作都会插入一条记录包含审核人、审核时间、审核意见。这样好处很明显系统里出现的每一条资源状态变更都有迹可循如果哪天出了问题需要追溯是谁在什么时候做了什么操作直接查表就行。这个设计在面试时提到会是一个加分点。3.2 用户登录与JWT鉴权全流程登录模块是这类型管理系统绕不开的起点。这套系统用的是JWTJSON Web Token做无状态鉴权流程分几步用户在登录页输入账号密码请求打到后端的/api/auth/login接口后端用MyBatis查询用户表用BCrypt算法校验密码校验通过后用用户ID、用户名、角色生成一个Token返回给前端前端把Token存在本地localStorage之后每一次接口请求都在Header里带上Authorization: Bearer token后端配置拦截器除了登录接口和获取验证码的接口外所有请求都要校验Token有效性考虑密码安全这里要插一句很实在的建议数据库里存的密码绝对不要是明文。项目里用的BCrypt加密算法它是Spring Security内置的也可以单独引入spring-security-crypto。BCrypt的厉害之处在于它自带盐值同一个密码每次加密出来的结果都不同而且计算速度刻意设计得比较慢能有效抵御暴力破解。相比简单的MD5加盐方案BCrypt的安全性高一个量级。Token过期时间我设置在2小时。这个值是有讲究的——太短了用户动不动就被踢下线体验很差太长了安全风险增加。2小时对教学场景是一个比较平衡的值。前端在Axios的响应拦截器里判断后端返回的401状态码一旦发现Token过期就自动跳转回登录页省去了用户手动清除缓存的麻烦。3.3 核心链路资源上传与审核闭环资源上传是整个系统最核心的功能也是事务和状态流转最容易出错的地方。完整流程这样走第一步教师登录后进入“我的资源”页面点击上传。前端用Element-UI的Upload组件提交方式设成multipart/form-data。这里输出的是一个包含文件二进制数据和资源元信息标题、描述、分类的混合表单。第二步后端接收并处理。Controller层用一个DTO对象接收元信息用MultipartFile接收文件。然后调用Service层Service层里做三件关键事把文件写到存储目录并生成唯一的存储文件名用UUID加原始后缀名避免文件名冲突组装resource_info记录并插入数据库初始状态设为“待审核”把文件路径和资源ID关联写入resource_file表。这里有一个特别容易踩的坑文件突然消失了数据库记录还在。原因是实际存储路径和代码里写的相对路径不一致。我自己习惯的做法是用绝对路径配置在application.yml里定义file.upload-path生产环境直接指到服务器上一个专用目录。这样排查问题时路径清清楚楚不会出现找不到文件的尴尬。第三步管理员审核。管理员在后台看到一个“待审核”列表点开可以预览资源信息。审核通过就把status改成2已上架不通过就改成3已驳回并填写驳回原因。教师在前端就能看到审核状态和原因改完可以重新提交。这个闭环在工作流引擎里属于简单审批流但小学生都知道杀鸡不用牛刀——直接写在Service层一个audit()方法里事务控制在方法级别传入审核结果和审核意见先更新资源状态再插入审核记录所有数据操作在一个事务里完成要么全成功要么全失败逻辑非常清晰。3.4 MyBatis动态SQL的精髓应用服务端代码有个地方是体现功力的——资源搜索。搜索条件通常包含关键词模糊匹配、分类筛选、时间范围、状态筛选、排序方式五六个条件而且这些条件里可能有也可能没有。如果用JPA写这种动态查询要多写不少代码。MyBatis的where加if标签在这种场景下简直是天生为这种需求准备的。我贴一段典型的Mapper XML写法select idsearchResources resultTypecom.example.vo.ResourceVO SELECT r.*, c.name AS category_name, u.real_name AS uploader_name FROM resource_info r LEFT JOIN resource_category c ON r.category_id c.id LEFT JOIN sys_user u ON r.uploader_id u.id where if testkeyword ! null and keyword ! AND r.title LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND r.category_id #{categoryId} /if if teststatus ! null AND r.status #{status} /if /where ORDER BY r.create_time DESC /select注意几个小细节CONCAT(%, #{keyword}, %)这里不推荐直接写%${keyword}%用${}存在SQL注入风险#{}预编译才安全。LEFT JOIN而不是INNER JOIN是为了保证即使分类或用户被删了资源记录仍然能查出来。3.5 前端路由与权限控制的落地Vue前端部分除了页面组件有两块基础设施是必须提前做好的路由守卫和请求封装。路由配置里我给每个路由的meta上加了roles字段标明哪个角色可以访问。比如“学生后台”这个路由只有student角色能见“审核管理”这个路由只有admin角色能见。然后在全局前置守卫里统一做校验router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() return } if (!token) { next(/login) return } const userRole store.state.user.role if (to.meta.roles !to.meta.roles.includes(userRole)) { next(/403) return } next() })Axios封装这里除了上面提到的统一携带Token还要做统一错误处理。比如后端返回500时统一弹一个错误提示而不是让每个页面各自处理错误。实际开发中我发现很多人项目的重复代码非常多光“Token过期跳登录”这个逻辑就写了好几遍。做一个统一的Axios实例在拦截器里处理认证和异常能省下非常多的重复劳动。4. 实测过程中遇到的坑建议收藏4.1 事务失效文件传了数据库没记录事务这个东西配置错一步就等于没配置。我见过太多人在上传资源这个接口里犯错文件用MultipartFile.transferTo()写到磁盘然后resourceMapper.insert()插入数据库但Service方法上没有加Transactional注解或者加在了一个没有被Spring管理的方法上。结果就是文件写成功了数据库插入失败了垃圾文件堆积在服务器上。排查这类问题建议先确认注解有没有加在public方法上其次是确认调用是否经过了Spring代理——同一个类内部的this.xxx()调用不会走代理所以事务不生效。事务这块的坑我建议把这几个基础问题背清楚Transactional失效的几种经典场景、REQUIRED和REQUIRES_NEW的区别、为什么不能用try-catch吞掉异常后再让事务回滚。4.2 MyBatis返回null导致前端组件渲染异常项目里有个很经典的问题按ID查询资源详情的时候如果ID传了一个不存在的值后端Mapper返回nullController没做判空直接返回给前端。前端拿到的数据是{...}这种空结构页面组件里如果写了resource.title这种取值就会直接报错“Cannot read properties of null”白屏一片。这类问题好排查但根子在于后端接口设计不够健壮。建议Controller层统一做空值校验查不到数据就返回一个明确的错误码不要返回null。前端的Axios拿到错误码后统一展示“数据不存在”的提示体验会好很多。4.3 文件上传大小限制导致大视频传不上去项目默认的SpringBoot上传大小限制是1MB但教学资源里经常有几十上百兆的视频文件。第一次部署的人经常传个课件就报错以为是自己代码问题其实只要在配置文件里调大限制就行spring: servlet: multipart: max-file-size: 200MB max-request-size: 200MB还有配套的一个问题Nginx反向代理时也有client_max_body_size限制默认是1MB。如果你用了Nginx转发请求到后端光改SpringBoot是不够的还要在Nginx配置里加上client_max_body_size 200m;这两个都得改少一个都会出现“小文件能传大文件报413或500”的情况。4.4 时间字段类型不一致导致JSON格式化异常用了MyBatis加MySQL插入一条包含create_time的记录后前端拿到的时间字符串可能长这样2025-03-12T08:30:45带一个莫名其妙的字母T。这是Java 8的LocalDateTime直接序列化产生的默认格式和前端期望的2025-03-12 08:30:45不一致。解决办法有两个一是在application.yml里做全局配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8二是用JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)注解在实体类的日期字段上。我建议项目里统一用第一种全局方案省得每个字段都得加注解。4.5 分页查询的count结果不准如果分页用了PageHelper插件在多表LEFT JOIN的情况下count语句有可能计算不准确。原因是PageHelper的count是自动生成的某些情况下它会把你SQL里的JOIN带给左边表的去重效果给算进去。实际解决办法是复杂分页查询不要偷懒用PageHelper自动count改成手写count查询语句或者在Mapper里面单独写一个countResources方法逻辑和列表查询保持一致分页参数单独处理。很多时候“老司机不翻车”并不是技术多高深而是该手写的地方不偷懒。5. 部署上线全流程实录5.1 后端环境准备与打包本地开发跑通之后部署到服务器是另一套活儿。后端部署需要的东西比较固定JDK 8或11项目用的是JDK 8兼容性最好MySQL 8.0Maven打包命令在项目根目录执行mvn clean package -DskipTests打出来的Jar包在target目录下。部署时我习惯建一个专门的部署目录把application.yml里的数据库连接信息改成生产环境的地址和账号密码。启动命令nohup java -jar resource-server.jar --server.port8081 server.log 21 这里要注意项目里配置文件和数据库账号密码属于敏感信息生产环境建议用环境变量覆盖不要在源码里写死生产数据库的明文密码。启动完成后用curl http://localhost:8081/api/health验证后端是否正常。如果接口能返回正常结果说明后端已经跑起来了。5.2 前端构建与Nginx部署前端部署更简单在Vue项目目录下执行npm run build构建完成后dist目录里就是打包好的静态资源。把dist目录整个上传到服务器Nginx配置的站点根目录然后修改Nginx配置把/api开头的请求转发到后端server { listen 80; server_name your-domain.com; location / { root /var/www/resource-system/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files这一行很关键——它保证Vue Router的history模式在刷新页面时不会404。之前有个学生部署完发现从首页点进详情页没问题但直接刷新详情页就404就是因为没加这一行他的Vue路由用的是history模式刷新时浏览器直接请求服务器路径服务器找不到对应文件就404了。微调之后重新加载Nginx配置nginx -s reload整个系统从浏览器输入域名就可以访问了。5.3 上线前的数据初始化部署完成后还有一步容易忽略初始化基础数据。比如管理员账号、资源分类、默认配置。项目中提供了一个schema.sql和一个data.sql分别建表和插入初始化数据。用Navicat执行一遍就行。一个实用建议在data.sql里把管理员账号密码提前写好密码用BCrypt加密后的结果存进去。这样可以保证首次登录就能用管理员账号进入系统不用再去数据库里手动改密码。初始化数据的同时建议顺便核对一下MySQL时区设置是否用的SYSTEM如果不是插入的时间字段可能和实际差8个小时。这个问题的解法是在MySQL连接串上显式加上serverTimezoneAsia/Shanghai。6. 核心问题排查技巧与实战心得6.1 排查思路日志、接口、数据三步定位项目出问题后我的排查顺序基本是固定的第一步看日志。后端日志文件里有没有异常堆栈前端浏览器控制台有没有报错网络请求的状态码是多少。第二步调接口。用Postman或Swagger直接调用出问题的接口确认问题在前端还是后端。这一步能排除大量“看起来是后端问题实际是前端没传对参数”的乌龙。第三步查数据。数据库里数据记录的状态和内容是怎样的是压根没写进去还是写进去了但查不出来。这套“日志—接口—数据”三步法90%的系统性问题都能定位。剩下的10%基本是环境差异、缓存、并发这类硬骨头把问题现象完整记录下来带着日志去找答案比瞎猜有效得多。6.2 资源数据错乱和脏数据预防上线初期最容易出现的另一类问题是因为用户反复操作产生的脏数据。比如取消收藏但记录没删干净用户删除资源但文件没同步删除审核驳回但资源状态没及时回退。解决思路有两个方向一是数据库层加必要的唯一约束和外键关系二是在Service层写业务逻辑时多做“幂等检查”——比如收藏操作插入前先查一下是否已经收藏过避免出现同一个用户对同一个资源插入多条收藏记录。幂等性这个概念听起来高大上其实就是“同一个操作重复执行多次结果都一样”写接口时多想一步就能避免很多数据问题。6.3 性能优化从SQL到Redis的提升路径资源管理系统在初期几百个用户、几千条资源的情况下性能其实不构成瓶颈。但聊到优化方向面试中这是必考点。大致的优化路径是SQL索引优化。给resource_info表的category_id、status、create_time字段加上普通索引查询效率提升非常明显。最基础但最有效。减少无效查询。热门分类下资源的搜索和列表接口能合并的查询就合并避免在一个循环里反复调数据库。引入Redis做缓存。把热点分类树、系统配置、用户会话缓存到Redis里。资源详细内容这类低频变化数据也可以做30秒短缓存。但不要无脑把所有接口都加缓存——资源列表被人改了就更新缓存这种一致性维护成本往往比缓存收益更高。文件存储替换。当文件越来越大本地磁盘不够用时会自然想到把资源文件迁移到对象存储比如MinIO或者云服务商的对象存储。这个渐进式演进方式比一上来就上全套分布式架构要务实得多。6.4 面试中如何把这个项目讲出亮点拿这个项目去面试时最大的误区是上来就背功能清单“我们这个系统有登录、上传、下载、审核、评论……”面试官听这种话已经听了上千遍了毫无记忆点。正确的方式是以方案取舍和问题解决为主线比如“登录这块我为什么用JWT而不是Session因为前后端分离下Session有跨域和扩展性问题JWT无状态更适合这种场景。”“审核状态我为什么用状态码而不是布尔字段因为资源有草稿、待审核、已上架、已驳回多个状态布尔表达不了。”“上传文件时我遇到过事务失效的问题排查后确认是因为方法没走Spring代理从那之后凡是多表写操作我都检查一遍事务配置。”“分页查询在JOIN的时候count不准我把它改成了手写count准确性和性能都更好。”这些问题一旦聊起来面试官自然能从“这个项目是不是你做的”过渡到“这个人的技术判断力怎么样”这才是项目经验真正值钱的地方。7. 个人实操后的三个建议项目完全跑通之后我个人最深的感触有三点。第一点遇到问题不要先怀疑框架先怀疑自己的使用方式。很多看起来是SpringBoot、MyBatis的“bug”最后查出来都是配置文件写错、注解漏加、路径不对这类低级问题。把日志看仔细、把请求链路理清楚绝大多数问题都能自己解决。第二点源码阅读很重要尤其是你能改的源码。这个项目拿到后建议不要只跑起来看一眼至少把pom.xml里关键的依赖关系理一遍把自己的代码从头到尾读一遍。能讲清楚“为什么这么写”才敢说这个项目算你的。我建议可以先改一个小功能比如把密码加密从MD5升到BCrypt或者给查询列表加上排序功能从“能跑”进步到“能改”是走向“能设计”的第一步。第三点扩展的方向想清楚再动手。如果你想让这个项目看起来更有竞争力可以考虑往下面几个方向扩展一是用MinIO替换本地存储二是用Redis加缓存三是用ElasticSearch做全文检索四是给教师端加数据可视化看板统计资源下载趋势。这些方向每一个单拆开都能成为面试时深入聊的点也比堆砌多个小功能更聚焦。但别一次全加挑一个方向做深做透收获会更大。
