基于SpringBoot+Vue的企业车辆管理系统设计与实现全解析

1. 项目概述与价值拆解

这个标题看起来平平无奇，但做过毕设的人都知道，“企业车辆管理系统”属于管理信息系统里最典型的综合型题目，覆盖面广，技术点密度适中，既能体现开发能力又不至于失控。SpringBoot + Vue + MySQL这套组合更是当前后端分离开发的事实标配，很多企业的管理系统都是这个架构。把这三个点吃透，整个毕业设计的含金量就立住了。

这个项目解决的问题很清晰：企业里车辆调度混乱、费用记录靠Excel、司机排班靠口头通知、年检保险经常过期才知道，需要一个系统把车辆信息、用车申请、审批流程、费用记录、维保管理、统计报表全部管起来。听起来业务上并不复杂，但它同时牵扯到RBAC权限、工作流审批、文件上传存储、复杂条件查询、ECharts可视化，这几个子模块叠加起来，难度并不低，恰好是本科毕业设计最理想的分量。

适合谁来参考呢？一是选了类似管理系统的本科生，二是想学前后端分离开发但缺完整案例的Java学习者。这套东西不是你抄一遍就够的，而是要把里边的设计逻辑讲明白，答辩的时候老师深挖几个问题，你会不会，直接决定你能不能拿到优秀成绩。

2. 系统架构设计与技术选型拆解

2.1 前后端分离还是服务端渲染

很多教程还在用古老的JSP + SpringMVC那套，但现实是企业开发已经全面转向前后端分离了。毕设选题如果是车辆管理系统，直接采用SpringBoot提供RESTful API、Vue独立渲染的架构，这个选择本身就是加分项。分离架构的核心优势不是“显得高级”，而是真正解决了协同开发的问题——前端专注交互，后端专注数据，两者通过JSON接口交互，后期扩展移动端也只需要复用同一套API。

我建议的项目结构：

vehicle-management ├── backend # SpringBoot后端服务 │ ├── controller # 接口层 │ ├── service # 业务逻辑层 │ ├── mapper # MyBatis-Plus数据访问层 │ ├── entity # 实体类 │ ├── dto # 前端入参对象 │ ├── vo # 前端出参对象 │ ├── config # 拦截器、跨域等配置 │ ├── utils # JWT、日期等工具类 │ └── common # 统一返回结果和异常处理 ├── web # Vue前端工程 │ ├── src │ │ ├── api # 接口请求封装 │ │ ├── views # 页面组件 │ │ ├── router # 路由配置 │ │ ├── store # 状态管理 │ │ └── components # 通用组件 └── sql # 数据库初始化脚本

项目拆解层面，按模块分包是基本功，但重点在于分层后的调用链要清晰：Controller只做参数接收和数据校验，不写业务逻辑；Service层承载事务和核心规则；Mapper层只负责SQL查数据。很多初学者习惯把业务逻辑写进Controller，一个接口跑几百行，这种代码答辩时被老师看到基本会引起追问。

2.2 技术栈选型的几个关键考量

SpringBoot的版本选择，我推荐2.7.x这个分支。原因很实际：2.x的文档和解决方案最多，网上能查到的踩坑记录最丰富，学校答辩环境通常也用JDK8配合SpringBoot2.x。3.x虽然新，但强制JDK17，且很多旧依赖不兼容，除非你有强烈的理由，不然不要给自己添堵。

权限模型上用Spring Security加JWT还是Shiro？车辆管理系统的角色不外乎系统管理员、调度员、驾驶员、普通员工四五种，用Spring Security的说法对SpringBoot原生生态整合度更高，但学习曲线略陡；Shiro的API更直观一些，學习成本低。两种方案都能做，重要的是你答辩时能说清楚RBAC模型里的用户-角色-权限表是怎么关联的。推荐Spring Security，因为毕业以后真正进企业开发，Spring Security的出场率远高于Shiro。

数据库层面，MySQL 8.0是当下的默认选择，要注意的不少细节在后文展开。ORM选用MyBatis-Plus，为什么不建议直接用MyBatis？因为Plus提供了条件构造器、分页插件、自动填充这些功能，能把开发量砍掉一大截，代码可读性也更好。但要能解释清楚它和MyBatis底层的关系，老师经常会问“它自动生成的那些方法本质是什么”——本质还是代理对象在跑MyBatis的SQL会话。

