SpringBoot+Vue车辆管理系统设计与实现：从零搭建到答辩通关指南-平芜编程栈

车辆管理系统这类题目，放在毕业设计里属于“经典永流传”的选择了。无论是计算机专业还是相关工科专业，每年选题库里基本都少不了它。要说原因也很直接：业务模型清晰（无非是车辆信息、司机信息、用车申请这些）、技术栈覆盖面广（后端、前端、数据库全都有）、难易程度又适中——好好做能做得出亮点，粗糙应付也能顺利结题。它不偏门，不挖坑，是所有指导老师都不会反对的选择。这次梳理这套SpringBoot+Vue车辆管理系统的源码和实现逻辑，就是想把从技术选型、数据库设计再到前后端联调这条链路上的关键点都摊开讲清楚。适合正在准备毕设、课设，或者单纯想搞懂一个完整JavaWeb项目是怎么跑起来的同学来对照参考。

我先把话放这儿：市面上这类源码包其实多如牛毛，但“能跑”和“会做”完全是两码事。拿到源码只是第一步，能跟面试官或者答辩老师把设计思路、表结构为什么这么建、接口为什么这么写讲明白，那这个项目才算真正属于你了。

1. 技术选型复盘：为什么毕设选用这套组合拳

1.1 SpringBoot为什么成了JavaWeb项目的标配

SpringBoot之所以能在这个领域里占据统治地位，核心在于它把过去SSM框架中大量繁琐的配置工作干掉了。我读书那会儿用的还是Spring MVC + MyBatis那套，光一个spring-context.xml、spring-mvc.xml、mybatis-config.xml的配置组合就能让人调试一晚上。部署还需要单独装Tomcat，把war包丢进去，稍不留意端口冲突、Jar包依赖冲突一堆问题就冒出来了。

SpringBoot把这些全部内聚到了一起。内嵌的Tomcat容器意味着你不需要额外安装任何服务器软件，mvn clean package之后一个java -jar命令就能启动整个后端服务。再配合自动配置机制，引入spring-boot-starter-web依赖，一个空类上加了@SpringBootApplication注解，就能跑起来一个Web应用。对于做毕设的同学来说，这套机制极大地降低了起步门槛，让你有更多精力集中在业务逻辑本身，而不是和各种配置文件斗智斗勇。

另外SpringBoot还有一个对毕设非常友好的特性：生态整合能力太强了。你要做权限验证，spring-boot-starter-security或者spring-boot-starter-validation直接加依赖即可；你要做数据库操作，mybatis-plus-boot-starter也已经是开箱即用的状态，CRUD的通用方法几乎不用写SQL。这套工具的成熟度，已经是过去SSM时代没法比的。

1.2 Vue带来的前后端分离开发体验

车辆管理系统的前端选Vue，背后是典型的“前后端分离”思想。说白了就是前端负责页面渲染和交互效果，后端只负责提供JSON格式的数据接口，两边通过HTTP协议进行通信。这种模式的好处很直接：分工明确了，后端可以专注于业务逻辑和数据安全，前端可以专心处理用户体验；团队协作时互不阻塞，属于当今企业级开发的项目主流形态。

Vue的使用体验对学生也比较友好。单文件组件的写法让你可以把一个功能的模板、脚本和样式放在同一个.vue文件里，维护起来逻辑清晰。配合Element UI这套组件库，表格展示、表单弹窗、分页控件这类管理系统的“常客”需求，几乎不需要从零开发，拉组件过来改改配置就行。做毕设的周期本来就很紧，这种效率上的优势能让你少熬很多夜。

而且Vue生态中已经解决好了和后端交互的“最后一公里”问题。axios封装了HTTP请求，你可以很轻松地处理请求头、拦截错误、统一返回格式。用Vue Router做页面跳转和权限控制也非常顺手。这一套组合下来，哪怕之前只是看过前端教程，也能在实战中快速进入状态。

1.3 MySQL的角色定位与其他候选方案对比

数据存储选MySQL，这个没什么悬念。MySQL在海量互联网应用里已经经过了长期验证，稳定性和性能对管理平台这种中小型业务来说绰绰有余。它是关系型数据库，支持ACID事务，这对车辆管理系统这种涉及业务流转（比如车辆状态的变更、用车记录的登记）的场景是基本要求。可以用Navicat或命令行工具来管理数据库，操作直观，调试时也方便。

