SpringBoot+Vue+MySQL车辆管理系统：从部署到二次开发实战

前阵子有个朋友找我，说单位里车辆管理还在用Excel登记，出差调车全靠微信群里吼，加油记录、保养周期、保险到期这些信息经常对不上账。问我有没有一套能直接跑起来的车辆管理系统源码，最好后端、前端、数据库全都给齐，省得自己从零搭。我翻了翻手头收集的项目，正好有一套SpringBoot后端+Vue前端+MySQL的车辆管理系统，导入就能跑。今天把这套系统的设计思路、部署过程、核心模块实现，以及我踩过的坑，一次说清楚。适合刚接触前后端分离项目的人参考，也适合想快速给单位或小组搭一套车辆信息台账的开发者。

1. 项目整体设计与技术选型解析

1.1 为什么是SpringBoot+Vue+MySQL这套组合

先说结论：这套组合在目前的中小型管理系统里，属于最常见、最稳、也最好招人的搭配。

SpringBoot是目前Java后端的事实标准。它把Spring繁琐的XML配置抽走了，内置Tomcat，一个main方法就能起服务，配合Spring Data JPA或者MyBatis，写增删改查的节奏非常快。而且SpringBoot 2.x版本生态特别成熟，网上能搜到的各种starter、中间件集成案例，基本都能直接搬。

前端Vue这边，组件化开发让页面复用变得很容易。车管系统这种后台管理界面，本质上就是一堆表单、表格、弹窗的组合，用Vue加上Element UI组件库，不用太久就能把所有页面骨架搭完。源码里用到的Vue Router做页面跳转，Axios做HTTP请求，状态管理Vuex，这三个组合是后台管理项目的标配。

MySQL更不用多说。关系型数据库，事务支持可靠，对于车辆申请、审批这类有状态流转的业务，ACID特性是刚需。要是换成NoSQL，给这种台账类业务做统计查询反而别扭。

为什么强调“可直接运行”？因为很多源码项目最大的问题不是代码差，而是环境依赖一团糟。这套源码在数据库脚本、配置文件、依赖版本上都做了收敛，拿到手不用改太多东西，启动流程相对顺滑。这一点下面展开讲。

1.2 功能模块划分：这套车管系统到底管了什么

我打开源码梳理过，这套系统的功能划分比较标准，属于“该有的都有”：

• 系统登录与用户认证：区分管理员和普通用户，管理员负责审批、维护基础数据，普通用户主要发起用车申请、查看自己相关的记录
• 车辆档案管理：维护车辆基本信息，包括车牌号、品牌型号、车辆类型、所属部门、购置日期、车辆状态、座位数等
• 用车申请审批：普通用户提交用车申请，管理员审核，审核通过后车辆状态变为占用，归还后解除状态
• 加油记录管理：记录加油时间、油品、油量、金额、当前里程
• 维修保养记录：记录维修项目、费用、维修厂、保养时间、下次保养提醒
• 保险、年检记录：记录保险起止日期、年检到期时间，方便提前续保和安排年检
• 驾驶员数据管理：维护驾驶员驾照信息、联系方式、所属部门

这些模块之间的数据关系并不复杂，核心就是围绕“车辆”这张主表展开。记住这一点，后边看代码的时候思路会清晰很多。

1.3 数据库表结构的核心设计

直接说几个关键表。

用户表（sys_user）：字段不外乎用户名、密码、姓名、手机号、角色类型、部门、状态。密码一般存的是加密后的哈希值，不要用明文。

车辆表（vehicle）：除了基本信息字段，一定要留一个status字段，用来标记车辆当前是否可调度。这个字段是整个用车流程里最关键的判断依据。车牌号建议加唯一索引，避免重复录入。

用车申请表（vehicle_apply）：外键关联用户ID和车辆ID，字段有申请原因、预计用车时间、实际用车时间、审批状态、审批意见、创建时间等。审批状态建议用数字枚举代替字符串，比如0待审核、1已通过、2已驳回、3使用中、4已完成，查询和统计都方便。

加油、维修、保险这些台账表，结构比较接近，无非是记录表 + 关联的车辆ID + 费用字段 + 时间字段。

注意：我在实际看过不少同类项目后总结，表名和字段名的命名一致性非常重要。这套源码里表名前缀统一、字段命名使用下划线风格，配合代码里的实体类映射，调试的时候能少花很多时间。

2. 快速部署与启动：从零到能登录

2.1 源码目录结构与环境准备

拿到解压后的源码包，先别急着跑，扫一眼目录结构。一般情况下是三个部分：一个后端目录，里面是Maven工程结构，src/main/java和src/main/resources；一个前端目录，里面是Vue项目；再一个sql或者database目录，放数据库初始化脚本。有些版本还会带README，优先看它。

