做毕设选型那阵子，我在SpringCloud和SpringBoot之间反复纠结过很久，最后选了SpringBoot+Vue这套组合来做“光影管理平台”。原因很直接：这是目前招聘市场认可度最高、学习资料最全、踩坑成本最低的一套前后端分离方案，而且Java+MySQL的搭配足够应付大多数高校的毕设和课设要求，无论是从工作量、创新点还是演示效果来看，都处于一个很舒服的位置。
这个项目最终做成了一个围绕“光影展示场景”的综合管理平台，涵盖作品信息维护、设备状态管理、展场排期、预约审核、数据统计等模块。如果你是计算机相关专业的学生，正在为毕设选题发愁，或者想找一套结构清晰、能跑通完整业务闭环的代码来学习前后端交互，这套东西可以给你一个很扎实的参考底座。整套代码虽然不算复杂，但麻雀虽小五脏俱全，从用户登录鉴权到后端接口设计，再到前端动态路由，基本把企业级开发里最常见的那套玩法都串起来了。
1. 光影管理平台到底做什么：需求拆解与业务定位
1.1 从一个“灯光控制室里的乱象”说起
这个项目的业务灵感来源于某次参观一个光影艺术展的体验。当时后台的工作人员在调度不同展区的灯光设备时，靠的是一张Excel表格和微信群里的语音沟通，哪个作品几点开灯、哪套投影设备该维护了、哪场预约和展区排期冲突了，全靠人工判断。这种场景天然适合用一套Web管理系统来解决：设备信息上线、预约流程标准化、排期冲突自动提示、数据可视化展示，这些都是“光影管理平台”的核心价值点。
我把这个业务提炼成了三个核心模块：资源管理（作品、场地、设备）、流程管理（场次排期、预约登记、审核）、数据管理（观众统计、设备使用率、作品热度）。这三个模块基本覆盖了一个管理类系统的标准范式，也是毕设答辩时比较好讲故事的切入点。尤其推荐你在论文里把“业务痛点到功能模块的映射”这个思路写清楚，这比单纯堆功能列表要高级得多。
1.2 为什么非要搞成前后端分离
很多同学问：毕设用传统的JSP+Servlet不行吗？也不是不行，但你得明白毕设的核心目的不是“完成”，而是“展示能力”。前后端分离意味着你可以很自然地讲出“RESTful API设计”“跨域处理”“Token鉴权”“异步渲染”这些关键词，这些恰好是目前企业里的主流做法。
SpringBoot负责提供后端接口，Vue负责页面交互和渲染，两者通过JSON格式的数据进行通信。这种架构下的好处是：前端开发和后端开发可以并行推进，你只需要提前把接口文档约定好。即便你是单兵作战，这种分离也能让你的代码结构更清晰，改页面不用动Java代码，调接口不用翻HTML。
1.3 技术选型的三点考量
选SpringBoot不是因为它新，而是因为它稳。SpringBoot极大简化了Spring的配置流程，内置Tomcat，打jar包就能跑，这对毕设这种“需要在答辩现场快速演示”的场景太重要了。Vue则胜在轻量，单页应用的体验好，而且它的响应式数据绑定让表单类页面的开发效率翻倍。MySQL更不用多说，开源免费，网上教程铺天盖地，Navicat连上就能看表结构，排查数据问题非常方便。
2. 整体架构设计与数据库建模
2.1 前后端分离下的项目结构
后端我用的是标准的Controller-Service-Mapper三层架构：
src/main/java ├── controller // 接收前端请求，返回JSON ├── service // 业务逻辑处理层 ├── mapper // MyBatis数据访问层，对应Mapper.xml ├── entity // 数据库表对应的实体类 ├── dto // 前端交互的数据传输对象 ├── config // 配置类，跨域、拦截器等 ├── utils // 工具类，JWT生成解析、MD5加密等前端Vue项目则按“视图-组件-工具”划分：
src ├── api // axios请求封装，按模块拆分 ├── views // 页面级组件，如Login.vue、Dashboard.vue ├── router // 路由配置，含动态路由和守卫 ├── store // Vuex状态管理，存用户信息、权限标识 ├── components // 可复用子组件，如表格封装、上传组件 ├── utils // request.js请求拦截器等这套结构放到“项目结构说明”那一章去写论文，光是目录解释就能写出两千字来，而且全是干货。
2.2 数据库到底建几张表才合适
我最终设计成7张核心表：用户表、角色表、作品表、场地表、设备表、排期表、预约表。加上用户和角色的关联表、角色和权限的关联表，总共9张左右。这个规模既不会让数据库设计显得单薄，又不至于把自己陷入到建表、改表、写CRUD的无底洞里去。
以排期表为例，字段设计如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| work_id | bigint | 关联作品ID |
| venue_id | bigint | 关联场地ID |
| start_time | datetime | 场次开始时间 |
| end_time | datetime | 场次结束时间 |
| status | tinyint | 状态：1待开始 2进行中 3已结束 4已取消 |
| operator | varchar | 操作人 |
| create_time | datetime | 创建时间 |
排期表是光影管理平台里业务逻辑最复杂的表，因为它牵扯到“场地冲突检测”：同一个时间段不能安排两个不同场次。这个逻辑如果在数据库层面靠外键和约束去实现会很别扭，所以我在Service层实现了一个“时间重叠校验”——查询同一场地、时间范围相交的记录数，只要大于零就提示冲突。为了不影响查询性能，我给venue_id和start_time建了联合索引。
2.3 用户权限这块怎么处理
平台里分了两类角色：管理员和普通观众。你不能让观众登录后跑到设备管理页面去乱点，所以后端的接口必须做鉴权。我采用的是JWT方案，登录成功后后端返回一个Token，前端存在localStorage里，每次发请求时在请求头带上。后端用拦截器统一校验Token，再从Token里解析出用户角色，做接口级别的权限控制。
JWT的核心代码很简单，生成Token时把用户ID和角色塞进去：
String token = Jwts.builder() .setSubject(user.getUsername()) .claim("role", user.getRole()) .claim("userId", user.getId()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 2)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();到拦截器里再解析出来放ThreadLocal里，后续Controller里直接取当前登录用户就能用。这里有几个细节要注意：secretKey不要写死在代码里，放到配置文件；过期时间设置成2小时比较合理，别设太长也别太短，太长不安全，太短用户老要重新登录。
3. 核心功能模块的实操落地与代码解读
3.1 登录认证模块：从Form表单到JWT鉴权
登录页的核心交互大概是这样的：用户输入账号密码，前端axios发POST请求到/api/auth/login，后端根据用户名查出用户记录，比对MD5加密后的密码。验证通过就生成Token返回，同时返回用户的基本信息包括角色、昵称、头像。
密码加密我选了MD5加盐的方式，没用BCrypt是因为很多初学同学对盐值的理解容易绕晕。加盐的逻辑是：注册时把固定的字符串拼到密码后面再做MD5，数据库中存的是“盐+密码”的哈希结果。虽然从安全角度BCrypt更优，但对于课程设计级别的项目，MD5加盐已经足够展示你的加密意识。
前端这边的代码要不要贴？我建议贴，因为登录到Dashboard的流程是答辩时必演示的环节。关键是前端路由守卫的处理：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (!token && to.path !== '/login') { next({ path: '/login' }) } else { next() } })这段代码的作用是：没登录就跳转登录页，登录了才能访问其他页面。如果再配合Vuex里的用户信息来做动态路由渲染，比如管理员能看到“用户管理”菜单而观众看不到，那这个项目的“深度”就瞬间立起来了。
3.2 排期管理模块：业务最重的部分
排期管理是光影管理平台的核心业务。当你创建一个新场次时，后端要做三件事：校验作品是否存在且状态正常；校验场地是否存在；校验该场地在当前时间段有没有被其他场次占用。
冲突检测的SQL大概长这样：
<select id="selectConflictingSchedule" resultType="java.lang.Integer"> SELECT COUNT(*) FROM schedule WHERE venue_id = #{venueId} AND status IN (1, 2) AND ( (start_time <= #{startTime} AND end_time > #{startTime}) OR (start_time < #{endTime} AND end_time >= #{endTime}) ) </select>这里一开始比较容易犯的一个错误是只判断了start_time < 新结束时间 AND end_time > 新开始时间，但如果边界正好相等，就漏判了。我加了等号处理，把四种重叠情况全部覆盖到：包含、被包含、左交、右交。你在测试时一定要构造这四种边界数据，不然答辩时老师随便点个边界就能把你问住。
排期列表在页面上我用的是一个时间线组件，左边是场地列表，右边是不同时间段的可视化色块，绿色表示可用，红色表示已被占用。这个可视化效果不需要很高深的Canvas技术，纯Vue的CSS绝对定位加浮动宽度就能实现，但视觉冲击力很强，演示时很出彩。
3.3 数据可视化模块：让答辩PPT活起来
如果只是CRUD，这个平台显得有点平。所以我在首页的Dashboard中嵌入了几个ECharts图表：作品热度Top10的柱状图、每周观众流量曲线图、场地使用率的饼图。这些图表的数据全部从后端接口实时获取，前端用axios调接口拿数据后，动态设置ECharts的option。
后端统计接口的实现，还是绕不开GROUP BY和日期函数的运用。比如统计每周的观众访问量，SQL可以这样写：
SELECT DATE_FORMAT(visit_time, '%Y-%u') AS week, COUNT(*) AS visit_count FROM visit_record GROUP BY week ORDER BY week用DATE_FORMAT可以方便地把时间粒度归拢到周，前端拿到数据后直接按顺序填充X轴。展示这些图表时，答辩老师直观上会觉得这个系统“有数据支撑”，而不是一个空壳子。从论文的角度，这一块也可以对应“系统测试与数据分析”的章节，一鱼两吃。
3.4 文件上传与静态资源映射
做光影管理平台，作品展示图是必不可少的，这就涉及到图片上传功能。后端的实现方案是：Vue前端用el-upload组件，走FormData格式把文件POST到/api/file/upload，后端用MultipartFile接收，写入服务器本地磁盘目录，然后返回一个URL给前端，数据库里只存这个URL字符串。
这里有个必踩的坑：SpringBoot默认不会把磁盘上的图片目录映射成可访问的静态资源，如果你按路径访问图片会出现404。解决方法是添加一个WebMvcConfigurer配置类：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { String filePath = ResourceUtils.getURL("classpath:static").getPath(); registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + filePath); }另外注意文件大小限制，SpringBoot默认上传文件最大1MB，你要在application.yml里调大：
spring: servlet: multipart: max-file-size: 20MB max-request-size: 100MB不调这个配置的话，前端传一张大图直接报错，你会莫名其妙怀疑是不是网络问题，其实只是配置在作祟。
4. 联调避坑：跨域、时间、接口文档这三大杀手
4.1 跨域问题：为什么前端调不通后端
前后端分离项目第一个遇到的拦路虎就是跨域。你在Vue开发服务器上跑在8080端口，后端SpringBoot跑在8082端口，浏览器默认策略会把这种跨端口的请求给拦下来。解决方案有三种：后端加@CrossOrigin注解、写全局CORS配置类、或者用Nginx做反向代理。毕设阶段我推荐用全局CORS配置，一次性解决问题，避免每个Controller上都加注解：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(Registry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:8080") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true); } }如果你用了JWT并在前端request.js里的withCredentials=true，切记CORS的allowedOrigins不能写成*，必须写具体域名，否则浏览器还是会拦截。这个细节坑了我很长时间，查了很多资料才发现是这个credentials和通配符的冲突问题。
4.2 时间的时区陷阱与格式化问题
MySQL的datetime类型和数据库连接的时区设置如果不一致，会出现“后端写入的时间比北京时间少8小时”这种灵异事件。在JDBC连接串里必须加上serverTimezone=Asia/Shanghai：
url: jdbc:mysql://localhost:3306/light_manage ?useUnicode=true&characterEncoding=utf8 &serverTimezone=Asia/Shanghai&useSSL=false此外，后端返回给前端的时间格式也需要统一。如果你直接用Java的LocalDateTime返回，前端拿到的可能是2024-06-15T20:30:00这种带T的格式，很不美观。我建议在后端做一个全局的Jackson配置，统一格式化：
@Bean public Jackson2ObjectMapperBuilderCustomizer jsonCustomizer() { return builder -> { builder.serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); builder.deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"))); }; }4.3 接口文档别偷懒：Apifox比Swagger更适合学生
很多同学用Swagger生成接口文档，但Swagger的页面相对老旧，而且侵入性比较强。我后来换用Apifox做接口管理和调试，好处是可以在一个工具里把后端的接口全部导入并进行联调测试，前端同学们看文档也直观。如果你的项目需要写“接口设计说明”这类章节，直接截图Apifox里的接口列表就行，清晰度比手画表格高出不少。
4.4 MyBatis的几大经典报错及排查套路
写Mapper.xml时最崩溃的问题是“Invalid bound statement (not found)”。造成这个问题的原因大概有三种：接口和XML文件的namespace没写对；XML文件没有放在Mapper接口对应的目录下；或者在application.yml里没配置mapper-locations扫描路径。排查套路是：先看编译后的target目录里有没有XML文件，如果没有就说明是resources打包问题，在pom.xml里加上：
<resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources>还有个经常遇到的坑是传多个参数时，只用@Param("xxx")做映射，但XML里忘记在参数名前面加#{xxx}。调试这个报错时，最简单的办法是把SQL复制到Navicat里跑一遍，把手动拼接的参数放进去，看是不是SQL本身的问题。如果SQL没问题，那八成就是参数映射的事。
4.5 Vue端的几个常见卡点
Vue中比较常见的bug包括：axios的响应拦截器没写，导致后端返回401错误时页面没有统一跳转到登录页。表格数据渲染不出来，报错却是Cannot read properties of undefined，这个问题通常在接口返回的数据结构里多了或少了一层。比如后端返回{data: {list: []}}，你前端写成了res.data.list，但实际res已经是你拦截器里返回的response body，再读一层data就读到了undefined。
解决方法也很简单：在request.js里拦截到响应时，直接返回response.data，这样业务代码里就能统一从res.data里取数据。这个约定一定要在前后端接口文档里写清楚，不然两个人各自按自己的习惯理解，联调时就会“你说返回了list，我说没看见”。
5. 学习使用指南：这套源码的正确打开方式
5.1 三种用途，三种玩法
如果拿这套代码来做毕设，建议你不要把重心放在“再多加一个功能”上，而是把已有的主链路吃透：用户登录拿Token，带Token访问受保护接口，管理员创建排期，系统检测冲突，观众提交预约，管理员审核，前端展示数据图表。只要你能对着代码把这条链路完整讲清楚，答辩已经成功了大半。
如果拿来做课设，建议适当做减法：把数据可视化模块去掉了，改成简单的列表页加表单提交，就行。不需要为了撑工作量硬塞一堆半成品功能，反而让代码变得臃肿，答辩时自己都讲不明白。
如果拿来做学习，那你应该重点关注这几块代码：JWT拦截器的实现、时间冲突检测的SQL编写、Vue的异步请求和路由守卫、ECharts图表动态刷新。这些代码案例短小而完整，背下来都不亏，面试时聊到项目经历也拿得出手。
5.2 数据库初始化脚本怎么跑
项目仓库里附带了一个init.sql文件，用Navicat打开后直接运行，会自动创建数据库和表结构，并插入几条测试数据。这里有个小提示，运行前先把SQL里的DROP TABLE IF EXISTS看清楚，如果你本地的数据库里恰好有同名表，会被直接删掉。导入后，建议先用测试账号登录一遍全流程，确认数据没有问题，再去改代码。
5.3 本地跑起来的两分钟快速指南
要求前置环境：JDK 8+、Maven 3.6+、MySQL 5.7+、Node.js 14+。后端启动方式是在项目根目录执行mvn spring-boot:run，或者用IDEA打开后直接运行Main方法。前端需要先执行npm install装依赖，再执行npm run serve启动开发服务器。注意前端代理配置，在vue.config.js里把/api的请求代理到http://localhost:8082，这样前端请求就不会直接打到后端而触发跨域问题。
5.4 一套可以反复使用的部署组合
如果想把项目部署到服务器上给同学演示，推荐的方式是后端打成jar包，前端执行npm run build打包成静态文件，然后用Nginx同时托管前端静态文件和对/api路径的反向代理。Nginx的核心配置片段：
server { listen 80; location / { root /usr/share/nginx/html; index index.html; } location /api/ { proxy_pass http://127.0.0.1:8082; } }部署时最容易被忽略的是前端路由的history模式问题：直接刷新某个页面会404，需要在Nginx里加一条try_files $uri $uri/ /index.html;。这个小坑不打紧，但搞不定的话，你辛辛苦苦部署完，一刷新就白屏，心态很容易崩。
6. 关于项目后续扩展的一些个人心得
如果你想让这个项目在评分中往上走一档，我比较推荐加一个“环境监测”页面：当观众参观某个光影作品区时，传感器实时返回温湿度数据，后端折线图展示环境变化。这个功能的难点在于实时数据的推送，你可以用WebSocket实现，也可以简单粗暴地让前端每3秒轮询一次接口。对毕设来说，“技术含量适中但效果明显”是加分王道，轮询已经足够，真不用为了追求新颖去引入重型消息中间件。
个人在做这套项目时最大的体会是：很多同学写代码时容易陷入“为了用而用”的误区，比如明明只需要一个简单的状态字段，偏要引枚举字典表；明明数据量就几百条，非要配Redis缓存。这些技术在身上没有坏处，但实现不成熟反而让代码变得很难维护。毕设项目的评分逻辑从来不是看你用了多少技术，而是看你在有限的技术范围里有没有把每个点做扎实。
最后分享一个小技巧：每次答辩前，把自己代码里的SQL全部在Navicat手工执行一遍，看有没有慢查询或报错；把每个按钮从头到尾点一遍，看有没有控制台报错。这两件事做完，现场演示出问题的概率能降低八成。代码写得好不好，很多时候不是在写的时候看，而是在演示的时候看。稳，是最重要的。