可以用一张表格来对比一下常见的毕设数据存储方案：

方案	适合场景	学习门槛	毕设适配度
MySQL	通用业务系统，有明确的表间关系	较低，教程海量	高，几乎万能
PostgreSQL	数据类型复杂，地理信息等场景	中等	中，学校导师听过的不多
MongoDB	大量JSON格式数据，非结构化存储	中等	低，事务和关联查询偏弱
SQLite	移动端或超小型本地应用	极低	不太主流，显得单薄

实际操作中，车辆管理系统不管怎么扩展，核心还是围绕“车辆”和“人”这两条主线在做数据记录和状态流转。这种业务模型用MySQL来建模非常自然。加上MySQL的安装配置教程覆盖面极广，哪怕你在环境准备阶段遇到什么疑难杂症，基本都能搜索到现成的解决方案，这也是选型时需要重视的隐性成本。

2. 系统架构与数据库设计拆解

2.1 整体项目结构与分层思路

这套车辆管理系统的后端项目结构，典型的Controller-Service-Mapper三层架构。拿Java项目来说，代码包划分为controller、service、mapper、entity、config等模块。在前端项目目录里，则以views、components、router、api等为核心组织页面和接口调用。前后端项目分离部署，开发调试时通过代理解决跨域，生产环境则可以利用Nginx做静态资源代理和接口转发。

分层设计的意义不仅仅是让代码好看，更重要的是让调试和扩展变得可控。Controller只负责接收请求和返回结果，Service承载核心业务规则，Mapper负责与数据库交互，Entity层对应表结构实体。举个例子，当你要新增一个“车辆保险到期提醒”功能时，只需要在Service层加一个方法，并调用Mapper新增一个查询语句，前端对应加一个展示页面，整个流程不会牵扯到太多无关代码。

逻辑分层还有一个直接收益：当代码出现Bug时，你可以根据报错位置快速判断问题出在哪一层。如果是SQL语法错误，大概率在Mapper；如果是业务逻辑算错了状态，去Service里找；如果是接口返回格式不符合前端预期，看Controller层就好。这种定位思路，在答辩现场解决演示故障的时候极其好用。

2.2 核心数据表设计实操

数据库表的设计决定了系统能承载多少功能。基础版的车辆管理系统建议至少具备这几张表：系统用户表、车辆信息表、车辆使用记录表。扩展功能后还可以增加司机信息表、车辆维修保养表、保险记录表。

这里展示车辆信息表和用户表的设计，这是整个系统的地基：

CREATE TABLE `sys_user` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT 'MD5加密后的密码', `real_name` varchar(50) DEFAULT NULL COMMENT '姓名', `role` varchar(20) DEFAULT 'USER' COMMENT '角色：ADMIN管理员，USER普通用户', `phone` varchar(20) DEFAULT NULL COMMENT '联系电话', `status` tinyint DEFAULT 1 COMMENT '状态：1启用，0禁用', `create_time` datetime DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