环境版本建议按下面这个清单来：

• JDK 1.8（Java 8）。SpringBoot 2.x的项目用JDK 8最稳，不推荐直接用JDK 17，有些老依赖在JDK 17下会出反射相关的异常
• Maven 3.6以上，用来拉后端依赖
• Node.js 14或16。Vue 2项目在这两个Node版本下编译最稳定，Node 18在某些老项目的node-sass场景下会报错
• MySQL 5.7或者8.0都可以。如果项目用的MySQL驱动是5.x，连8.0数据库时需要留意认证插件的问题，建议直接用8.0数据库并调整连接串参数

如果你电脑上装过多个版本，切换版本前先确认一下环境变量，不然反复折腾容易崩溃。这块花费的精力可能比改代码还多。

2.2 数据库初始化步骤

拿到源码包后，一般在sql目录下会有脚本，这是整套系统的基础。

操作步骤：

1. 启动MySQL服务，用命令行或者图形化工具连接本地数据库
2. 创建数据库，比如执行CREATE DATABASE vehicle_management DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
3. 导入SQL脚本，可以在图形化工具中直接运行SQL文件，也可以执行mysql -u root -p vehicle_management < xxx.sql
4. 检查导入后的表清单，确认核心表是否齐全

字符集一定要用utf8mb4，否则后边存车牌号、生僻字或者特殊符号会出现乱码。这也是一个很常见的坑。

2.3 后端配置修改与启动

后端配置文件在src/main/resources/application.yml（也可能是application.properties），需要改的核心位置：

• spring.datasource.url：改成jdbc:mysql://localhost:3306/vehicle_management?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
• spring.datasource.username和password：改成你自己数据库的账号密码
• server.port：默认8080，如果被占用就改成8081之类的端口

改完配置文件，在项目根目录执行mvn clean package -DskipTests，然后进入target目录，用java -jar xxx.jar启动。也可以直接在IDE里导入Maven项目，找到启动类，右键运行。

第一次启动通常会卡在依赖下载，Maven会把所有依赖从中央仓库拉下来，速度看网络。如果下载时间太长，可以配置国内镜像源，在settings.xml里加mirror。

我实际测试时发现，如果项目里用了某些特殊版本依赖，Maven仓库没有收录，就会报Could not resolve dependencies。遇到这个问题，先检查仓库地址是否需要额外配置，再看本地Maven仓库有没有残留的损坏包，清空后重新拉取。

2.4 前端启动与跨域处理

进入前端目录后：

1. npm install安装依赖。如果网络慢，先把镜像源切换到国内npm镜像，执行npm config set registry https://registry.npmmirror.com
2. npm run serve（Vue CLI项目）启动开发服务器，默认端口通常是8080。前后端端口可能都是8080，需要调整其中一个
3. 打开浏览器访问前端地址，正常情况下会跳到登录页

这里最关键的坑就是跨域。前端在8080跑，后端也在8080跑，浏览器会拦截跨域请求。处理方式一般有两种：

• 在后端加入CORS配置类，允许前端地址跨域访问
• 在前端配置代理，把/api开头的请求转发到后端地址

源码里用的推荐方案是前端代理，在vue.config.js里配置devServer.proxy，把请求转发到http://localhost:8080。这样浏览器只和前端交互，跨域问题自然消失。

项目实际跑起来后，界面就是标准的后台管理样式：左侧菜单，首页、车辆管理、用车申请、台账记录、系统管理。右上角有用户头像和退出登录。

3. 核心功能模块实现拆解

3.1 登录认证与权限控制

登录流程不是简单的前后端不设防模式。后端会校验用户名密码，生成令牌（常用方案是JWT或者UUID Token），前端把Token存在本地，每次请求把它塞到请求头里。

后端通过拦截器或者过滤器统一校验Token，没有Token或Token失效的请求直接返回401或者一个自定义错误码。具体到项目里，通常会有一个自定义注解，比如@AuthRequired，标在需要登录的Controller方法上。

前端路由也有守卫逻辑，在router的beforeEach钩子里判断本地Token是否存在，不存在就跳转登录页。这种双重控制虽然不算高级，但对管理类系统足够用了。

真正做生产级权限控制时，建议把RBAC做完整。这套源码把管理员和普通用户分开，算是RBAC的简化版，二次开发时可以扩展。

3.2 车辆档案管理：CRUD的细节比想象中多

车辆档案管理模块，后端提供车辆列表分页查询、新增、修改、删除、详情等接口。

