SpringBoot+Vue+MySQL车辆管理系统全解析：从设计到部署避坑

搞开发这么多年，接手过不少管理系统项目，我自己的体会是：车辆管理系统是“麻雀虽小五脏俱全”的典型代表。单看这个标题——SpringBoot后端、Vue前端、MySQL数据库、可直接运行——其实已经把一套完整项目的技术栈和交付标准都交代清楚了。这类系统非常适合做课程设计、毕业设计，也很适合小企业直接改改就用。今天我就以这套源码为蓝本，把整个项目的设计思路、核心实现、运行部署和避坑经验完整拆一遍，希望能给正在做类似系统的朋友一点实际参考。

1. 项目全貌：先读懂这套源码能干什么

1.1 车辆管理系统的业务边界

很多人一听“车辆管理系统”，以为就是给车辆做个增删改查，其实没那么简单。真正能落地运行的管理系统，核心在于业务闭环：车辆从采购入库、建档登记，到日常的出车申请、领导审批、驾驶员指派，再到归还登记、里程记录、维修保养、保险续期，最后到报废淘汰——每一个环节都要有数据记录，每一笔记录都要能追溯。

我拿到这套源码的第一反应就是去看它的数据表设计，因为表结构直接决定了业务边界。通常一个完整的车辆管理系统至少要包含这几个核心实体：车辆档案、驾驶员档案、用车申请单、审批记录、维修保养记录、保险记录、系统用户。它们之间的关系并不复杂，但关联逻辑要理清楚：一个驾驶员可以驾驶多辆车，一辆车也可以被多个驾驶员驾驶，所以用车记录表一般会同时冗余车辆ID和驾驶员ID，方便统计。

这套源码的核心价值正在于此：它把上面这些业务都串起来了，而不是零散地做几个孤立页面。从登录进系统到看板统计，再到车辆列表、驾驶员管理、用车审批、维保管理，整个流程是完整的。这种完整性在课设答辩和实际演示中特别加分。

1.2 这套系统的目标用户与适用场景

先说结论：这套系统适合三类人。

第一类是在校学生，尤其是做毕业设计或者课程设计的。现在高校对管理系统类项目的常见要求就是前后端分离、数据库设计规范、功能完整、界面美观，这套SpringBoot+Vue+MySQL的方案完全覆盖这些要求。更重要的是，标题里明确写了“可直接运行”，这意味着拿到源码后不需要自己从头搭框架，把精力集中在理解业务和准备答辩上。

第二类是中小型企业的行政或车队管理人员。真实场景下，一个几十辆车的小车队，用Excel管台账很容易乱，用SaaS平台又太贵太重，这种自托管的开源式管理系统反而是性价比极高的选择。改个Logo、调几个字段、配上公司自己的数据库，就能上线使用。

第三类是刚入行的Java开发工程师。说实话，这种“教科书级”的完整项目非常适合用来学习主流框架的整合方式：SpringBoot到底怎么配置、MyBatis-Plus怎么用、JWT认证怎么落地、Vue路由守卫怎么做、前后端怎么联调。跟着源码敲一遍，比自己东拼西凑看教程效率高得多。

1.3 功能模块全景与业务闭环

从页面和接口反推，这套系统的功能模块大致分为六大块：

• 系统管理：用户管理、角色管理、菜单管理和登录退出，这块是所有管理系统的地基。
• 车辆档案管理：录车牌号、品牌型号、车辆类型、座位数、车架号、发动机号、购买日期等，支持照片上传和状态维护。
• 驾驶员管理：姓名、驾驶证号、准驾车型、电话、入职日期等档案，附带驾驶证到期提醒。
• 用车审批流程：申请人提交用车申请，填写时间、事由、预计里程，管理员或领导审批，审批后生成出车记录。
• 维保管理：登记维修和保养记录，记录费用、里程、维修厂、起止时间，能够查看维保历史，并有保养周期提醒。
• 统计报表：基于ECharts展示车辆使用率、费用分布、维保趋势等图表，辅助管理决策。

这个模块划分的思路很清晰：以车辆档案为核心，以流程审批为主线，以到期提醒为亮点。如果你在答辩时被问到“你这个系统有什么亮点”，这三句话基本就能镇住场面。

2. 技术选型：为什么是SpringBoot+Vue+MySQL

