实验室教学资源这块，不少高校和培训机构还在用最原始的方式管——纸质登记册、Excel表格、微信群接龙预约。每逢学期末设备盘点，管理员对着账本一个个核对，稍微马虎点就得出错。而学生想预约一间实验室、借一台仪器，得先打听负责老师在不在办公室，跑好几趟才能把事办成。这种模式下，资源利用率低、流程繁琐、数据没法沉淀，换谁管都头疼。
我当时接到这个题目，第一反应就是做一个前后端分离的实验室教学资源管理系统。技术栈没什么好纠结的，SpringBoot加Vue这对组合在当前Java生态里属于最主流、最成熟的搭配，网上资料多，遇到问题也好搜。系统核心要解决的问题也很明确：把实验室信息、设备台账、预约申请、审批流程、附件资料全部线上化，让管理员能管、老师能审、学生能约，整个链路走通，就不再依赖线下沟通。
这篇文章我按实际开发的顺序来写，从需求拆解、技术选型、数据库设计，到后端接口实现、前端页面落地，再到部署过程中容易踩的坑，完整过一遍。如果你正在做类似的毕设项目，或者刚接触前后端分离开发想找个完整案例练手，这篇内容应该能帮你省下不少弯路。
1. 整体设计与技术选型思路
1.1 实验室资源管理到底要管什么
做系统之前先别急着写代码，得先搞清楚业务域里到底有哪些角色、哪些流程。实验室教学资源管理系统，核心参与方无非三类人：系统管理员、实验室负责老师（或者叫审批人）、普通学生用户。
围着这三类角色转一圈，业务需求就很清晰了。管理员要维护实验室基础信息、管理设备台账、给不同角色分配权限、查看整个系统的使用数据。老师要发布实验室开放时间、设置可预约时段、处理学生的预约申请、上传或关联教学资源文件。学生要浏览实验室状态、查看设备可用情况、发起预约、上传自己的实验材料、查看审批结果。
功能模块拆下来大致就是这些：用户与权限管理、实验室管理、设备管理、预约管理、公告通知、教学资源附件管理、统计看板。每个模块都不算复杂，但合在一起就是一个完整的小型业务系统，该有的前后端交互、权限控制、文件处理、状态流转全都会涉及。
1.2 为什么选SpringBoot加Vue这对组合
技术选型这块我几乎没有纠结。后端用SpringBoot，因为它简化了大量配置，内嵌Tomcat，打个jar包就能跑，非常适合这种中小型管理系统的快速交付。Spring生态里现成的组件也足够丰富，MyBatis-Plus操作数据库、Spring Security或者JWT做鉴权、Spring Validation做参数校验，一套下来开发效率很高。
前端选Vue，主要是看重它的渐进式设计。Vue的组件化开发能让页面结构非常清晰，路由、状态管理、UI组件库都有成熟的配套方案。配合Element Plus这套组件库，后台管理界面的开发速度非常快，表格、表单、弹窗、分页这些高频组件开箱即用，不用自己从头手写。
前后端分离还有一个隐形的优势——并行开发。前端写页面的时候只需要和后端对好接口文档，后端专心出接口，两边互不阻塞。后面要扩展移动端或者嵌到别的系统里，前端代码也基本不用大动。
1.3 项目整体架构分层
系统的架构分层我保持了比较经典的三层结构。前端是标准的Vue工程，负责页面渲染、用户交互、路由跳转、状态管理，通过Axios发请求调后端接口。后端按Controller、Service、Mapper三层划分，Controller只做参数接收和结果返回，Service层承载业务逻辑，Mapper层负责和数据库打交道。数据库用的MySQL，文件存储本地目录就够了，小项目没必要上MinIO或者OSS，除非你有明确的多服务器需求。
注意：如果你想把项目做得更有亮点，可以考虑把文件存储换成MinIO，答辩的时候能多聊几句分布式存储的话题。但如果是图省事，本地存储完全够用，别给自己加戏。
2. 数据库设计与核心表结构
2.1 需求驱动的持久层设计
数据库设计是整个系统的地基，地基没打好后面全是坑。我的习惯是先把业务场景里的名词和关系列出来，再转成表结构。
系统里有几个核心实体：用户、实验室、设备、预约记录、附件文件。实体之间的关系用大白话说就是：一个用户（管理员或老师）可以维护多个实验室，一个实验室可以拥有多台设备，一个用户（学生）可以发起的多个预约申请，一个预约申请可能关联多条附件记录。
把这层关系理清楚，建表就水到渠成。这里强调一点——表设计一定要预留扩展字段，比如状态字段不要写死成0和1，尽量用可读性更好的字符串或者枚举值，后面业务调整的时候能少改很多代码。
2.2 五张核心表的字段设计
用户表（sys_user）主要字段：id、username、password、real_name、role（ADMIN/TEACHER/STUDENT）、phone、email、status、create_time。密码存储必须加密，我用的BCrypt，这个后面细说。
实验室表（lab）主要字段：id、lab_name、lab_location、lab_type（计算机/电子/化学等）、capacity、open_time、close_time、status（开放/维护中/关闭）、description、cover_image、create_time、update_time。这里的开放时间要用字符串还是时间范围类型要提前想清楚，我是用两个时间字段加一个周几可用字段组合处理的，灵活度更高。
设备表（equipment）主要字段：id、lab_id、equip_name、equip_model、equip_sn、purchase_date、status（正常/维修/报废）、description。设备挂在实验室下面，一对多的关系用lab_id关联。
预约记录表（reservation）是业务核心，设计时要特别用心。主要字段：id、user_id、lab_id、reserve_date、start_time、end_time、purpose、status（待审核/已通过/已拒绝/已取消）、audit_user_id、audit_remark、audit_time、create_time。这张表一定要加联合索引，查询高频场景就是根据日期和实验室查冲突记录。
附件表（attachment）主要字段：id、biz_type（实验报告/实验图片/设备手册等）、biz_id、file_name、file_path、file_size、upload_user_id、create_time。用biz_type加biz_id做成通用附件表，不管是预约申请、设备维修还是公告通知，哪种业务绑附件都能复用一张表。
2.3 关键索引与扩展点
预约记录表是查询压力最大的表，字段设计上我特意做了冗余——同时存user_id和lab_id，方便按人查也方便按实验室查。索引方面，联合索引（reserve_date, start_time, end_time）基本能覆盖冲突检测的查询场景，实测数据量不大的时候性能完全没问题。
逻辑删除这个习惯我一直保持，表里加一个deleted字段，默认值为0。这样数据误删了还能找回来，答辩的时候也算一个亮点，体现你对数据安全有考虑。但是要注意，所有查询都要带上deleted = 0的条件，否则会查出脏数据。
3. 后端核心实现（SpringBoot）
3.1 项目初始化和工程目录
创建SpringBoot项目可以用Spring Initializr，也可以用IDEA自带的向导。Java版本我选的JDK 8，不是越新越好，考虑到很多学校机房和老项目的兼容性，8是稳妥的选择。SpringBoot版本用的2.7.18，这是2.x系列最后一个稳定版本，坑最少。
工程目录按功能分包，而不是按技术分层分包，这样结构更清晰：
com.example.labresource ├── common -- 通用类：返回结果、异常处理、常量 ├── config -- 配置类：跨域、拦截器、文件上传 ├── controller -- 接口层 ├── entity -- 实体类 ├── mapper -- 数据访问层 ├── service -- 业务层 └── utils -- 工具类：JWT、日期处理等3.2 统一返回体和全局异常处理
前后端分离的项目，接口返回格式一定要统一。我定义了一个Result类，结构就是code、message、data三段式。code为200表示成功，401表示未登录或token失效，500表示业务异常，其他业务错误码可以按需扩展，比如40001表示预约冲突。
public class Result<T> { private Integer code; private String message; private T data; // 省略构造方法、getter/setter public static <T> Result<T> success(T data) { return new Result<>(200, "操作成功", data); } public static <T> Result<T> error(Integer code, String message) { return new Result<>(code, message, null); } }配合全局异常处理器，用@RestControllerAdvice拦截所有异常。业务异常统一抛BizException，系统异常统一走全局兜底，前端拿到的永远是结构一致的JSON，处理起来非常省心。这一套写完之后，后面所有接口都只需要关注正常逻辑，异常处理一点不用重复写。
3.3 JWT登录鉴权实现
登录鉴权我用的是JWT加拦截器的方式。用户登录成功后，后端生成一个token，token里带上用户id和角色信息，然后返回给前端。前端每次请求都在Header里带这个token，后端拦截器校验通过才放行。
// 登录成功后生成token String token = Jwts.builder() .setSubject(user.getId().toString()) .claim("role", user.getRole()) .claim("username", user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();拦截器里做的事也很简单，检查Header里的Authorization字段是否存在，解析token是否有效，然后把用户信息放到ThreadLocal里，方便后面的业务代码随时取当前登录用户。这里有一个细节要注意——放行路径要配置好，登录接口、静态资源、文件预览这些不需要鉴权的接口要排除掉，不然前端还没登录就直接被拦死了。
3.4 文件上传功能的实现
实验室教学资源系统里很常见的一个功能是上传实验图片、设备手册或者实验报告附件。SpringBoot内置的文件上传机制够用，但有几个点必须处理。第一，上传大小限制。SpringBoot默认上传单个文件最大1MB，这显然不够用，要在配置里放宽：
spring.servlet.multipart.max-file-size=20MB spring.servlet.multipart.max-request-size=50MB第二个点是文件存储路径和访问方式。我是把文件存到服务器本地指定目录，然后通过一个映射把虚拟路径映射到真实目录，这样前端可以通过URL直接访问文件，不用再走接口下载。
第三个点是文件重名问题，用户上传的文件名千奇百怪，直接存原名容易冲突，我用UUID重命名然后保留原始文件名存入数据库，同时把原始文件名记录下来，下载的时候用原始名返回给用户，体验和安全性都比较好。
// 文件上传核心逻辑 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + ext; File savePath = new File(baseDir + "/" + newFileName); file.transferTo(savePath); // 文件信息写入attachment表3.5 预约冲突检测的算法思路
预约功能是系统的重头戏，核心逻辑就是要避免同一间实验室在同一个时间段被重复预约。实现思路其实不复杂，插入新预约之前，查一下数据库中是否存在时间重叠的已通过记录。
判断重叠的条件就是：新预约的开始时间小于已有预约的结束时间，且新预约的结束时间大于已有预约的开始时间。这个逻辑两句话就说清楚了，但写SQL的时候要记得把状态为“已通过”的记录考虑进去，待审核的记录也要处理——我当时的做法是待审核的记录也占坑，避免两个学生同时申请同一时间段导致管理员两边为难。
SELECT COUNT(*) FROM reservation WHERE lab_id = #{labId} AND reserve_date = #{reserveDate} AND status IN ('已通过', '待审核') AND deleted = 0 AND start_time < #{endTime} AND end_time > #{startTime}如果查询结果大于0，直接返回“该时间段已被预约”的业务异常。这里建议用数据库层面再加一个唯一约束或者使用悲观锁/乐观锁来控制并发，简单点的方案就是预约方法上加个分布式锁的雏形，比如根据labId加字符串锁，保证同一实验室的预约操作是串行的。
4. 前端Vue实现与交互流程
4.1 Vue工程初始化和依赖安装
前端项目我用Vue CLI创建，Vue版本用的2.6，配合Element UI。现在Vue 3加Element Plus也成熟了，但考虑到很多人的毕设环境还在沿用2.x的资料，这个版本组合更稳妥。创建命令很简单：
vue create lab-resource-front # 选择Router + Vuex + Axios npm install element-ui npm install npm run serve安装依赖的时候容易踩坑，npm源在国内速度很慢，建议先设置淘宝镜像源：
npm config set registry https://registry.npmmirror.com4.2 项目目录和路由配置
前端目录结构按页面功能划分，views下面每个模块建一个目录，每个目录里面放index.vue和子组件。路由表里配置好每个页面路径和对应组件，菜单栏的数据源也是从路由表里抽出来的，这样菜单和路由天然保持一致。
{ path: '/reservation', name: 'Reservation', component: () => import('@/views/reservation/index.vue'), meta: { title: '预约管理', icon: 'calendar' } }路由懒加载一定记得用，组件用import动态引入，这样首屏加载速度会明显提升，不用在初始化的时候把所有页面都加载一遍。
4.3 Axios封装和Token管理
前端调用后端接口，axios实例需要做统一封装。把baseURL设为后端接口地址，request拦截器里从本地存储拿token放进Header，response拦截器里统一处理返回状态——code为200直接返回data，code为401跳登录页，其他错误弹Message提示。
service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res.data } else { Message.error(res.message) return Promise.reject(new Error(res.message)) } }, error => { // 401处理，清除token并跳登录页 } )这样封装完之后，业务代码里写请求就非常清爽，只要关心成功拿到的数据，错误处理全部走拦截器，页面代码里不会到处都是try-catch。
4.4 核心页面功能落地
预约页面是学生用得最多的。页面上方是查询条件区域，可以选择实验室类型、日期范围，点击查询后表格刷新。表格里展示每个时间段的状态，可用就显示“预约”按钮，已经被约就置灰。点击预约弹出对话框，填写实验目的和备注，提交后列表刷新状态变“待审核”。
实验室管理页面是管理员和老师共用的。这里我用了Tab切换，一个Tab展示列表，一个Tab展示统计图。列表和表单的联动用Dialog加Form表单实现，编辑和新增共用同一个组件，通过传入的id区分是修改还是添加。
设备管理页和实验室管理页结构类似，但要额外支持设备状态流转。设备报修的逻辑是学生发现在线状态不对，点击报修按钮，状态变成维修中，管理员处理后改回正常，整个流程在列表里用Tag组件直观展示状态颜色。
5. 实操全流程：从登录到预约的资源闭环
5.1 学生视角的完整操作链
整个系统跑通之后，学生的使用路径是这样的：浏览器打开系统，输入账号密码登录，进入首页看到最近公告和我的预约状态。点进实验室列表，筛选材料化学实验室，看到本周的开放时间表，周三下午两点到四点还空着，点击预约，填写实验内容“催化剂制备与性能测试”，上传预习报告附件，提交。此时列表里这条记录的状态变成“待审核”，学生端就完事了。
接下来老师或者管理员登录后台，在待办列表里看到这条申请，点击查看详情，Approve或拒绝。状态流转后，学生的预约列表自动刷新出结果。如果通过了，学生到时候直接在预约时间来实验室，管理员在后台可以看到当前时间正被使用中的实验室列表。
5.2 管理员的资源维护操作
管理员的日常操作集中在系统管理模块。新增一个实验室，填写名称、位置、类型、容量、开放时间，上传实验室照片，保存后学生端立刻就能看到。设备管理里给某个实验室添加设备，填写设备编号、型号、购买日期，设备出现在资产列表里。学生提交的预约申请都集中在审核菜单下，支持批量通过和批量拒绝，还能导出本周预约报表为Excel。
数据统计这块我用ECharts做了个简单的看板，展示实验室利用率Top5、设备使用频率、每周预约趋势。虽然逻辑只是聚合查询加图表展示，但效果很加分，演示的时候观感非常直观。
5.3 前后端联调的关键时间点
开发过程中一定要提前定好联调时间点。我们当时的节奏是后端先跑通登录和数据字典接口，前端同步搭好登录页和首页框架，大概三四天之后开始联调登录流程。登录通了之后，后续的功能联调就是按模块来走，每次后端给接口，前端对接，半天到一天就能跑通一个模块。不要攒到最后再联调，不然后端修bug和前端等接口的时间会非常痛苦。
6. 常见问题与排查技巧实录
6.1 跨域问题
前端跑在8080端口，后端跑在8081端口，前后端分离必然遇到跨域。最简单的方案是后端起一个WebMvcConfigurer的配置类，重写addCorsMappings方法：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }顺便说一句，如果你的后端接口用了拦截器做登录校验，前端跨域请求会先发一个OPTIONS预检请求，这个请求不带token，拦截器如果不能正确放行OPTIONS请求，前端就会莫名其妙报跨域错误。解决方式是在拦截器里加一行判断，如果是OPTIONS请求直接放行。
6.2 文件上传大小超限
前端上传到一半报“Maximum upload size exceeded”是很常见的坑。这个问题除了改后端配置之外，前端也要注意——axios请求上传文件的时候要设置Content-Type为multipart/form-data，然后在axios实例里不手动设置Content-Type，让浏览器自己带上boundary边界，否则后端文件解析会出错。如果前端框架里用了qs序列化，默认会转成urlencoded格式，这也同样会干扰文件流传输。
6.3 MyBatis-Plus分页插件
列表查询用MyBatis-Plus内置的分页插件非常方便，但很多人在配置上少了一步——必须注册分页拦截器：
@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }不注册这个拦截器的话，调selectPage方法虽然不报错，但返回的分页数据全是错的，total永远是0，page永远是1。还有一个细节是当条件查询传了空字符串时，MyBatis-Plus默认会把空字符串当作有效条件，导致查不出来数据，建议在写SQL的时候对外层查询条件做空值处理。
6.4 Vue路由刷新后404问题
前端部署到服务器，刷新页面的时候如果tomcat或者nginx没有做相应配置，会出现404。这是因为前端路由是history模式，刷新时浏览器直接请求了后端的某个URL路径，但后端没有对应路由。解决方法是在部署nginx时配置try_files：
location / { try_files $uri $uri/ /index.html; }如果你非要用hash模式路由，那URL里会带个#号，丑是丑一点，但确实不会遇到刷新404的问题。开发环境Vue CLI的devServer默认就已经做了historyApiFallback，所以开发时完全感觉不到这个问题，上线才暴露。
6.5 时间字段时区问题
数据库里存的时间比实际时间晚了8小时，这是Java后端传Date类型到前端常见的时区问题。MySQL驱动连接串里加上serverTimezone=Asia/Shanghai能解决大部分情况，另外就是后端接口返回时间时统一转成字符串格式化，时间类型不直接暴露给前端。我在实际项目中是封装了一个日期工具，Entity里用LocalDateTime，返回给前端前统一转成yyyy-MM-dd HH:mm:ss的字符串格式，干脆利落。
我的习惯是前后端传时间都用字符串而不是时间戳，虽然多写一点转换代码，但排除了大部分时区隐性问题。这个问题在演示现场翻车概率极高，千万别人为制造惊喜。
6.6 部署时的一个小提醒
项目打包部署时，后端用mvn clean package打jar包，前端npm run build生成dist目录。如果前后端要部署到同一个环境，可以用Nginx把前端的dist目录作为静态资源，然后通过反向代理把/api前缀的请求转发到后端的8081端口。这样对外只需暴露一个端口，配置一次Nginx就搞定，而且浏览器里不会出现跨域问题，因为前后端在同一个origin下。
我最后分享一个小细节——上线前务必把SpringBoot的日志级别调整到合理位置，开发时可以是DEBUG，生产环境用INFO就够，不然日志文件增长非常快，磁盘满了服务直接瘫掉。另外别忘了给MySQL数据库做定时备份，系统上线后数据就是资产，丢了可真找不回来。
做这类管理系统的经验，跟写一个Demo完全是两个量级的事情。Demo只需要功能能跑，而管理系统要考虑权限怎么控制、状态怎么流转、失败路径怎么兜底，还要兼顾使用体验。用SpringBoot加Vue这套组合做下来的体会是，主流技术栈能覆盖市面上绝大部分管理系统场景，遇到问题靠搜索引擎就能解决一大半，剩下的就需要你在实际开发中多动手验证，把那些文档里不会写出来的细节都沉淀成自己的经验。这套模式跑通之后，再换个领域做一套类似的系统只是时间问题。