2.3 车辆管理系统的核心流程闭环

我先画一遍业务主流程，理解了这条线，所有表结构和页面基本都能推导出来：员工提交用车申请，填写用车时间、人数、目的地、事由和预估里程；调度员审批通过后，系统校验该时间段车辆和驾驶员是否空闲并分配；车辆出车后，记录实际里程；归还时，补充油量、费用等信息；财务人员按月汇总费用，系统生成统计报表。

听着很简单，但踩坑点都在细节里。比如节假日期间同一辆车被多人同时申请，冲突检测的算法怎么写；审批之后用户能不能撤销，撤销之后车辆释放的逻辑怎么处理；超时未归还的监控，如何及时通知；年检到期、保养里程到限，系统怎么自动预警。我建议第一版先抓住主干流程，把这些细节作为后续的功能增强点写进论文的展望部分，这样工作量可控，论文内容还显得有深度。

3. 数据库表设计与核心业务建模

3.1 表结构规划与字段设计

车辆管理系统的数据模型，我建议从12张核心表起步，直接给出建表设计的要点。

• sys_user：用户表，存放登录账号、密码加密后的密文、姓名、手机号、部门ID、状态。密码用BCrypt加密存储，千万不能明文。
• sys_role：角色表，至少包含超级管理员、调度员、驾驶员、普通员工四个角色。
• sys_menu：菜单表，为了做动态路由和按钮级权限控制，菜单用树形结构设计，parent_id指向父菜单。
• sys_role_menu：角色菜单关联表，一个角色能看到什么菜单、点得了什么按钮，完全由这张表决定。
• sys_user_role：用户角色关联表，一个用户可以有多个角色，这里走多对多。
• vehicle_info：车辆信息表，车牌号、品牌型号、车辆类型、座位数、购买日期、年检到期日、保险到期日、当前里程、车辆状态。
• driver_info：驾驶员表，关联用户表，补充驾驶证编号、准驾车型、从业资格证有效期。
• vehicle_apply：用车申请表，这是业务的核心表，记录申请人、申请时间段、目的地、用车事由、状态（待审批/已通过/已驳回/已取消）、审批人、审批意见。
• dispatch_record：调度记录表，审批通过后生成，记录分配的具体车辆、驾驶员、出库时间、归来时间。
• vehicle_maintenance：维保记录表，记录保养、维修明细，含类型（保养/维修）、费用、维修点、下次保养里程或日期。
• refuel_record：加油记录表，加油日期、金额、油量、当前里程、经手人。
• vehicle_expense：费用汇总视图，加油、维修、保险、年检等各项费用的关联查询，用于生成报表。

3.2 核心表字段设计的关键技巧

以vehicle_apply为例，这是最容易出现设计缺陷的表。申请开始时间和结束时间必须用datetime而不是date，因为同一天内多人分时段用车是常态。状态字段建议用int或varchar加注释，我选择tinyint加状态码枚举，代码里写死常量，不要用魔法数字。申请ID建议用雪花算法而非数据库自增，原因是后续可能要对接其他系统，分布式环境下自增ID容易碰撞。

还有一个细节容易忽略：费用相关字段统一用DECIMAL(10,2)而不是float，浮点运算是二进制的，算钱会出现0.1 + 0.2不等于0.3的尴尬。里程数和油量这种涉及加总的字段也一样，用DECIMAL。

3.3 索引设计与查询优化

核心查询场景有两个，第一个是用户查看自己的申请列表，第二个是调度员查看时间范围内的所有申请。针对这两个高频场景，vehicle_apply建一个联合索引(user_id, status)和单列索引(apply_date)。很多人建索引不思考顺序，union索引最左前缀原则决定了查询条件必须从最左边开始匹配，所以字段顺序直接影响索引是否生效。

报表统计的时候经常按日期范围做分组聚合，比如查某月每天的用车次数。这类查询建议用MySQL的DATE_FORMAT函数做日期格式化加GROUP BY，同时注意在日期字段上建索引。数据量上了十万条以后，全表扫描会变得很慢，所以统计表的核心日期字段加索引要提前规划好。

3.4 外键和逻辑删除的取舍