2.1 后端选型：SpringBoot到底解决了什么

SpringBoot现在几乎成了Java后端开发的默认起点。它最大的价值不是新发明了什么技术，而是把Spring原有的那套繁琐配置大幅简化了。以前用Spring搭建一个Web项目，要手写一堆XML配置文件，还要操心第三方库的版本兼容问题；SpringBoot通过自动配置机制，根据classpath上的依赖自动装配，你只需要在pom.xml里加上spring-boot-starter-web，就能直接写Controller跑起来。

这套源码用SpringBoot是合理的选择，因为它对课设和中小企业项目非常友好：内嵌Tomcat，打包成jar直接运行，不需要单独装应用服务器；生态成熟，面试和答辩时能讲的东西也多；配合MyBatis-Plus做数据访问层，CRUD代码量可以压缩一大半。

要提醒的是版本对应关系。SpringBoot 2.x版本对应JDK 8或11，SpringBoot 3.x版本则要求JDK 17。如果你电脑装的是JDK 8，硬要用3.x的源码启动，会直接报ClassNotFoundException。我遇到过不少同学在这里卡壳，下载源码后先看pom.xml里的spring-boot-starter-parent版本，再检查自己的JDK版本，这是启动项目前的第一步。这也是最近“springboot版本太高”这个热词对应到实际问题——版本差异带来的一连串兼容性错误。

2.2 前端选型：Vue的核心优势与组件化逻辑

Vue在国内前端圈的地位不用多说，它的核心优势在于渐进式框架的灵活性和单文件组件的开发效率。对于管理系统这种以表格、表单、弹窗、菜单为主的项目，Vue配合Element UI（或用Vue3就是Element Plus）简直是一对黄金搭档：.vue文件里把HTML结构、JavaScript逻辑和CSS样式封装在一起，组件之间的复用非常直观。

以车辆列表页为例，页面上方是一个查询表单，中间是表格，下方是分页器，右侧有新增、编辑、删除按钮。如果不用框架，直接操作DOM会写大量重复代码；而用Vue，这些都被拆成小组件：el-table负责表格渲染，el-pagination处理分页，el-dialog承载新增编辑表单，数据通过data对象双向绑定，逻辑清爽得不止一点半点。

另外Vue Router的路由配置也值得一提。这套系统的前端会把页面分为登录页和主布局页两大区域：登录页是独立的 /login 路由；主布局页 / 下面挂载多个子路由，比如车辆管理、驾驶员管理、审批管理等。路由守卫可以在跳转前检查本地是否有token，没有就强制回到登录页——这个小细节是整套系统安全性的第一道防线。

2.3 数据库选型与表关系设计思路

MySQL作为后端的主力数据库，优势就四点：免费、稳定、资料多、环境容易搭。对于车辆管理系统这个体量，单机MySQL完全够用，核心表的数据量就算到十万级，配合合理的索引和分页查询也不会吃力。

表关系设计上，我梳理一下这套源码里常见的关联逻辑：

• 车辆表（vehicle） 与**驾驶员表（driver）是多对多关系，通过用车记录表（usage_record）**来关联。
• 用户表（user） 与用车记录表是一对多关系，申请人申请多条记录。
• 车辆表与**维保表（maintenance）**是一对多关系，一辆车有多次维修保养记录。
• 车辆表与**保险表（insurance）**也是一对多，一辆车在不同年份有不同的保险单。

这种设计的核心思想是避免冗余，通过外键关联保证数据一致性。有些人喜欢在车辆表里加几个字段直接存“最近保养里程”“最新保险到期日”，这样做查询方便，但维护起来很痛苦；更合理的做法是让维保表和保险表各自记录自己的业务数据，页面展示需要“最新状态”时通过SQL查询或子查询取最新记录。这套源码在这一点上做得比较规范。

2.4 认证方案：JWT+拦截器的实现思路

管理系统的登录认证，老一点的项目用Session，前后端分离的项目主流方案是Token，更具体的说就是JWT（JSON Web Token）。为什么不用Session？因为前后端分离后，前端可能跑在8081端口，后端跑在8080端口，Session依赖Cookie跨域传递，配置起来很麻烦；而JWT把用户信息加密后放在Token里，前端每次请求在请求头带上Authorization: Bearer token即可，后端无状态校验，天然适配前后端分离架构。