分页这块，源码如果用MyBatis-Plus，直接在ServiceImpl里调用page(new Page<>(pageNum, pageSize), queryWrapper)就行。如果是传统MyBatis加PageHelper，也就是startPage之后紧跟一个查询方法的写法。逻辑上都不复杂。

车辆状态这个字段要重点说。车辆状态一般有：0可用、1占用、2维修中、3报废。不同的状态会直接影响新车登记、编辑和用车申请时的展示逻辑。比如管理员新增车辆时，车辆状态自动设为可用；提交维修单后，状态可以手动或自动改为维修中。

细节提醒：编辑车辆时，车牌号的校验不能省。我见过有人直接把车牌号字段去掉校验，结果录入的数据格式五花八门。针对新能源车牌和普通蓝牌分别做正则校验，能避免很多后续对账的问题。

3.3 用车申请审批流程：状态流转最容易踩坑

这是整套系统的核心，也是业务逻辑最集中、最容易写错的地方。

流程：用户提交申请 -> 管理员审核 -> 车辆状态占用 -> 使用完成、归还车辆 -> 状态释放。

状态流转在后端实现时，通常用一个状态字段控制。提交申请时生成申请记录，状态为待审核；管理员点击通过，状态变为已通过，同时把对应车辆的状态改为占用；用户使用完毕，在系统中点归还，状态变为已完成，车辆状态恢复为可用。

这里有一个很容易踩的坑：并发冲突。如果前端在选车列表上没有实时同步车辆状态，两个人同时提交同一辆车的申请，会造成同一辆车在同一时段被重复申请。解决办法要么在查询时过滤掉已占用和待审核状态下的车辆，要么在后端加一层校验：审核的时候再查一次车辆当前状态，若不可用则直接提示拒绝。

如果业务上需要做时间段重叠判断，最好把申请字段里的预计用车时间和预计归还时间都纳入查询条件。不想做复杂时间重叠计算的话，最简单粗暴的办法就是：同一辆车同一时间段内只允许一条有效申请，审核时就校验时间区间，冲突的直接打回。

3.4 加油、维修、保险台账管理

台账模块本质上是围绕vehicle_id的增删改查。

加油记录的典型字段：车辆、加油日期、油品型号、加油量（升）、单价、金额、当前里程、加油站。录入后，系统可以在车辆列表或者车辆详情页展示最近N次加油记录，方便核算百公里油耗。

维修保养记录模块要注意“下次保养提醒”这个逻辑。一般有两种实现：

• 定时任务方式：每天跑一次，查询所有车辆的最近保养时间，和当前时间比对，如果超过设置间隔且没有新保养记录，就发送提醒通知
• 查询计算方式：展示车辆列表时，动态计算每辆车距离上次保养的里程数或天数，超过阈值列表上就用警告色标识

两种方式各有优劣。定时任务适合做通知，查询计算适合在界面展示。我一般把两种结合起来：列表展示警告色，定时任务负责推送提醒，比如每天向管理员推送临近保养和保险到期的车辆清单。

保险、年检记录的核心是到期时间。提前30天、7天分别做一次提醒，行政人员就能从容安排续保和年检，不用等到过期才发现。

3.5 统计报表模块

如果源码里带了统计图表，那大概率是用ECharts处理的。常见图表包括：

• 每月用车次数柱状图
• 各部门用车占比饼图
• 月度加油费用折线图
• 车辆利用率排名

统计接口在后端一般用SQL聚合实现。比如按月统计用车次数，SQL里用GROUP BY DATE_FORMAT(create_time, '%Y-%m')，返回给前端渲染。注意GROUP BY之后的结果集顺序不稳定，最好再order by一下月份字段。

没有统计模块的话，二次开发也很简单：前端新增一个页面引入ECharts，后端补一个聚合查询接口，很快就能搞定。

4. 项目运行效果速览

先说说跑起来的整体样子，方便你知道自己在看什么。

登录页是标准的管理系统样式，左侧背景，中间登录卡片，下方版权信息。默认账号一般是admin/admin123之类，以源码README为准。这类系统容易忘记给初始登录一个明显的账号提示，拿到手先看README，别直接乱试密码，容易把自己锁晕。

登录后主界面左上角是系统logo和名称，左侧菜单按模块排列。车辆管理页面是一个标准表格：车牌号、车辆类型、所属部门、驾驶员、状态、操作列。操作列里有编辑、删除、详情。新增车辆通过右上角的按钮弹窗表单实现。

用车申请页面比较关键。用户提交申请时，车辆下拉框里应该只能看到当前状态为可用的车辆，如果不可用车辆也出现在选项里，说明后端筛选逻辑没做完整。申请提交后，在“我的申请”或“申请审批”页面可以看到记录，管理员操作通过或者驳回。