整车管理系统的表之间是有真实关联的，比如申请表关联用户表，调度记录关联车辆表。这里我建议不要用数据库外键约束，而是让Service层通过业务代码保证数据一致性。理由在于：高并发写入场景下数据库外键会带来额外的锁开销，而且项目规模变大后分库分表基本没法用外键；ORM层面做了关联查询就够了，MyBatis-Plus提供了逻辑删除功能，删除记录不是真的DELETE而是置一个deleted标记，这样历史数据还能留着查询用。

逻辑删除是一个很大的加分点，答辩时可以围绕“数据可追溯”展开讲。但注意所有业务SQL都要带deleted条件，MyBatis-Plus的全局逻辑删除配置可以自动完成这一点，前提是每个实体类都加对应注解。

4. 后端核心功能与接口实现解析

4.1 统一响应结果与全局异常处理

后端开发的第一步不是写业务，而是把基础设施搭好。我用一个Result类封装所有接口返回值：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

前端拿到任何一个接口返回，先判断code再取data，这是前后端协作的基础规范。

种植异常处理，我不建议在Controller里写try-catch，而是用@RestControllerAdvice做全局异常拦截。业务上出现的所有可预知问题，例如车辆不存在、申请时间冲突、审批状态不允许变更等，直接抛一个自定义BusinessException，统一由全局处理器转成Result.error返回。这样Controller代码得到极大瘦身，维护成本直线下降。

安全校验方面，JWT鉴权用一个拦截器实现。登录成功后后端签发token，前端存储到本地并在每次请求头里携带Authorization字段。拦截器里放行登录接口和静态资源路径，其余接口全部校验token有效性。注意拦截器要排除OPTIONS预检请求，否则前后端分离部署时跨域请求会被拦在门外，这个坑我见很多人踩过。

4.2 用车申请与冲突检测的实现逻辑

用车申请是业务的起点，接口设计的难点在冲突检测上。设计的核心判断：新的时间区间和老记录是否重叠。数学上的重叠条件是新开始时间小于老结束时间且新结束时间大于老开始时间，这个条件写进SQL：

// 查询时间段内已被绑定的车辆 LocalDateTime start = applyDTO.getStartTime(); LocalDateTime end = applyDTO.getEndTime(); LambdaQueryWrapper<DispatchRecord> wrapper = Wrappers.lambdaQuery(); wrapper.eq(DispatchRecord::getVehicleId, vehicleId) .eq(DispatchRecord::getStatus, 1) // 状态为已出车 .lt(DispatchRecord::getStartTime, end) .gt(DispatchRecord::getEndTime, start);

执行这个查询，如果返回结果不为空，就说明该车辆在该时间段已被占用。注意重叠条件要同时覆盖部分重叠和完全包含的情况，只判断contains是新手容易犯的错误。

4.3 审批流程的状态机设计

审批流程写成状态机能让逻辑清晰很多。我定义一个枚举：

@Getter public enum ApplyStatus { PENDING(0, "待审批"), APPROVED(1, "已通过"), REJECTED(2, "已驳回"), CANCELLED(3, "已取消"), COMPLETED(4, "已完成"); private final Integer code; private final String description; }

状态的可迁移路径是严格受控的：待审批可以被审批为通过或驳回，也可以由申请人自己取消；通过之后车辆出库可以标记为已完成；驳回和取消都是终态。在Service层做一个校验方法，每个状态变迁前先判断当前状态是否允许迁移到目标状态，防止接口被绕过直接改状态。这是业务流程的核心规则，写清楚并配合状态码，也是答辩时展示工程化能力的好地方。

审批接口注意一个细节：审批人和申请人是同一个用户时提示禁止自审。车辆调度最好支持同一个时间段内多辆车并行审批查看，方便调度员挑选空闲车辆。

4.4 报表统计的SQL与数据可视化对接

月度统计报表我建议拆成几步。先算用车次数和里程，按天分组；再算费用，加油、维修、保险三个来源各自汇总，再用一个总表关联。SQL层面需要注意GROUP BY和聚合函数的使用，比如按天统计：

SELECT DATE_FORMAT(apply_date, '%Y-%m-%d') AS day, COUNT(*) AS apply_count, SUM(planned_mileage) AS total_mileage FROM vehicle_apply WHERE status = 4 AND apply_date BETWEEN #{startDate} AND #{endDate} GROUP BY DATE_FORMAT(apply_date, '%Y-%m-%d')