这套源码里的典型实现流程是：用户提交用户名密码，后端用BCrypt加密校验密码（不存明文），校验通过后使用io.jsonwebtoken生成一个带过期时间的Token返回前端；前端存到localStorage或sessionStorage；后续请求由Axios拦截器统一在请求头添加Token；后端的拦截器或OncePerRequestFilter拦截所有非登录接口，解析Token判断有效性。

我特别想说一下密码加密。前几年不少课设项目喜欢直接用MD5存密码，稍微撞一下库就能还原。用BCrypt的好处是它内部实现了加盐和随机化，同样的密码每次生成的哈希都不一样，安全性完全不在一个量级。答辩时如果能主动提一句“密码用了BCrypt加密存储”，老师对你的印象会立刻不一样。

3. 核心功能模块与数据库设计实战

3.1 车辆档案模块的设计要点

车辆档案是整个系统的数据基石，所有其他功能几乎都依赖这张表。我在看这套源码时重点关注了车辆表的字段，典型的必备字段是：

• plate_no：车牌号，全局唯一，这是车辆在系统里的身份证。
• brand、model：品牌和型号，用于车辆基本信息展示和筛选。
• vehicle_type：车辆类型，比如轿车、SUV、客车、货车，在审批和统计中会按类型分组。
• status：车辆当前状态，我见过不同系统用不同枚举，常见的有 可用、出车中、维修中、已停用。这里的坑在于状态更新要同步做：审批出车时车辆状态要改成“出车中”，归还时要改回“可用”，维修登记时改成“维修中”，否则看板数据会失真。
• mileage：当前里程，这个字段要注意只增不减。一旦出现里程回退，基本就是录入错误或人为篡改，会让后续维保周期计算全部乱套。
• photo：车辆照片路径，一般用字符串存URL地址或相对路径，文件本身存在后台上传目录。

车牌号的唯一性校验是整个模块最容易踩坑的地方。新增车辆时如果没做重复检查，等到车辆列表出现两条同牌号数据，后续的里程统计、费用统计全部会串数据。所以保存接口里一定要先按plate_no查一次，存在就返回“车牌号已存在”的提示。

3.2 驾驶员管理与证件到期提醒

驾驶员表的核心不只是基本信息，关键是驾驶证有效期管理。现实中驾驶证到期不换证，驾驶员就不能合法上路，所以系统里必须记录license_start_date和license_end_date。

这块功能最出效果的实现方式是首页看板上的到期提醒卡片：离驾驶证到期不足30天或者已经过期的，用橙红色高亮显示。这个功能的实现并不复杂，后端写一个定时任务或查询时用SQL的DATEDIFF函数筛选出到期时间距今小于等于30天的驾驶员即可。可别小看这个提醒，它往往是整套系统里最容易被评审老师认可的“业务价值点”。

驾驶员和车辆的绑定关系也要注意。有的系统设计成“一个驾驶员固定绑定一辆车”，这在小公司可行，但业务上不够灵活。更好的设计是通过出车记录来动态绑定，驾驶员A今天开1号车，明天开2号车，都由审批通过的出车单决定，这样回看历史时，“某辆车某天由谁驾驶”就一清二楚了。

3.3 用车审批流程与状态流转

审批流程模块是管理系统类项目的核心加分项，因为它体现了业务流程建模能力。

一个标准的用车审批流程是这样的：申请人填写用车申请——选择车辆、起止时间、事由、预计里程——提交后生成状态为“待审批”的记录；审批人（一般是管理员角色）在待审批列表里看到申请，点击通过或驳回，填写审批意见；审批通过后，车辆状态自动变为“出车中”；后续驾驶员出车、归还时再分别填写实际里程和实际时长，状态变为“已归还”。

这套源码如果按这个逻辑来实现，数据表里一定有一个audit_status字段，建议用整数或短字符串存，例如0待审批、1已通过、2已驳回、3已完成。用数字存的好处是查询排序方便，但可读性差，所以前端展示时一定要用数据字典或枚举转换。我看到不少项目不做转换，页面上直接显示个0或1，体验很差，这个细节要注意。