CREATE TABLE `vehicle_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '车辆ID', `plate_number` varchar(20) NOT NULL COMMENT '车牌号', `vehicle_type` varchar(30) DEFAULT NULL COMMENT '车辆类型：轿车、SUV、货车等', `brand` varchar(50) DEFAULT NULL COMMENT '品牌', `model` varchar(50) DEFAULT NULL COMMENT '型号', `purchase_date` date DEFAULT NULL COMMENT '购买日期', `status` tinyint DEFAULT 0 COMMENT '车辆状态：0空闲，1使用中，2维修中，3已报废', `mileage` decimal(10,2) DEFAULT 0 COMMENT '当前里程（公里）', `store_location` varchar(100) DEFAULT NULL COMMENT '停放位置', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_plate_number` (`plate_number`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='车辆信息表';

建表时有几个细节值得展开说一下。第一，字段建议用bigint作为主键并且设置为自增，这样在后续做分布式场景时也有扩展余地，同时自增索引的写入性能也比较好。第二，utf8mb4字符集是必须的，不要为了省空间用utf8。utf8mb4兼容全部Unicode字符，包括手机号里可能出现的怪字符和不常见的输入法符号，避免出现中文乱码和Emoji写入失败的悲剧。第三，通用的审计字段（创建时间、更新时间）尽量都配上，这对后期排查数据问题非常关键，表格页面上按时间排序的功能也离不开它。

2.3 权限模型与接口路由规划

系统不搞复杂的菜单级权限方案，而是坚持用“用户-角色”的基础模型来控制核心操作。管理员账户可以管理车辆信息、审核用车申请、查看全部记录；普通用户则只能查询车辆状态、提交用车申请、查看自己的历史记录。在JWT令牌中把角色信息直接放进去，后端接口上通过自定义注解配合拦截器做权限校验，这样可以很好地避免每次都查数据库确认身份。

接口设计遵循RESTful风格，围绕核心资源命名：

POST /api/auth/login 用户登录，返回token GET /api/vehicle/page 分页获取车辆列表 POST /api/vehicle/add 新增车辆 PUT /api/vehicle/update 编辑车辆信息 DELETE /api/vehicle/{id} 删除车辆 POST /api/vehicle/apply 提交用车申请 GET /api/record/page 分页获取用车记录

前端路由规划上也做对应设计。登录页、系统首页、车辆管理、用车申请、记录查询、个人中心是基础必备页面。把Vue Router配置为模式，登录成功后将Token存储在本地缓存中，前端根据角色在路由守卫中拦截未授权页面，实现动态跳转。

3. 核心模块实现与实操要点

3.1 用户认证流程与JWT鉴权细节

用户认证模块是后面所有业务模块的门户。流程上无非是登录时校验用户名密码，通过后生成一个加密令牌返回给前端，前端再存储这个令牌并在后续请求中附带。JWT相较于传统Session方案的优势在于它就是一段自包含的验证信息，服务器不保存登录状态，因此在集群部署时不需要额外搞Session共享，这也更契合当前互联网应用的主流做法。

写后端代码时有一个重要细节：密码绝对不允许以明文形式存储。推荐的做法是加盐后使用MD5或者BCrypt进行加密。特别是BCrypt，每次生成的结果都不相同，内置了盐的机制，即使在密码文件泄露的情况下，要破解也需要付出极高的成本。在车辆管理系统里虽然数据不涉及金融级别，但这个习惯一定要在毕设阶段就养成。

核心代码逻辑大致如下：

@Service public class AuthServiceImpl implements AuthService { @Autowired private SysUserMapper userMapper; @Override public LoginResult login(LoginRequest request) { SysUser user = userMapper.selectByUsername(request.getUsername()); if (user == null) { throw new BusinessException("用户不存在"); } // BCrypt校验密码 if (!BCrypt.checkpw(request.getPassword(), user.getPassword())) { throw new BusinessException("密码错误"); } if (user.getStatus() == 0) { throw new BusinessException("账号已被禁用"); } // 生成JWT令牌，有效期设置2小时 String token = JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole()); return new LoginResult(token, user); } }

JWT令牌的解析和校验，通过Spring提供的拦截器和HandlerInterceptor实现。拦截器里针对白名单路径放行，比如登录接口和静态资源；其他所有接口都先执行令牌解析。这里有一个容易踩的坑：在过滤器中要处理“请求头没有携带Token”和“Token过期”这两种异常，不要把它们混成一类错误返回。前端拿到401状态码后应该统一跳转登录页，这样才能形成完整的闭环。

3.2 车辆管理模块的CRUD与状态流转

车辆信息管理是整个系统的前台核心。实现思路上，列表页申请一个分页接口，每次请求带上页码、每页条数和查询关键词。后端通过MyBatis-Plus的分页插件，一行代码就能完成分页查询。这个方法完全可以支撑毕业设计演示时反复翻页、筛选、排序等全部操作，性能也足够优秀。

条件搜索这里值得多写几笔。接口需要支持的筛选条件一般包括：车牌号模糊搜索、车辆状态精确匹配、车辆类型精确匹配。我们用MyBatis-Plus的LambdaQueryWrapper来实现，体验非常顺畅：

public PageResult<VehicleInfo> pageVehicles(PageQuery query) { Page<VehicleInfo> page = new Page<>(query.getPageNum(), query.getPageSize()); LambdaQueryWrapper<VehicleInfo> wrapper = new LambdaQueryWrapper<>(); // 车牌号模糊查询 wrapper.like(StringUtils.isNotBlank(query.getPlateNumber()), VehicleInfo::getPlateNumber, query.getPlateNumber()); // 车辆状态精确过滤 wrapper.eq(query.getStatus() != null, VehicleInfo::getStatus, query.getStatus()); // 按创建时间倒序，最新登记的车排前面 wrapper.orderByDesc(VehicleInfo::getCreateTime); Page<VehicleInfo> result = vehicleInfoMapper.selectPage(page, wrapper); return new PageResult<>(result.getRecords(), result.getTotal()); }

车辆状态的流转逻辑要放在心上：车辆新增时默认空闲；管理员审核通过一个用车申请后状态改为使用中；车辆归还时再改回空闲；假如提交了维修申请，那就切换到维修中。这个状态机的调度逻辑适合放在Service层用枚举约束，避免前端乱传一个字符串导致数据不可控。实际工作中我还见过有人在数据库里用字符串字段存状态，最后统计报表钻取数据时发现各种缩写不一致，只能写一堆CASE WHEN兜底，这种教训在毕设阶段就应该规避掉。

3.3 前端Vue组件与交互逻辑的落地

前端部分建议用Vue + Element Plus的组合来快速搭建管理界面。列表页面无非是“搜索表单 + 表格 + 分页 + 弹窗新增/编辑”这个四件套。

这里给出一个表格页面的核心结构思路：

<template> <div class="vehicle-page"> <el-card shadow="never"> <el-form :inline="true" :model="searchForm" @submit.prevent> <el-form-item label="车牌号"> <el-input v-model="searchForm.plateNumber" placeholder="输入车牌号查询" clearable /> </el-form-item> <el-form-item label="车辆状态"> <el-select v-model="searchForm.status" placeholder="全部状态" clearable> <el-option label="空闲" :value="0" /> <el-option label="使用中" :value="1" /> <el-option label="维修中" :value="2" /> </el-select> </el-form-item> <el-form-item> <el-button type="primary" @click="loadData">查询</el-button> </el-form-item> </el-form> <el-table :data="tableData" border stripe> <el-table-column prop="plateNumber" label="车牌号" width="140" /> <el-table-column prop="brand" label="品牌" width="120" /> <el-table-column prop="model" label="型号" width="150" /> <el-table-column label="状态" width="100"> <template #default="{ row }"> <el-tag :type="statusTagType(row.status)"> {{ statusText(row.status) }} </el-tag> </template> </el-table-column> <el-table-column label="操作" width="220" fixed="right"> <template #default="{ row }"> <el-button size="small" @click="openEdit(row)">编辑</el-button> <el-button size="small" type="danger" @click="confirmDelete(row)">删除</el-button> </template> </el-table-column> </el-table> <el-pagination v-model:current-page="pageNum" v-model:page-size="pageSize" :total="total" layout="total, sizes, prev, pager, next" @current-change="loadData" /> </el-card> </div> </template>

交互细节上有几处需要特别留心。删除操作一定要加二次确认，用ElMessageBox.confirm弹窗提示用户“确定要删除该车辆吗”，避免误触导致数据丢失。表单校验可以用Element Plus自带的规则引擎，比如车牌号必填并且要用正则校验格式；购买日期不能晚于今天等等。这些细节在答辩演示时是加分项，老师能看到你考虑到了边界情况，说明这不是简单堆代码，而是真正在按产品的思路做项目。

3.4 前端调用接口的封装策略

前端和后端的通信不能散落得到处都是，合理封装能减少大量重复代码。建议在src/api目录下按业务模块拆分接口定义，同时封装一个统一的axios实例，把基础URL、超时时间、鉴权头都放在一起处理。

// request.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：统一携带Token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = `Bearer ${token}` } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response?.status === 401) { ElMessage.error('登录已过期，请重新登录') localStorage.removeItem('token') router.push('/login') } else { ElMessage.error('网络异常，请稍后重试') } return Promise.reject(error) } )

界面层的逻辑，分页数据和表格数据用一个对象统一维护。即使导师后期提出“加一个按品牌筛选的下拉框”或“表格加一列购买日期”，改动也只是加一个查询参数的问题。

4. 环境搭建与本地运行的五个关键

4.1 JDK与Maven的本地配置

拿到代码第一件事就是确认环境版本。JDK建议使用8或11版本，这两个版本的稳定性和SpringBoot的兼容性都经过了多年验证。直接在IDEA里配置Project SDK指向本机安装的JDK路径即可。Maven方面，重点检查settings.xml中的本地仓库路径和中央仓库镜像。

国内访问Maven中央仓库一直是个折磨。强烈建议在settings.xml中配置阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

配置好这个镜像后，下载SpringBoot相关依赖的速度能快上好几倍，还能大幅减少“依赖下载失败导致Idea报Red”的情况。Maven的依赖管理机制是自动递归拉取你声明依赖的上游依赖，所以明明只写了十几个依赖，实际下载下来会是几十上百个Jar包，这是正常现象，不用慌。

4.2 MySQL安装、初始化与数据导入

MySQL安装环节，网上教程铺天盖地，但有两个最常出问题的点要提前讲清楚。第一是版本选择，建议装5.7以上的稳定版，我自己用下来8.0也很流畅，但对于某些老项目而言，驱动包和连接配置可能有不兼容问题。第二是字符集问题，安装时一定要选UTF-8字符集，否则后续所有中文和查询条件辛辛苦苦编码都白搭。

数据库初始化时，项目根目录一般都会附带init.sql脚本，包含了建库、建表和基础测试数据。执行脚本前先确认数据库服务已经启动，然后按顺序执行：

mysql -u root -p < init.sql

执行完毕后会用SHOW TABLES或者开图形化工具检查关键表是否创建成功。如果你在连接数据库时遇到“SSL连接错误”或“Public Key Retrieval is not allowed”的报错，解决方式通常是在JDBC连接串上加上：

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

这段话的价值你们过上几遍就知道疼了，我第一次跑类似代码时栽在时区问题上，SpringBoot控制台抛出一大串关于serverTimezone的异常，当时愣是查了半天才发现原来是MySQL 8.0驱动与时区配置不对应。

4.3 前端依赖安装与代理配置

切换到vehicle-front文件夹后，执行npm install安装依赖。这个步骤通常需要几分钟，取决于网络状况和Node版本。这里要特别提醒Node版本太高可能带来的兼容性差异，如果执行npm run serve后出现类似“digital envelope routines::unsupported”的错误，那多半是Node 17以上版本与旧版webpack之间的坑。可以降级Node版本到16.14，或者在package.json中配置环境变量规避。

前端开发服务器的代理配置，是实现开发环境下前后端联调的关键。在vue.config.js中添加：

const { defineConfig } = require('@vue/cli-service') module.exports = defineConfig({ devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

通过这个代理，前端页面发往/api/login的请求会被转发到后端的http://localhost:8080/api/login，绕过了跨域浏览器的同源策略限制。这也是开发环境最简单的联调方式。

4.4 前后端启动顺序和统调思维

启动时推荐顺序是：先启动MySQL服务，确认数据库连接正常；然后启动后端SpringBoot服务，看到控制台输出启动耗时，确认没有报错；最后再启动前端Vue开发服务。启动前要在前端检查代理端口与后端端口是否完全一致，避免请求发送到了空端口上。

启动完成后打开浏览器访问http://localhost:8081，正常情况跳转到登录页。拿管理员账号登录，流程通了，系统就算跑起来了。开发模式里后端每次代码改动都可以通过DevTools热部署插件实现免重启，极大提高调试效率。建议把这一条加入到你的运行脚本中，真能省下不少重新刷新的时间。

5. 常见问题与排查技巧实录

5.1 跨域问题到底该怎么正确解决

跨域大概是前后端分离项目最让人头疼的问题之一。很多同学一遇到跨域就加上@CrossOrigin注解，前端再快手配置跨域代理，结果两边都加了，反而更乱。

跨域的解决只需选择一条路即可。开发阶段个人推荐用前端的代理进行转发，这不需要后端代码做任何改动，也符合前后端分离开发时“前端视角端到端联调”的习惯。如果做了前后端分离部署，生产环境下由Nginx统一转发后端接口请求，则同样不存在跨域困扰。只有在后端直接面向外部API时，才建议在SpringSecurity/拦截器配置里统一加上CORS配置，切勿在Controller方法上随手加注解。

这里把结论讲清楚：

场景	推荐方案
本地开发联调	前端devServer代理转发
生产环境部署	Nginx反向代理统一入口
后端单独开放API	全局CORS配置类统一处理

5.2 Maven依赖下载失败的两个深层原因

依赖下载卡住是IDEA里最讨厌的画面，解决办法看似复杂，但根源往往就两个。一个是仓库镜像不通或没有配置镜像，另一个是本地仓库里已经有下载了一半的临时文件，导致解析逻辑混乱。

排查思路：先看本地settings.xml是否配置了有效镜像，然后删掉本地仓库对应目录下的lastUpdated后缀文件，强制重新解析。如果看着像某个特定包被卡住，直接去Maven仓库官网搜索该包，确认最新版本号，手动下载Jar包放进本地仓库也是应急方案。

# Windows下快速清理失败缓存 find ~/.m2/repository -name "*.lastUpdated" -delete

这个问题在毕设答辩前夜遇到会让人崩溃，但提前了解了来源和措施，基本都是几分钟就能解决。

5.3 MySQL时区与连接参数引发的各类怪问题

除了前面提到的serverTimezone和useSSL，拼接JDBC连接串时还要注意URL中不能带着空格和多余的引号。连接参数冲突时MySQL的驱动会优先使用URL参数，也就是说application.yml中写的连接串参数优先级比数据库全局配置要高。如果你同时配置了数据库服务器的时区并且连接串里有别的时区，必须以连接串为准，这是排查时容易迷惑的一个点。

另外用Navicat连接远程或本地MySQL时，偶尔会遇到认证方式不对报错的情况，旧的Navicat版本对MySQL 8.0的 caching_sha2_password 新认证插件支持不完整，可能会提示连接失败。解决办法也不难：在MySQL命令行里执行：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码'; FLUSH PRIVILEGES;

扩展到项目运行阶段也一样，项目里的连接账号建议单独创建，只授权访问车辆管理系统的数据库，千万不要用root连生产库跑项目。虽然毕设只是本地演示，这个好习惯却能在你做真正项目时少被前辈们念很多遍。

5.4 车辆管理系统的扩展方向与答辩加分点

基础功能完善后，这个系统的可扩展空间非常大。比如增加仪表盘图表，统计各状态车辆的占比，车辆使用频率的月度趋势图；引入MinIO做文件上传，实现驾驶证、保险单照片的在线预览；加入Spring Boot整合消息队列，在提交用车申请后通知管理员；甚至加入定时任务，每天早上发送即将到期保养的车辆提醒邮件。

用表格把这些扩展方向整理一下：

扩展点	核心思路	涉及技术
数据可视化	通过ECharts图表展示车辆使用分析	ECharts + 聚合SQL
文件管理	车辆图片与证件扫描件上传/预览	MinIO + 前端预览组件
流程引擎	用车申请走审批流，管理员逐级审批	Activiti或状态机方案
消息通知	申请通过/被驳回时短信或邮件通知	Spring Boot Mail或阿里云短信

在答辩中把这些扩展方向和项目本身的衔接点讲出来，哪怕只是给出了需求分析和设计方案，也会体现你具备产品视野。比单纯背CRUD代码强很多。从这个系统的骨架中去看设计模式，看数据库三范式，看HTTP协议交互，这是一个能持续学习的老地基，毕业之后回头翻它也能常看常新。

我个人的体会是，这个系统的价值，不在于它的功能有多么宏大，而在于它是一个能让你完整亲历“设计—实现—测试—部署”全过程的载体。第一次调试时那个江郎才尽的感觉，第一次看到前端表格正确显示从数据库查出来的数据显示在网页上时的那种成就感，比任何教科书都来得深刻。跟着源码敲一遍，出错了自己排查，排查不过去再看答案，这套磨炼下来，SpringBoot+Vue这套开发组合对你来说就不只是面试题里的概念了，而是握在手心里的工具。等把这一套跑通，再回头看那些入门教程，你会有完全不一样的感受。