台账页面是几个tab切换：加油记录、维修记录、保险记录、年检记录。每个tab里都支持按车辆筛选、时间筛选。

系统管理部分，一般是用户管理和角色管理，管理员可以重置密码、启停账号。

整体界面的交互逻辑很直观，哪怕之前没接触过这个项目，点点左侧菜单也能猜个八九不离十。

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

这部分是我觉得整套源码从部署到使用最值得看的内容，很多问题我在现场调试时都遇到过。

再补几个不那么常见但很折磨人的问题。

一个是上传图片或附件时报空指针。大部分车管系统会涉及驾驶证照片、行驶证照片的上传，如果源码里用了本地文件存储，运行时需要指定一个可写的文件目录，比如D:/upload/或者/usr/local/upload。Linux服务器上目录没创建或者权限不足，就会触发FileNotFoundException。解决方式是把上传目录改成当前用户可读写的位置，或者在配置文件中指定完整路径。

另一个是低配机器上启动后端时内存不足。IDE启动或者执行java -jar时报OutOfMemoryError，可以在启动参数中加-Xms256m -Xmx512m缓解。我还遇到过Maven build时卡死的情况，一般是在MAVEN_OPTS里把堆内存调大一点。

再有一个是前端控制台会报一些vue警告，比如“property xx was accessed during render but is not defined on instance”。这类警告不影响使用，但介意代码整洁的话，就在data()里提前声明所有用到的变量，别以为它不会出现就不管。

6. 二次开发与扩展方向

6.1 权限体系完善

我建议把角色拆成更细的粒度，比如车管员、部门管理员、普通用户三档。车管员能维护车辆和审批申请，部门管理员只能看到本部门数据，普通用户只能发起申请和查看个人记录。后端用Spring Security加自定义权限注解实现，改造量不算太大，但权限边界清晰后，后续加功能心里有底。

6.2 消息提醒接入

实际部署到单位后，管理人员不可能天天挂在系统上。可以接入企业微信群或钉钉群机器人Webhook，在“新申请待审批”“保养到期”“保险到期”这些节点自动推一条消息到群，体验会好很多。实现方式也不复杂，就是在对应业务方法里请求一次Webhook地址，把内容POST过去。

如果有内网邮件系统，也可以加邮件通知。SpringBoot对接JavaMail很简单，配置文件里设置邮箱服务地址和账号密码，再写一个消息服务类封装发送逻辑就行。

6.3 车牌识别与定位追踪

如果业务上需要车辆实时位置，可以在车辆详情页接入地图组件展示位置，后端对接定位平台的API。核心改造是车辆表增加设备ID字段，定时任务同步位置信息，数据库保留近期轨迹点。

再往后还能扩展车牌识别、ETC流水对账，不过那就需要硬件和第三方接口配合了，不是在纯软件源码里能简单模拟的。

6.4 数据备份与安全

真正上线使用前，至少做两件事：一是修改默认管理员密码，二是配置数据库定时备份。MySQL备份最简单的方式就是写个定时任务执行mysqldump命令，备份文件按日期命名，保留最近三十天。SpringBoot服务端注意不要把数据库账号密码硬编码在配置文件里，重要环境用环境变量覆盖。

7. 一些个人经验

最后聊几句实在的。这套源码我前后在几个场景里跑过，包括课程设计、小团队内部车辆调度、几个人合作做毕设时作为基底。整体感觉是：结构清爽，功能覆盖够用，数据库脚本完整，对初学者友好，对有一定经验的开发者来说，它更像是一个可以直接站在上面改的底座。

实际使用中最容易出问题的不是代码，而是环境。很多人在部署阶段就被Node版本、Maven仓库、数据库编码这些问题劝退，所以我特别强调先把环境照上面梳理好再动手。

如果你想在这套源码上加新功能，我建议先花半小时把数据库表之间的关系画出来。理解了表关系，改字段、加接口、调前端，都会很有方向感。不要急着看代码逻辑，先看数据模型。

再叮嘱一遍：部署到生产环境之前，请一定认真确认默认账号密码改没改，数据库密码强度够不够，后端服务要不要用Nginx做反向代理和HTTPS，数据备份有没有配置。我见过不少项目倒不是说功能不好，而是安全意识欠缺，被人拿到后台一顿乱操作，再好的系统也白搭。

好了，关于这套SpringBoot+Vue+MySQL车辆管理系统的解析就先写到这里。如果你在部署或者二次开发中遇到什么奇怪的问题，欢迎留言，我看到了会尽量回复。