还有一个非常容易被忽略的设计盲区：审批通过后，如果记录被删除了怎么办？ 严谨的做法是逻辑删除，也就是维护一个is_deleted字段，默认0，删除时改为1，查询默认过滤掉已删除的数据。业务单据不能物理删除，因为后面可能涉及对账和审计，真的需要删时也应该走“撤销”或“作废”流程。

3.4 维保、保险与到期定时任务

维保和保险模块是车辆生命周期管理的重要内容。维保记录表至少要有这些字段：关联车辆ID、维保类型（维修还是保养）、金额、当前里程、维修内容/项目、维修厂商、开始日期、完成日期。

保养提醒的逻辑我要单独说一下。现实生活中保养周期有两种算法：按时间（比如每半年一次）和按里程（比如每8000公里一次）。系统里实现时，最简单的做法是在车辆表里冗余一个next_maintain_mileage或next_maintain_date字段，每次保养完成时自动计算并更新下次保养节点。随后定时任务每天扫描一次，发现到达或超过节点的车辆就生成提醒。

保险模块的核心是险种和到期日。交强险和商业险的到期日可能不同，所以保险表里要有type字段区分险种，同时记录起止日期。到期提醒的逻辑类似：提前30天提示续保，过期没续保的标红。

这里会用到SpringBoot的定时任务。在启动类上加@EnableScheduling，然后在提醒服务类里加@Scheduled(cron = "0 0 2 * * ?")，意思就是每天凌晨两点执行一次。定时任务跑出来提醒数据后，存入一张提醒表或者直接写入Redis，前端加载看板时读取即可。用cron表达式没什么难的，但要注意服务器时区问题，如果部署环境设置了非北京时间，任务执行时间会偏，最好在Application配置里固定spring.jackson.time-zone和系统时区。

4. 后端构建细节：SpringBoot核心代码拆解

4.1 工程结构与统一响应体设计

我打开这套源码时，第一步看的就是包结构。一个干净的后端工程大概长这样：

code复制com.vehicle.system
├── controller        // 接口层
├── service           // 业务层
│   └── impl
├── mapper            // 数据访问层
├── entity            // 实体类
├── dto               // 入参/出参对象
├── config            // 配置类（拦截器、跨域、定时任务）
├── common            // 公共类（统一结果、异常、常量）
└── util              // 工具类

这种分层从Controller到Service再到Mapper，每一层各司其职，是Spring项目最主流的组织方式。尤其是entity和dto分离这个细节：实体类对应数据库表结构，不应该直接暴露给前端；前端传参用dto对象接收，可以限定字段、做参数校验，防止前端传入了实体类里根本没有的字段造成异常。

统一响应体是另一个容易被忽略但非常重要的设计。后端接口如果有的返回Map，有的直接返回List，有的返回null，前端处理起来就会非常混乱。规范的做法是定义一个泛型结果类Result<T>，包含三个字段：code（状态码）、msg（提示信息）、data（实际数据）。正常返回时code=200，业务异常时code=500，未登录时code=401。前端Axios响应拦截器里依据code统一处理成功、报错和跳转登录页，整套联调体验会顺畅得多。

4.2 接口设计与参数校验

接口设计遵循RESTful风格基本是标配，但在实际项目里，我更建议按“模块+动作”的方式来命名，不要过度追求所谓纯REST标准。比如车辆管理模块：

• GET /api/vehicle/list：分页查询车辆列表，支持关键词搜索。
• GET /api/vehicle/{id}：获取车辆详情。
• POST /api/vehicle：新增车辆。
• PUT /api/vehicle：修改车辆信息。
• DELETE /api/vehicle/{id}：逻辑删除车辆。

参数方面，分页参数通常就是pageNum和pageSize，配合MyBatis-Plus的Page对象，一行代码完成分页查询。搜索条件用@RequestParam(required = false)接收，避免前端没传对应字段时直接报400。

参数校验要用@Validated注解结合@NotNull、@NotBlank、@Size等注解在dto字段上做。比如新增车辆时，车牌号不能为空、车辆类型必须在枚举值范围之内。校验失败后全局异常处理器会捕获MethodArgumentNotValidException，把具体的错误信息返回给前端，前端就能在表单控件下方直接展示“车牌号不能为空”这类提示。做完整的前后端交互，参数校验这一环必不可少，很多源码省掉了这个细节，导致前端可以传任意的垃圾数据进后台。

4.3 Controller、Service、Mapper的分层约定