统计结果直接封装成VO返回前端，前端用ECharts折线图展示每日趋势，饼图展示费用构成。做数据可视化的时候，前后端联调最容易出现的问题是日期格式不一致，建议统一ISO字符串传值，由前端负责格式化展示。

5. 前端Vue实现要点

5.1 前端工程结构与路由权限控制

Vue前端我使用的是Vue 3加Element Plus，配合Vite构建工具。Vue 3的CompositionAPI比OptionsAPI更适合逻辑复用，把请求、状态、业务逻辑都写到setup里边，代码紧凑且可测试性好。Router使用createRouter加createWebHistory方式，同时设置全局前置守卫：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

动态路由我建议在后端登录时返回当前用户的菜单列表，前端用addRoute方法动态注册。这样管理员和普通员工登录后看到的功能完全不同，菜单直接由后端权限控制，避免仅仅靠路由守卫隐藏界面的安全问题。按钮级别的权限控制使用自定义指令v-permission，在指令里判断当前用户是否拥有对应权限编码，没有就直接移除DOM。

5.2 用车申请与审批页面交互细节

用车表单是前端交互的核心，注意几个实操层面的设置。日期控件用Element Plus的el-date-picker加daterange，快捷选项设置为今天、明天、本周，减少用户手动填写的负担。表单校验至少覆盖：开始时间不能早于当前时间，结束时间不能早于开始时间，目的地和事由不能为空，预估里程不能小于0。时间冲突的后端返回错误信息要在页面上直接弹出提醒，方便用户快速调整时间窗口。

审批列表页面需要做到数据实时性，不建议每操作一次就手动刷新全部列表，用局部数据更新方式效率更高——审批完成一条后从当前列表移除一条，同时把统计数字改掉。页面上的状态标签用tag组件展示，不同状态加不同颜色，视觉上一眼能分辨哪个有待办任务。

5.3 文件上传与附件管理的ECharts展示

车辆管理系统通常需要上传行驶证、保险单扫描件等附件，这一块的方案我建议引入独立的MinIO服务。文件不直接存数据库，数据库只存文件的访问路径，MinIO通过预签名的URL方式对外提供访问。前后端上传的流程是前端直接向MinIO发起PUT请求，成功之后把文件路径回传给后端记录。这样做的好处是文件访问不走应用服务器，大文件传输不阻塞业务接口。

ECharts方面，我建议统计页面做成三个板块：月度用车趋势（折线图）、部门用车占比（饼图）、费用构成（柱状图）。动态数据全部从后端报表接口拉取，渲染时注意在用 组件销毁时调用dispose方法释放图表实例，否则切换页面再切回来时图表会重复初始化出现白屏或告警。

6. 部署环境搭建与云端发布全流程

6.1 从本机到服务器的部署方案

毕设最后一环是部署。本机开发用IDEA启动后端、VS Code起前端，但最终你要把系统部署到服务器上，可能是阿里云或腾讯云的轻量应用服务器。我的部署建议方案是宝塔面板加Docker的组合。宝塔面板负责MySQL和nginx的管理，Docker跑后端Java应用，前端dist目录直接由nginx静态托管。

后端打包先执行mvn clean package，注意跳过测试阶段mvn clean package -DskipTests。SpringBoot默认打出来的是可执行jar，部署时用nohup命令启动：

nohup java -jar vehicle-backend.jar --spring.profiles.active=prod > app.log 2>&1 &

6.2 Nginx反向代理与前端部署

前端构建执行npm run build，产物在dist目录，把dist里的内容扔到nginx的html目录。Nginx配置两块：一是静态资源托管前端，二是并反向代理/api路径到后端服务：

