“光影系统”这四个字从需求方嘴里说出来时我第一反应是那种五光十色的灯光秀控制台。真正上手聊完才发现人家要的是活动策划公司内部的“光影方案管理系统”——把每场活动的灯光设备清单、场景预设、场次排期统一管起来策划人员录方案、现场人员看排期、管理员维护设备库一套标准的前后台 Web 应用技术栈明确指定了 SpringBoot Vue MyBatis MySQL并且要求前后端分离交付附带完整源码和部署教程。这项目做完之后我最大的感受是技术点没有一个是“新”的但把这一套组合用在带视觉属性的业务系统上踩坑点和普通管理系统还不大一样。比如场景预设怎么存、色值数据怎么传、场次时间在前端和后端之间为什么会差出 8 小时、Nginx 部署时候 static 资源和 API 路由怎么处理——这些才是折腾半天的东西。这篇我就把从需求拆解、表结构设计、后端接口、前端交互到服务器部署的完整链路复盘一遍适合正在做类似“管理系统 可视化展示”项目的同学参考也适合准备拿前后端分离项目练手的人照抄作业。1. 光影系统的需求边界与技术选型复盘1.1 客户到底要什么从“灯光控制”到“光影方案管理”需求最初只有一句话“做一个光影系统把灯光效果管起来。”这是典型的需求模糊场景如果直接按字面理解去搞灯光硬件控制项目方向就偏了。我花了一周时间和客户方对业务场景才把真正的边界理清楚。这个系统的使用方不是灯光师而是活动公司的策划和运营人员。他们日常要做的事情是接到一场活动后确定这场活动用什么灯光风格比如“暖阳”“夜蓝”“落日渐变”把用的灯具型号、功率、色温、数量列进清单再把活动排到某一天某个时间段。活动现场的操作人员只需要打开系统看到当天场次的光影执行单照着执行就行。所以核心模块拆下来只有四个设备管理维护灯具资源库包含型号、功率、色温范围、通道数、状态。场景预设定义光影风格比如一组色值、一套亮度变化曲线关联若干设备建议。方案编排策划人员创建立体方案绑定场景、选择设备清单、设置执行时间。场次日历以天为单位展示排期支持按日期范围、状态、负责人检索。搞清楚需求边界后技术实现就明确了这是一个典型的 MIS 类系统重点在数据建模和流程配置上不需要实时硬件控制也不需要高并发。选这套技术栈从业务角度完全够用还能保证交付周期和团队上手成本可控。1.2 为什么是 SpringBoot Vue MyBatis MySQL 这套组合这个组合在市面上确实“烂大街”但“烂大街”本身就是理由——它稳定、生态成熟、招人容易、排查问题能找到海量案例。我后来复盘这个项目的选型把每个组件的理由都写进了技术方案文档里。组件选择理由我在备选方案对比时的判断SpringBoot快速搭建 RESTful API内置 Tomcat配置自动化Java 生态适合团队现有技术栈有人提过用 Node.js但后端团队的主语言是 Java没必要为了“新”换语言Vue组件化开发效率高响应式数据绑定适合列表和编辑器类交互中文文档和社区案例丰富Vue3 Vite 或 Vue2 Vue CLI 都行项目按团队熟练度选了 Vue3MyBatisSQL 完全可控复杂查询和动态条件组合比 JPA 更直观DBA 审起来也方便JPA 自动建表和抽象查询在业务快速变化时反而不好追查问题MySQL成熟、稳定、事务可靠十几万条数据的表完全无压力部署运维成本最低没有分库分表需求不需要上分布式数据库这里有一个点想多说一句很多人纠结 MyBatis 和 MyBatis-Plus 怎么选。这个项目我用了原生 MyBatis故意没上 MyBatis-Plus。原因有两个一是核心查询都是多表关联和条件动态拼接手写 XML 更直观二是代码库里引入太多“半自动”封装后新接手的人往往对底层 SQL 失去掌控感。实体类、Mapper 接口、XML 这三件套虽然啰嗦但每一条 SQL 都摆在明面上出问题一眼能看到。1.3 前后端分离的请求链路与部署拓扑前后端分离的意思不只是代码目录分成两个仓库更关键的是部署形态和请求链路。这个项目最终的部署结构是浏览器 - Nginx 托管前端静态资源dist 目录 - 访问首页 - 登录后请求 /api 前缀的接口 - Nginx 反向代理到后端 SpringBoot 进程监听 8080 端口 - SpringBoot 通过 MyBatis 访问 MySQL监听 3306 端口。这里有个非常容易踩的坑很多人把前端打包后的 dist 文件随便丢到服务器某个位置然后直接访问 8080 端口以为后端能同时服务页面和 API。结果页面能打开登录接口却跨域失败。正确做法是让 Nginx 承担静态文件服务和 API 反向代理的职责前端页面请求的相对路径是 /api/login浏览器看到的是同源请求不存在跨域问题也就绕开了开发环境里 CORS 配置的那堆破事。我在部署文档里画过一张请求链路的说明图其实不画图也讲得清楚静态资源走 Nginx 的 root动态请求走 Nginx 的 location /api/两个 location 互不干扰这也是前后端分离部署最标准的姿势。2. 从表结构到MyBatis数据层的建模与动态SQL实践2.1 核心表设计设备、场景、排期三张表的字段取舍这个系统的数据模型不复杂但有几个字段设计是能体现“做过实际项目”的地方。我建了三张核心业务表设备表 light_device、场景预设表 light_scene、场次排期表 show_plan加上最基本的用户表 sys_user。先看场景预设表这是整个系统里最“光影特色”的一张表CREATE TABLE light_scene ( id bigint NOT NULL AUTO_INCREMENT, scene_name varchar(64) NOT NULL COMMENT 场景名称如暖阳、夜蓝、落日渐变, tone_json varchar(1024) DEFAULT NULL COMMENT 色值集合JSON数组如[{color:#FFA500,pos:0},{color:#FF4500,pos:100}], curve_json varchar(1024) DEFAULT NULL COMMENT 亮度曲线关键点JSON数组, status tinyint DEFAULT 1 COMMENT 1启用 0停用, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT光影场景预设表;我重点说一下 tone_json 和 curve_json 这两个字段的设计思路。初版设计时有人建议把色值和亮度曲线拆成两张子表理由是“规范化”。我否掉了这个方案原因非常实际一条场景预设的色值集合就是一个固定长度的数组前端场景编辑器一次性读出来、一次性提交拆成子表意味着每次编辑要删了重插还要处理事务查询时多一次关联最终换来的“规范化”没有任何实际收益。用 JSON 字符串存这种结构稳定的配置数据是这个体量项目里最优解处理时后端直接用 Jackson 转对象数组就行。设备表的字段设计倒没什么稀奇就是品牌、型号、功率、色温范围、通道数、状态这几个。真正要注意的是功率和色温不能只存一个字符串因为后面要做按功率范围检索。数字语义的字段一定要用数值类型否则写动态 SQL 的时候 、、BETWEEN 全都用不上。场次排期表则要关联场景 ID并冗余一个场景名称字段避免列表页每次都要 JOIN这是典型的用冗余换性能的取舍。2.2 MyBatis的XML与注解混用动态SQL解决组合检索MyBatis 的使用细节是这个项目数据层最核心的部分。我的习惯是单表简单 CRUD 用注解多表关联和动态条件查询全部走 XML。这样写的原因很简单——注解拼接动态 SQL 可读性太差一串 Select 里塞了四五个