用MyBatis-Plus时，Mapper接口继承BaseMapper<T>，基础的增删改查方法就都自动拥有了。Service接口继承IService<T>，实现类继承ServiceImpl<Mapper, T>，复杂业务则写在实现类里。

我特别想说说业务放哪一层的问题。很多初学者喜欢在Controller里直接写业务逻辑，数据库查询完直接在控制器里加工返回。这个习惯短期写起来很爽，但一旦业务复杂起来，Controller会膨胀得无法维护。规范的做法是：Controller只负责接收参数、调用Service、返回结果，一切业务逻辑都封装在Service层。比如“提交用车审批时同时修改车辆状态”，这个联动逻辑就必须放在Service里，用@Transactional事务注解保证这两步操作要么同时成功，要么同时失败。

这里有个很重要的关键词：事务。用车申请提交时，要插入一条用车记录，同时把车辆状态改成“出车中”。如果先插入记录成功后，改状态那步因为网络原因失败了，数据就出现不一致：车明明被用着但状态显示可用，下一单还能接着申请。@Transactional就是来解决这个问题的，它保证这两个数据库操作在同一个事务里执行，任何一个失败都会回滚全部操作。这样“逻辑闭环”的实现才算真正落地。

4.4 全局异常处理与日志记录

全局异常处理是SpringBoot项目里最“润物细无声”的模块，它不直接产生业务功能，但直接影响系统的健壮性和调试效率。

实现方式是建一个@RestControllerAdvice类，在里面定义多个异常处理方法，用@ExceptionHandler声明要捕获的异常类型。比如：

• MethodArgumentNotValidException：捕获后返回参数校验错误信息。
• BusinessException：自定义业务异常，比如车牌号重复、审批人不能审批自己的申请，返回业务提示。
• Exception：兜底捕获所有未预料到的异常，记录日志并返回“系统繁忙”之类的中性提示。

日志记录方面，用slf4j的Logger在每个Service的关键方法里打info和error日志，字段上重点记录操作人、操作内容、接口耗时。这些日志不仅是排查线上问题的重要依据，也是项目答辩时体现工程素养的加分项。如果你还想做得更规范，可以引入AOP统一记录操作日志到日志表里，实现“谁在什么时间对什么数据做了什么操作”的审计追踪。

5. 前端实现细节：Vue项目开发实录

5.1 前端工程结构与路由守卫

前端工程用Vue CLI或Vite搭建。经典的结构是：

code复制src
├── api          // 接口定义模块，按业务拆分为vehicle.js、user.js等
├── assets       // 静态资源
├── components   // 通用组件
├── router       // 路由配置
├── store        // Vuex或Pinia状态管理
├── views        // 页面组件
│   ├── login
│   ├── dashboard
│   ├── vehicle
│   ├── driver
│   ├── audit
│   └── ...
└── utils        // 工具函数，特别是axios封装

路由守卫是整个前端安全机制的枢纽。用户在地址栏直接输入 /vehicle/list，但还没登录，就会被router.beforeEach拦下来，判断是否持有有效token，如果没有就重定向到 /login?redirect=/vehicle/list，登录成功后自动跳回目标页。这个细节不仅提升了用户体验，还保护了所有页面不被直接绕过登录访问。

路由配置里还要注意动态路由和按钮级权限的区分。如果做的是更复杂的多角色系统，可以根据当前登录用户的角色返回对应的菜单列表，再通过addRoute方式动态挂载路由，实现不同角色看到不同菜单。如果只是简单课设，通常在路由配置里写死路由表，用角色字段控制菜单显示。这套源码若是以“管理员”和“普通用户”两种角色为例，管理员拥有全部菜单，普通用户只看到车辆查询、申请用车和个人中心。

5.2 Axios封装与Token处理

前端和后端通信，axios是事实标准。作为有追求的开发者，一定不要把axios直接用得到处都是，必须二次封装。

封装后的request.js要解决这几件事：基础URL统一配置（开发环境用/api前缀走代理，生产环境用完整后端地址或同域相对路径）、请求拦截器、响应拦截器、错误提示统一处理。

请求拦截器里从localStorage取出token，拼成Authorization: Bearer xxx加到请求头。响应拦截器里判断后端返回的code字段：如果等于200，直接返回data；如果等于401，说明token过期或未登录，清空本地登录信息，跳转登录页；如果等于500，用Element UI的Message.error统一弹出后端返回的msg。