server { listen 80; server_name your-domain.com; root /home/www/vehicle-web; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

关键点在于try_files配置，Vue的history模式路由在用户直接访问某个子路径时，如果服务器上没对应文件，要回退到index.html，由前端路由接管。还有proxy_pass后面的路径需要注意：如果不带/，会把完整路径传过去；带/则会把location前缀去掉。既然接口统一以/api开头，推荐保留前缀，去掉/。

6.3 服务器MySQL安装与配置

服务器上的MySQL建议先装MySQL 8.0版本，安装时设置root密码。推荐创建一个专用数据库账号而不是直接用root跑业务：

CREATE DATABASE vehicle_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER 'vehicle'@'localhost' IDENTIFIED BY 'YourStrongPass@123'; GRANT ALL PRIVILEGES ON vehicle_system.* TO 'vehicle'@'localhost'; FLUSH PRIVILEGES;

然后导入建表SQL脚本：mysql -u vehicle -p vehicle_system < init.sql。

常见的一个坑是MySQL8默认的认证插件是caching_sha2_password，而一些老版本客户端工具连不上。如果遇到，可以修改为mysql_native_password。但如果你用的是新版MySQL Workbench或者Navicat 16以上版本，其实不需要改。

6.4 Docker部署与持续集成思路

想要更工程化的部署，考虑用Docker Compose编排。编写一个docker-compose.yml包含后端服务、MySQL、MinIO三个容器：

version: '3' services: mysql: image: mysql:8.0 container_name: vehicle-mysql environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: vehicle_system ports: - "3306:3306" volumes: - mysql-data:/var/lib/mysql - ./sql/init.sql:/docker-entrypoint-initdb.d/init.sql restart: always minio: image: minio/minio container_name: vehicle-minio command: server /data --console-address ":9001" environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin ports: - "9000:9000" - "9001:9001" volumes: - minio-data:/data backend: build: ./backend container_name: vehicle-backend depends_on: - mysql - minio ports: - "8080:8080" restart: always volumes: mysql-data: minio-data:

有经验的评委老师看到你用了容器化部署，通常好评度会明显提升。这一块放在论文的部署章节详细写，并截图留档，答辩的时候打开服务器页面现场演示。

7. 常见问题排查与避坑手册

7.1 SpringBoot与MySQL版本不兼容

热词里有个“springboot版本太高”，一年能遇到好几回。常见错误是用的SpringBoot 3.x配合MySQL驱动用的还是com.mysql.jdbc.Driver老包名，启动直接报ClassNotFoundException，或者报SSL连接错误。解决方案是确认三件事：pom中引入的mysql-connector-j版本不低于8.0.30；JDBC的url带serverTimezone=Asia/Shanghai参数；驱动类名用com.mysql.cj.jdbc.Driver。如果用的是SpringBoot 3.x，注意它集成的JDBC默认是HikariCP，连接池参数和2.x完全兼容，问题基本出在驱动上。

7.2 常见的SSL连接错误

错误信息长这样：Communications link failure. The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server. 原因通常是MySQL8默认启用SSL而驱动/客户端环境没有正确校验。排查思路：先确认MySQL服务启动并监听3306端口，telnet一下IP和端口通不通；然后看JDBC url是否带useSSL=false，很多教程写的连接串没有这个参数，导致驱动尝试SSL握手失败。我的连接串模板：

jdbc:mysql://127.0.0.1:3306/vehicle_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

allowPublicKeyRetrieval=true也很重要，MySQL8的caching_sha2_password插件首次认证需要获取公钥，不加这个参数同样会报连接失败。

7.3 前端npm安装依赖卡住

Vue工程最折磨人的就是npm install，经常卡在某个包卡很久，还时不时报ERESOLVE错误。解决方案：一是先升级npm版本npm install -g npm@latest；二是设置镜像源为淘宝源：

npm config set registry https://registry.npmmirror.com

如果项目用的依赖版本互相冲突，先删除node_modules和package-lock.json再重新安装。如果某个包下载超时，单独安装该包并指定版本，npm install element-plus --save。Vite构建时如果报内存溢出，设置NODE_OPTIONS=--max-old-space-size=4096环境变量再重新执行构建命令。

7.4 部署后接口调通了页面却白屏

前后端分离部署的一大经典问题：前端接口通了，页面白屏。排查顺序：打开浏览器开发者工具，看Console报什么错；如果报的是加载JS文件404，多半是nginx的root路径配置错了；如果报跨域，那就是后端没有正确配置CORS跨域支持。建议后端里配置一个跨域过滤器，允许来自前端部署地址的跨域请求。还有vue-router的history模式部署后刷新变成404的问题，前面说到的try_files配置就是根治方案。

7.5 数据展示不对的排查思路

审批列表显示的数据和实际数据库对不上，优先考虑逻辑删除是否生效，MyBatis-Plus默认的全局逻辑删除字段查找的是deleted，如果某张表的逻辑删除字段叫is_deleted，需要单独配置。日期差8小时的问题检查JDBC时区和服务器时区是否一致，最简单的方式是统一服务器时间设为Asia/Shanghai，并在数据库连接串里显式指定serverTimezone。

我把排查思路整理成一个速查表：

8. 论文写作架构建议与查重注意事项

8.1 论文大纲建议

毕设论文的结构要跟着系统开发流程走，我建议的一级标题结构是：

1. 绪论：背景与意义、国内外研究现状、论文主要内容与结构安排
2. 相关技术介绍：SpringBoot框架、Vue框架、MySQL数据库、前后端分离架构
3. 系统需求分析：可行性分析、功能需求分析、非功能需求分析
4. 系统总体设计：架构设计、功能模块设计、数据库设计
5. 系统详细设计与实现：重点按功能模块论述，配合核心代码片段和页面截图
6. 系统测试：测试环境、功能测试用例、性能测试结果
7. 总结与展望

8.2 论文写作的几个关键技巧

论文最怕写得像说明书。技术介绍那章别大段抄框架文档，而是结合本项目说明为什么选它，比如“选择SpringBoot是因为其内嵌Tomcat免去了繁琐的XML配置，同时提供了强大的starter生态，能快速整合MyBatis-Plus和JWT”。

系统设计部分要求图文并茂，架构图、用例图、E-R图、流程图建议提前用绘图工具画熟练。数据库设计章节不要只贴建表语句，对每张核心表的功能和设计思路用文字做说明，例如为什么要在vehicle_apply表中冗余存储vehicle_id而不是关联查询——因为调度完成后车辆可能被换掉，而申请单上需要保留最终实际使用的车辆。

8.3 降低查重率的实操方法

查重率是所有毕设的痛点，这里分享一些有效的方法。第一原则是：不要大段复制任何博客或论文原文，要使用自己的话重新组织，把技术点说清楚。写功能设计的时候多用项目自己的SQL语句、代码片段和页面截图填充，文字叙述尽量精简，代码不被查重系统重点收录。

还有一个技巧是把自己的实现过程描述得具体一些，比如“本系统在审批模块中引入了状态机设计模式，将申请表的status字段严格约束为待审批、已通过、已驳回、已取消、已完成五个状态，并在每次状态变更前进行合法性校验”，这种结合具体业务的原创表述查重系统很难匹配到重复源。

9. 从毕设到项目的实际经验总结

版权属性问题基本说完了，最后分享一些做这个项目时我的真实体会，希望能帮到还没开题或者正在做的同学，也帮已经在改代码的同学补一些思路。

建筑结构上最值得投入精力的三个地方是权限模型、业务状态流转、报表统计。做完了这个项目你会发现，这三块恰恰是几乎所有企业管理系统的公共骨架，换个业务场景从车辆换成会议室、工单、办公用品，系统照样能用。所以认真完成这个毕设，收获的不只是一份源码和论文，而是对企业应用开发的整体认知。

部署和文档也不要拖到最后一周才开始。我曾经见过太多同学代码写得不错，最后却因为部署文档不齐全、不会演示、没准备完整的数据初始化脚本导致答辩现场翻车。建议在项目中期就找一台云服务器，把Maven构建、Vue打包、nginx配置、MySQL初始化这些流程完整跑通至少一遍，让导师或同学从外网访问一下系统，做到心中有数。

最后再给一个小技巧：答辩演示之前，先在数据库里造好几组干净的数据，包括不同状态的申请单、不同角色的账号、不同月份的统计报表，演示的时候画面会非常饱满。千万别现场临时填表单等人审批，那种等待的过程在答辩现场是极其尴尬的。数据造好，从头到尾按业务主线演示一遍，面试老师问的问题基本都在预料之内。

我做完这个项目的整体感受是：这套技术栈的复杂度上限非常高，但下限也足够友好。你完全可以从最简单的CRUD起步，再逐步补上文件存储、报表可视化、权限控制、容器化部署这些层次，一步一步把它做深。希望这份总结对正在做类似题目的你有所帮助，如果是第一次接触前后端分离开发，建议先按这个文章把核心业务链路跑通，再考虑扩展细节，不要一上来就贪多求全。