这里有一个小坑必须说一下：文件上传接口的响应格式不是JSON，而是文件流。如果统一走响应拦截器判断code，它拿不到字段，会误判为异常。解决办法是在上传请求的方法上设置responseType: 'blob'或单独封装一个uploadRequest，绕过统一处理逻辑。这些小细节往往是源码和“玩具代码”的分水岭。

5.3 核心页面实现思路

车辆管理页面是整套前端系统的门面。列表页的实现套路其实很固定，但细节好坏差很多：

顶部是搜索栏，用el-form配合inline模式，放车牌号输入框、车辆类型下拉框、状态下拉框，点击“搜索”触发列表查询，点击“重置”清空条件并重新加载。

中间是按钮区，新增、批量删除、导出Excel等操作按钮，权限控制决定这些按钮是否显示。

下方主体是el-table，列字段绑定对应的数据属性。需要注意的是状态列的显示转换：后端返回的是status=1，前端不能直接显示“1”，要用formatter函数或计算属性转换成“可用”“出车中”“维修中”“已停用”。同理，日期字段一般后端返回2024-05-12 14:30:00这样的字符串，如果数据库存的是datetime，后端要做好格式化，否则前端拿到YYYY-MM-DDTHH:mm:ss格式会显示得很难看。

新增和编辑用同一个el-dialog，内部是el-form表单。关键技巧是editDialogVisible和formData的配合：新增时formData重置为空对象，编辑时先通过行数据回填再弹出。保存时调用不同的接口，成功后关闭弹窗、刷新列表、弹出成功提示。这三板斧做完，基本就是一个可用的管理页面。

5.4 数据可视化与图表模块

首页看板是整个系统最容易出视觉效果的部分，也是体现项目“高级感”的地方。

常见的数据看板包括：车辆总数、驾驶员总数、今日出车次数、待审批申请数、近30天维修费用、车辆使用率排行。这些数据从后端提供一个DashboardController的聚合接口返回，前端用卡片和ECharts图表展示。

用ECharts时，核心是option对象。柱状图展示每月费用，饼图展示车辆类型分布，折线图展示近六个月出车次数趋势。因为这些图表都是异步数据驱动，一个常见错误是图表渲染时数据还没回来，导致图表空白。解决办法是：用v-if控制图表的渲染时机，等数据加载完成后再创建图表实例；或者用nextTick确保DOM渲染完成后再初始化。还有一个技巧是窗口大小变化时调用chart.resize()，不然浏览器缩放后图表会变形。

ECharts主题的问题我提一下：默认主题偏基础，答辩时如果想加分，可以自定义配色，统一成和系统主色调一致。这种细节上的用心，评审老师一眼就能看出来。

6. 从源码到运行：环境搭建与部署实战

6.1 环境准备清单

拿到源码后第一件事，不是急着npm run dev，而是先检查本机环境。根据这套系统的技术栈，我建议按下面清单确认：

这里我要单独强调一下Node版本的问题。新版Node.js（尤其18以上）对旧版本Vue CLI项目有时会出现OpenSSL相关的报错：Error: error:0308010C:digital envelope routines::unsupported。遇到这个报错，要么降Node版本到16，要么在启动命令前加上NODE_OPTIONS=--openssl-legacy-provider。这个坑对刚接触前端的人很折磨，网上查半天也未必能找到原因。

6.2 数据库初始化与配置修改

数据库这块是“开箱即跑”的关键。拿到源码后，一般会有两种交付形式：一种是提供database.sql脚本，需要你自己在MySQL里创建库并导入；另一种是直接提供一个初始化好的mysql数据目录文件，可以快速导入绑定。这套系统多半是前者。

导入脚本常用命令（在MySQL命令行或Navicat里执行）：

sql复制CREATE DATABASE vehicle_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE vehicle_system;
SOURCE /path/to/database.sql;

导入完成后，千万别忘了改SpringBoot的数据库连接配置，一般位于resources/application.yml或application.properties：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/vehicle_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
    username: root
    password: yourpassword

MySQL 8.0版本建议在url里加上allowPublicKeyRetrieval=true，否则连接时可能报Public Key Retrieval is not allowed错误。useSSL=false用来避免SSL握手报错。serverTimezone一定要设置，否则日期字段会与本地时区不一致。

6.3 后端启动与测试

后端启动有两种典型方式。

第一种是在IDEA里直接运行启动类。打开Application.java，右键Run即可。启动成功后控制台会输出SpringBoot的Logo和Tomcat started on port(s): 8080。注意一定要看到这个日志才算启动成功，窗口没报错但卡住不动并不代表已经起来了。

第二种是用Maven命令打包运行：

bash复制mvn clean package -DskipTests
java -jar target/vehicle-system-0.0.1-SNAPSHOT.jar

这种方式适合部署到服务器。在Linux环境下，我习惯使用nohup java -jar xxx.jar > log.txt 2>&1 &来启动，日志输出到文件里，方便排查。

启动后一定要先自测几个接口，用浏览器或Postman访问：

• POST /api/login：传一个初始化账户密码，看能否拿到token。
• GET /api/vehicle/list：请求头带上token，看能否返回车辆列表。
• GET /api/dashboard：看聚合数据是否正常返回。

自测这一步非常关键。很多人在前后端联调阶段才发现数据库表字段对不上、接口路径写错，浪费大量时间。

6.4 前端启动与跨域处理

前端开发环境启动流程是：

bash复制npm install
npm run dev

默认会在http://localhost:8081（或8080，看端口配置）启动一个热更新开发服务器。

这里最容易出的问题就是跨域。前端开发服务器在8081端口，后端接口在8080端口，浏览器里的Ajax请求默认会被跨域策略拦截。最佳解法是在vue.config.js里配置devServer.proxy：

js复制module.exports = {
  devServer: {
    port: 8081,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

这样前端代码里请求/api/login，开发服务器会自动转发到http://localhost:8080/api/login，浏览器端不会产生跨域报错。这个配置是前后端分离项目的生命线。

6.5 打包部署：前端dist放入SpringBoot

开发模式下前后端分离很舒服，但要是想交付一个“开箱即用”的系统，最省事的方式其实是前端打包后放进SpringBoot的静态资源目录，打成单jar包交付，用户只需要Java环境即可运行。

步骤很简单：

1. 前端执行npm run build，生成dist目录。
2. 把dist目录里的所有文件复制到SpringBoot的src/main/resources/static目录下。
3. 重新打包后端mvn clean package。
4. 运行java -jar，访问http://localhost:8080直接就是前端页面，不需要单独部署Node环境。

但这里有个连环坑：如果前端路由用了history模式，打包后直接访问子路径（比如/vehicle）刷新会返回404。因为前端路由本身是纯前端的，打包后没有服务器重写规则支持。解决办法有两个：把Vue Router改成hash模式，或者后端加一个WebMvcConfigurer，把非/api路径的所有请求forward到index.html。对于日常项目，直接改hash模式最简单，代价是地址栏会多个#号，但功能完全不受影响。

7. 常见问题排查与避坑实录

7.1 启动类问题速查

我把自己遇到过的启动问题按出现频率排个序，基本能覆盖90%的情况。

• 端口被占用：启动日志报Port 8080 was already in use。Windows下用netstat -ano | findstr 8080查进程PID，然后任务管理器结束进程；或者直接修改application.yml里的server.port改成8081。要注意前端代理配置也要同步改target端口。
• JDK版本不匹配：SpringBoot 3.x启动报java.lang.UnsupportedClassVersionError，说明JDK版本太低，换JDK17以上。SpringBoot 2.0启动没问题但编译报错，也要检查Idea里Project Structure的SDK版本是否切换到了正确的JDK。
• 依赖无法下载：Maven卡在Downloading状态或者报Cannot resolve ...，多半是本地仓库源的问题。在settings.xml里配好阿里云镜像源，或者检查IDEA是否开启了离线模式。
• Mapper接口找不到：启动报Invalid bound statement (not found)，大概率是Mapper接口和XML文件路径不匹配。MyBatis-Plus虽然可以自动生成单表CRUD SQL，但自定义SQL还是需要XML文件。检查mybatis-plus.mapper-locations配置是否指向了classpath*:/mapper/**/*.xml。

7.2 数据库连接与SSL问题

数据库连接错误是启动期的重灾区。最常见的报错和原因我整理成了表格：

还有一个细节，MySQL 8.0默认的密码加密方式是caching_sha2_password，有些旧版本的驱动不支持。如果连接报错和她有关，可以换成mysql-connector-java 8.x以上版本，或者在MySQL里把用户的加密方式改成mysql_native_password。不过现在的主流驱动都已经兼容这种新加密方式，升级驱动通常就解决了。

7.3 前端依赖与运行问题

前端相比后端坑更多，因为Node生态变化太快。这里记录几个高频问题：

• npm install 卡住或失败：网络原因居多。解决方案是配置镜像源：npm config set registry https://registry.npmmirror.com，再重新安装。
• 启动报OpenSSL错误：error:0308010C错误，Node版本过高，前面已经提过，加NODE_OPTIONS=--openssl-legacy-provider或降级Node。
• Element UI样式失效：main.js里忘记import 'element-ui/lib/theme-chalk/index.css'，多半是粗心。
• 请求404：接口路径写错或代理配置没生效。先看浏览器网络面板，确认请求实际打到了哪个URL，再对比后端Controller的@RequestMapping前缀。
• 登录后刷新丢了登录状态：token只存在sessionStorage里，关闭浏览器或者新开标签页就会丢。需要持久化的就放localStorage。

7.4 打包与跨域坑点

最后说一下打包和跨域的几个隐蔽问题。

如果前后端分开部署，前端放在Nginx上，后端单独跑在8080端口，这时候需要通过Nginx反向代理解决跨域。Nginx配置文件里加一段：

nginx复制location /api/ {
    proxy_pass http://127.0.0.1:8080/api/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

这个配置把前端域名的/api请求转发给后端服务，浏览器看起来就是同域请求。

如果前端打包后放在SpringBoot的static目录里跑，就不存在跨域问题了，因为前后端同源。但要小心上传文件路径的问题：图片上传后如果保存在本地目录D:/upload/，打包部署到Linux后这个路径就失效了。建议把上传文件的保存路径配置成相对路径或从配置中心读取，并且前端的图片URL要对应后端提供的静态资源映射，比如：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/upload/**")
                .addResourceLocations("file:" + uploadPath + "/");
    }
}

还有一个常见的坑：跨域配置写了两遍。有些人既在vue.config.js里配了proxy，又在后端加了@CrossOrigin或全局CORS配置，结果开发模式下两者冲突，出现奇怪的“预检请求401”问题。建议开发环境用前端代理，生产环境用同域部署或Nginx代理，后端CORS配置仅在前后端分离部署时开启，不要同时开。

写在最后：几点使用建议与扩展方向

这套源码跑通之后，如果时间充裕，我非常建议动手改几处，这样答辩或面试时聊起来会显得更有深度。

第一个方向是引入Redis缓存。目前登录token是纯JWT无状态，用户信息每次查询都要访问数据库。可以在登录后将用户信息和角色缓存在Redis里，自定义注解配合AOP实现接口鉴权，这样做的好处是权限控制更灵活，性能也更优。

第二个方向是接入工作流引擎。用车审批如果只有单级审批，用现在的状态字段就够。但如果是多级审批，比如部门主管初审、行政经理复审，建议引入Flowable或Activiti。这个改动会让项目复杂度上一个大台阶，作为扩展研究方向非常合适。

第三个方向是消息通知机制。当前到期提醒是登录后在页面上看，如果增加站内信、短信或企业微信通知，系统实用性会倍增。每次新增一条保养提醒或审批通知时，往通知表插一条记录，用户在首页顶部铃铛图标处能看到未读数量，这个功能也不复杂。

从我自己的经验来看，管理系统类项目容易做“平”，因为CRUD太容易了。真正让一套源码从“能跑”变“好用”的，恰恰是那些业务细节和异常边界的处理：车牌号重复时提示是否友好、删除车辆时是否检查有关联记录、审批驳回时申请人能否重新提交、导出Excel时字段是否整齐统一。把这些细节逐一做好，才是真正读懂了这套源码。

最后分享一个我调试前后端项目的小经验：遇到Bug先不要急着改代码，打开浏览器F12看Network面板，确认请求有没有发出去、走到了哪个接口、后端返回了什么状态码。八成的问题在这一步就能定位清楚，剩下两成再看后端日志。理清前后端的数据链路，调试效率至少提升一倍。