企业官网建设流程全解析

做 Java Web 毕设的同学应该都有这种感觉：题目好定，落地难。汽车服务管理系统就是一个典型的"看起来不难、做起来一堆事"的选题，它背后涉及 SpringBoot 后端、Vue 前端、MySQL 数据库、SQL 脚本初始化、接口文档编写、前后端联调部署，整条链路缺一个环节都跑不起来。最近我拿到一套完整的 SpringBoot+Vue 汽车服务管理系统平台源码，自带了 SQL 脚本和接口文档，就从零开始把它搭起来、跑通、又拆开研究了一遍。这篇就把整个过程和踩过的坑好好聊一聊，给准备做同类 Java Web 项目的同学一个可直接参考的完整路线。

这套系统本质上解决的是汽车维修保养门店的运营管理问题：客户信息怎么建档、车辆维保记录怎么查询、工单如何流转、订单如何结算、营收怎么统计。如果只是做一个简单的增删改查演示，那确实不难，但毕设要想拿高分，得把前后端分离架构、数据库设计、接口规范、权限控制这些关键点全部讲清楚。所以我先从项目拆解开始，一步步讲到环境搭建、核心实现、联调排错和部署答辩，每一段都是实操过程中真实遇到的内容。

1. 项目整体拆解：一套汽车服务管理系统该有的样子

1.1 这个系统的核心业务与功能闭环

汽车服务管理系统的业务场景并不算复杂，但正因为贴近真实生活，反而容易把功能讲得具体、接地气。以一家汽车维修保养门店为例，日常要处理的事情大致包括：客户第一次进店，需要记录车主姓名、电话、住址等基础信息；车辆信息要独立建档，车牌号、品牌车型、行驶里程、上次保养时间都要可查；客户要做保养或者维修，门店要开一张工单，记录接车时间、服务项目、负责技师、当前状态；服务完成后，根据工单生成订单，计算配件费用和工时费，确认支付状态；管理者要能随时看到今天的营业额、做了多少单、哪些客户的车快该保养了。

这套系统的功能模块正是按照这条业务线设计的。客户管理、车辆管理、服务项目管理、工单管理、订单管理、报表统计，几个核心模块一到手，业务闭环就完整了。前端页面按这些模块组织成菜单，后端接口按这些模块划分 controller，数据库表也按这些实体去设计，三层结构一一对应，理解起来非常顺畅。

这就回答了毕设里最核心的一个问题：你的系统解决了什么问题？答案是清晰而具体的，而不是笼统的"一个管理系统"。答辩时顺着这条业务线讲，每个功能都能落到实际场景里，可信度马上不一样，老师也不容易把你问住。

1.2 前后端分离架构的选型逻辑

为什么现在 Java Web 毕设清一色是 SpringBoot + Vue？因为这是一套经过大量项目验证的高效组合，不是偶然的潮流，而是实实在在适合这类管理系统。

后端选 SpringBoot，核心原因是它把 Spring 生态里最繁琐的配置自动化了。传统的 SSM 项目要手写大量 XML 配置文件，数据源、事务、扫描包都要一个个配置，SpringBoot 用自动配置和约定大于配置的方式把这些东西都收敛了。你只需要在 application.yml 里写上数据库连接、端口号等少量配置，启动一个入口类，内嵌的 Tomcat 就把整个 Web 服务跑起来了。再加上 SpringBoot 对 MyBatis、Redis 等组件都有很好的整合支持，后端开发效率非常高。

前端选 Vue，是因为它特别适合做管理类页面。Vue 的核心价值在于组件化和响应式数据绑定。一个表格、一个表单弹窗、一个统计卡片，都可以拆成独立的 .vue 组件复用；页面数据放在 data 或者状态管理里，修改状态后视图自动更新，不再需要手动操作 DOM。这种开发模式对后端出身的同学尤其友好，写页面的心智负担比 jQuery 时代低很多。

更现实的一点是，这套组合的学习资料、开源项目、报错解决方案都极其丰富。做毕设最重要的是"遇到问题能搜到答案"，你选一个冷门框架，光环境配置就能折腾一星期，而 SpringBoot+Vue 几乎所有坑都有人踩过，搜一下就能解决。选型这件事，本身也是答辩时能讲的头头是道的点。

1.3 数据库设计和表结构怎么理解

SQL 脚本是整个项目的底座。拿到脚本后不要急着执行，先把表结构看一遍，弄清实体之间的关系。通常这类系统会包含以下核心表：

从表关系上看，客户对车辆是一对多，一个客户名下可以有多辆车；工单分别关联客户和车辆，记录一次完整的服务过程；订单与工单一对一，体现"一单一结"的业务规则。这套关系模型不复杂，但是非常经典，正是数据库设计题里常考的范式设计的应用场景，答辩时被问到表结构设计，把这些关系和设计理由讲清楚就够用了。

这里顺带提醒一句：密码字段一定不要存明文。一般这类系统会用 MD5 加盐或者 BCrypt 做加密，你如果要改造登录逻辑，加密方式不能随便动，否则校验永远不通过。另外 SQL 脚本里通常会预置几个演示账号，登录之前先看清楚账号密码是什么，省得自己瞎试。

2. 环境准备：版本选择与项目初始化

2.1 版本组合怎么选才不会翻车

拿到项目第一件事，不是急着启动，而是把环境版本对齐。很多同学项目跑不起来，根本不是代码问题，而是 JDK、Maven、Node 的版本和项目不匹配。

先说后端。如果你的项目基于 SpringBoot 2.x，JDK 用 8 最稳，尤其是 SpringBoot 2.7.x，作为 2.x 系列的最终版本，兼容性非常好。如果是 SpringBoot 3.x，JDK 必须 17 起。这里有一个很多人不知道的关键区别：SpringBoot 3.x 把包名从 javax 换成了 jakarta，如果源码里还有import javax.servlet这类写法，在 3.x 下直接编译报错。看到网上"springboot版本太高"这种热搜就能理解，很多人把 SpringBoot 版本升到 3.x，结果一堆兼容问题，其实不是新版本不好，而是旧代码没有跟着升级。

Maven 建议装 3.6.3 以上版本，旧版 Maven 在拉取仓库依赖时容易出现证书或协议报错，信息特别抽象，与其排查半天，不如直接换新版。前端这边，Vue 项目要用 Vue2 还是 Vue3，得先看源码。Vue2 项目建议 Node 12 到 16，Vue3 项目用 Node 16 或 18 都能跑。特别要警惕 node-sass 这个库，它对 Node 版本的兼容性极差，Node 装成 18 以上时，安装依赖很可能报Node Sass does not yet support your current environment，处理办法是换成 sass，也就是 dart-sass，或者老老实实装一个匹配的 Node 版本。

2.2 SQL 脚本导入的正确姿势

导入 SQL 脚本是环境准备里最容易出岔子的一步，我把正确做法拆开讲。

第一步，先在 MySQL 里创建一个专属数据库。用 Navicat 的话，右键连接，选择新建数据库，名字可以取 car_service，字符集务必选 utf8mb4，排序规则选 utf8mb4_general_ci 或 utf8mb4_unicode_ci 都行。命令行方式直接执行CREATE DATABASE car_service DEFAULT CHARACTER SET utf8mb4;。

第二步，选中这个数据库，右键运行 SQL 文件，选择项目提供的脚本，点击开始。命令行方式则是mysql -u root -p car_service < car_service.sql，或者进入 MySQL 后执行use car_service; source /path/to/car_service.sql;。

第三步，执行完成后验证结果。重点看三样：表是否创建成功、各表是否有数据、字段是否符合预期。最简单的方式是执行SHOW TABLES;查看表清单，再用SELECT COUNT(*) FROM sys_user;这类语句看看用户表、客户表、工单表有没有初始数据。

这里有个新手常踩的坑：不加判断直接在一个已有同名表的数据库上执行脚本。很多 SQL 脚本开头是DROP TABLE IF EXISTS，意思是先删掉旧表再建新表，如果你在真实库上执行，旧数据就会被清掉。所以一定先创建独立的数据库再导入，别拿写好的数据库乱试。

2.3 拿到源码后先做的三件事

项目导入 IDE 之前，我建议先花十分钟把源码结构看清楚。第一件事是看 README 或者项目说明文档，一般会写明项目版本、启动步骤、初始账号。第二件事是看配置文件，后端看application.yml里的数据库连接、端口、上传路径，前端看.env、vue.config.js、package.json里的代理配置和依赖列表。第三件事是看依赖版本，后端pom.xml里的 SpringBoot、MyBatis、MySQL 驱动版本先心里有数，前端package.json里的 vue、vue-router、axios、element-ui 版本也要了解。

做完这三件事再动手，后面踩坑的概率会小很多。尤其是配置文件里的数据库密码和账号，很多人拿到源码改都不改直接跑，结果连接报错，其实只要把这两项改成你本地环境的就行了。

3. 核心细节解析与实操要点

3.1 后端三层架构与接口规范

这套系统的后端结构是标准的 Controller-Service-Mapper 三层，我把它拆开讲，方便你答辩时也能讲清楚。

Controller 层只做参数接收、校验、调用 Service、返回统一响应。一个合格的 Controller 方法应该很薄，比如登录接口只做三件事：接收用户名密码、调用 Service 校验、返回 token 或错误信息。业务逻辑放在 Controller 里是大忌，代码会越来越难维护，答辩时一问就露馅。

Service 层承载核心业务逻辑。登录时的密码校验和 token 生成、工单状态流转时的状态校验、订单生成时的金额计算，都在 Service 层完成。Service 层通常用@Service注解，并拆成接口和实现类，这样有利于解耦，也方便写单元测试。答辩时如果说"我的业务逻辑放在 Service 层"，老师会认为你有基本的工程素养。

Mapper 层就是数据访问层，和 MySQL 打交道。项目通常用 MyBatis 或 MyBatis-Plus，前者用 XML 或注解写 SQL，后者自带通用 CRUD，能省掉大量重复代码。分页的话，MyBatis-Plus 用分页插件传入页码和每页条数，返回分页对象；手写分页的话要自己处理 LIMIT 参数，容易在计算偏移量时出错，建议优先依赖插件。

接口规范方面，RESTful 风格是主流。列表查询用 GET，新增用 POST，修改用 PUT，删除用 DELETE，资源路径用名词复数，比如/api/customers、/api/workOrders。响应结构统一封装成{ code, message, data }这样的格式，前端拿到的一致性好，处理起来也方便。前端发起请求时，还要注意接口路径是否带/api前缀，以及后端的 context-path 配置，这些细节不对齐，接口就调不通。

3.2 Vue 前端的路由、状态管理与请求封装

前端工程化之后，Vue 项目的组织方式已经非常固定。路由用 Vue Router，全局状态用 Vuex（Vue3 对应 Pinia），HTTP 请求用 Axios。这套系统前端目录一般长这样：

src/ ├── api/ // 接口请求封装 ├── assets/ // 静态资源 ├── components/ // 公共组件 ├── router/ // 路由配置 ├── store/ // 全局状态管理 ├── views/ // 页面视图 ├── App.vue └── main.js

路由配置是最先要看的部分。管理系统的路由一般分为公开路由和需要登录的受保护路由。登录页、注册页属于公开路由，客户管理、工单管理这些业务页面必须登录后才能访问。Vue Router 的全局前置守卫beforeEach会在每次路由跳转前检查本地是否有 token，没有就强制跳转到登录页，这是管理系统的标配逻辑。

请求封装则是把 Axios 实例统一创建，设置baseURL，在请求拦截器里自动带上 token，在响应拦截器里统一处理错误码。比如 token 失效时后端返回 401，拦截器里自动清除本地 token 并跳转登录页。这里特别提醒一句：请求拦截器写config.headers['token'] = localStorage.getItem('token')虽然简单，但要注意 token 值不要带引号、空格之类的前后杂质，否则后端解析失败。很多"登录明明成功但后续请求一直 401"的问题就出在这里。

Vue 里的插槽也是一个高频考点。比如封装了一个自定义表格组件，不同页面需要在表格底部放不同的操作按钮区域，用 slot 就能把这些差异化的内容暴露给父组件填充。插槽又分默认插槽、具名插槽、作用域插槽，答辩论到组件化封装时，能自然地讲出插槽的使用场景，前端功底会显得扎实很多。

3.3 登录认证与权限控制的核心逻辑

登录认证是每个管理系统都必须有的部分。这套系统如果用的是 JWT，流程大概是：用户提交用户名密码，后端校验通过后生成一个携带用户信息的 token 字符串返回；前端把 token 存到 localStorage，后续请求在请求头中带上；后端写一个拦截器或过滤器，对需要认证的接口统一校验 token 合法性，通过就放行，不通过就返回 401。

如果用的是 Session 方式，后端登录成功后把用户信息存进 Session，后续请求靠浏览器 Cookie 携带 SessionId，后端从 Session 里取用户信息。两种方式在答辩时经常被对比。我的建议是：如果是 JWT，强调无状态、适合前后端分离、扩展性好；如果是 Session，强调简单直观、服务端可控。无论哪种方案，权限控制的思路一致：在拦截器里判断用户角色，只有管理角色才能访问后台管理接口。

前端同样有权限控制。除了路由守卫在未登录时拦截，有些系统还会做按钮级别的权限控制，比如只有管理员能看到"删除客户"按钮。实现方式通常是用自定义指令v-permission，根据当前用户角色判断是否移除按钮 DOM。这类细节如果项目里体现了，答辩时提一句，加分效果非常明显，因为大部分同学的毕设只做了登录拦截，没有做到前端细粒度权限。

3.4 分页查询、文件上传与统计报表的实现细节

管理系统里几乎每个列表页都用分页。前端表格组件通常自带分页能力，比如 Element UI 的el-pagination，只需把当前页码和每页条数传给后端，后端返回总记录数和当前页数据，前端把 total 赋值给分页组件即可。这里容易踩的坑是分页参数名不一致：有的后端用 pageNum 和 pageSize，有的用 page 和 limit，前后端必须对齐，否则第一页正常、翻页就报错或数据为空。联调时第一步就是确认参数名一致。

文件上传也是常见需求，比如客户头像、车辆照片、工单附件。后端用 MultipartFile 接收文件，配置一个上传路径，把文件保存到本地磁盘，再把访问路径存进数据库。重点处理两件事：一是重命名，避免同名覆盖，一般用 UUID 或时间戳加原始文件名；二是文件访问，如果存放在本地，前端 img 标签的 src 要么填完整 URL，要么通过代理访问，否则会图片 404。

统计报表一般用 SQL 聚合查询加前端图表。后端写统计接口，用GROUP BY按日期聚合订单金额，返回每天营业额和订单数；前端用 ECharts 的折线图、柱状图展示。这里要小心时区问题：数据库的日期字段和前端展示的日期可能因为时区不同差几个小时，按天分组的数据看起来会少一天。处理办法通常是在 JDBC 连接串里加serverTimezone=Asia/Shanghai，或者统一在 SQL 里做日期格式化。

4. 接口文档、联调与调试实录

4.1 接口文档里到底要看什么

拿到接口文档，别只把它当摆设。一份能用的接口文档至少应该包含：接口名称和请求地址，明确是 GET 还是 POST，路径是/api/login还是/api/user/login；请求参数的类型、是否必填、说明；请求体示例，POST 请求尤其要有；响应体示例，包括成功和失败两种情况。这些信息缺了哪个，联调时都得靠猜，效率非常低。

如果你是动手实现方，先看登录接口，把认证方式弄明白，这是打通前后端的第一步。接着看业务接口，重点关注列表接口的分页参数和搜索参数。最后看统计接口，对照首页仪表盘的图表数据，确认返回结构能否直接给前端用。这套系统的接口文档把每个接口的请求方法、请求参数、返回结构都列出来了，照着文档调，省去大量抓瞎时间。

4.2 一条完整业务链路的联调过程

联调不要东一下西一下，最好按业务链路完整走一遍。我拿这套系统里最典型的一条链路演示：登录系统、进入首页、查看工单列表、创建新工单。

第一步，前端登录页填账号密码，调用/api/login，后端返回成功后，前端把 token 存起来并跳转首页。这一步失败，通常表现为没有跳转或请求返回 401，原因多半是参数名写错或密码加密方式不一致，先对照接口文档确认请求体字段名。

第二步，首页仪表盘请求统计接口，后端返回总营收、订单数、工单数等数据，前端渲染到统计卡片和图表中。这一步常见的问题就是上一节说的日期时区，导致当天数据汇总不对。排查方式很直接：在 Navicat 里手动执行统计 SQL，看返回结果是否和接口返回一致；不一致就是 Java 后端代码的问题，一致的话问题就在前端展示参数。

第三步，进入工单管理页面，请求列表接口，注意把分页参数带正确。出现列表空白时，先打开浏览器开发者工具 Network 面板，看请求有没有发出去、返回什么状态码。如果请求没发出去，多半是路由守卫误判登录状态；如果发出去但返回 500，就拷贝报错信息去搜。

第四步，点击新建工单，弹表单，选择客户、车辆、服务项目，提交保存。这里要留意新增接口的参数结构，如果一单包含多个服务项目，请求体里通常是数组嵌套，前端要组装好数据，后端用List<Item>接收，两者必须一致。实战里因为"前端传了一个对象，后端却要数组"导致的失败简直不要太多。

4.3 这几个联调问题几乎人人都遇过

第一个是字段大小写不一致。Java 后端字段习惯用驼峰命名，比如 userName，数据库和 JSON 里却可能是下划线 user_name，前端一取值就得到 undefined。用 MyBatis-Plus 可以开启驼峰映射，或在 SQL 里用别名，但最稳的办法是前后端统一字段命名规则，接口文档里写清楚，联调前对齐。

第二个是跨域问题。前后端分离后，前端运行在 8080，后端运行在 8081，浏览器会阻止跨端口请求。处理方式常见有三种：后端加@CrossOrigin注解；后端写全局跨域配置类实现 WebMvcConfigurer 的 addCorsMappings；前端在 vue.config.js 里配置 devServer 的 proxy 代理，让前端请求转发到后端。打包部署时前后端同域，跨域问题不明显，但本地开发避不开。

第三个是请求 404。前端请求地址明明后端有接口，但返回 404，大概率是代理配置或路径拼接出错。打开 Network 面板看实际请求的 URL，对比后端 Mapping 路径，很多时候是 baseURL 配错或者漏了/api前缀。这类问题从 Network 面板入手，基本几分钟就能定位，不要凭感觉乱猜。

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

5.1 SpringBoot 版本过高引发的连锁反应

搜过"springboot版本太高"的人，多半经历过这种场景：项目代码没问题，启动时却报一堆依赖冲突，今天缺包，明天注解找不到。本质原因是 SpringBoot 各版本对依赖的默认管理版本不一样，手动指定过高版本的依赖，容易和 SpringBoot 的 BOM 产生冲突。

处理办法很简单：依赖版本跟着 SpringBoot 主版本走。pom.xml 里引入spring-boot-starter-parent作为父工程，其他依赖不写版本号或只写确实需要覆盖的版本。如果非要升级某个依赖，用dependencyManagement统一管理版本，避免隐性地不一致。另外就是 SpringBoot 3.x 和 2.x 的包名变化，之前提到的 javax 到 jakarta。要升级 3.x，就所有引用了 javax 的代码一起改成 jakarta；如果只是要跑通毕设，完全没必要追求最新，2.7.x 配 JDK8 最省事。

5.2 Vue 安装依赖时的 Node 与 node-sass 冲突

"vue安装及环境配置"折腾过不少人。前端项目 clone 下来后第一件事是npm install，问题往往出现在这里。报错常见的有权限问题、网络问题、node-sass 编译问题。

权限问题在 macOS 或 Linux 下需要用sudo npm install，或者调整 npm 的用户目录权限；网络问题可以换镜像源，执行npm config set registry https://registry.npmmirror.com；node-sass 的问题前面说过，优先考虑把node-sass替换成sass，同时把代码里的@import语法调整成@use，遇到兼容问题就查一下官方迁移说明。还有一个容易忽略的点：Vue2 配 Element UI，Vue3 配 Element Plus，两个组件库的 API 有差异，Button 的 type、table 列定义都不太一样。环境配置阶段把版本关系理顺，后面写页面会很省心。

5.3 MySQL 执行 SQL 脚本的常见报错

执行 SQL 脚本最常见的报错有两个。一个是"Table doesn't exist"，通常是你选错了数据库，或者根本没建库就导入。另一个是导入时字符集报错，脚本里有中文注释或中文数据，但数据库字符集不是 utf8mb4，导致乱码或执行中断。

解决方式是导入前确认数据库字符集。Navicat 新建数据库时选 utf8mb4；命令行方式在创建库时加CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci。如果脚本本身是用 utf8 编码保存的，导入前还要看文件编码是不是 GBK，否则中文数据会变成乱码。还有一种情况是脚本里有存储过程或触发器，包含DELIMITER $$语句，用命令行的 source 执行时弹错，不要慌，确认一下脚本里的 DELIMITER 处理是否正常，必要时用 Navicat 直接运行整个文件更省心。

5.4 跨域、登录失效和请求 404 的排查思路

这三种问题都和请求有关，排查套路是一样的：先在浏览器开发者工具 Network 面板看实际请求，再对应后端控制台日志定位。

请求跨域，Network 面板会明显标出 CORS error，或者响应缺少 Access-Control-Allow-Origin 头，处理方式参考之前章节。登录失效，请求头里没带 token 或 token 过期，看 Network 面板请求头里是否存在 Authorization 或自定义 token 字段，再看前端拦截器有没有正确注入。请求 404，先看实际请求 URL 和后端接口路径是否一致，注意斜杠、大小写、参数名，排除后再看后端 Controller 的 RequestMapping 是不是写错了。

排查原则只有一个：不要凭空猜，先用 Network 面板拿到实际请求和响应信息，再结合后端日志定位。绝大多数问题都能在这套组合拳下十分钟内找到原因。我自己排错时，九成时间都花在打开 Network 面板这一步，剩下的只是看到报错、搜索、修复。

6. 部署打包与答辩准备心得

6.1 后端打包与前端构建的完整流程

项目做完要部署，通常后端打成 jar 包，前端构建成静态文件。后端打包命令在项目根目录执行：

mvn clean package -DskipTests

执行完成后，target 目录下会生成 jar 包，比如car-service-0.0.1-SNAPSHOT.jar。本地运行用java -jar target/car-service-0.0.1-SNAPSHOT.jar，想改端口就追加--server.port=8081。需要注意，jar 包运行时读取的是src/main/resources下的配置，数据库连接、上传路径等要提前改成目标环境对应的参数。

前端构建命令：

npm run build

构建完会生成 dist 目录，里面是打包好的 HTML、CSS、JS 静态文件。开发时前端通过代理访问后端，打包后的请求地址已经写死成/api前缀，部署时就要靠 Nginx 代理转发到后端端口。Nginx 配置大概长这样：

server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8081/api/; } }

try_files这一行是关键。前端是单页应用，路由由 Vue Router 控制，刷新页面时如果直接请求某个子路由路径，Nginx 需要把请求重写到 index.html，否则会出现刷新 404。很多人部署完首页能打开，一刷新就报错，问题就出在这里。

6.2 答辩现场最值得讲的三个点

答辩时不要照着 PPT 念功能列表，选最有技术含量的几个点展开。我最推荐这三个：

第一个是数据库设计。把客户、车辆、工单、订单的表关系画出来，讲清楚一对多和一对一的关系，以及为什么这样设计。这是所有功能的基础，也是最容易讲扎实的部分。只要老师顺着业务问，你都能落到表层面说明白。

第二个是认证方案。把 JWT 或 Session 的完整流程讲一遍：用户提交凭证、后端验证、生成 token、前端存储、请求拦截器注入、后端校验、401 处理。这条链路完整讲下来，比说一百句"实现了登录功能"都有说服力。如果还能顺带提一下密码加密方式、权限控制的前端配合，就是一个很完整的回答。

第三个是前后端联调的细节。比如跨域是怎么处理的、分页参数怎么对齐、上传文件做了哪些安全处理。这些细节能证明你在项目里做的事情是真实的、有思考的，而不是从网上找了一份现成代码跑通就完事。老师特别爱问"这个功能你遇到过什么问题"，你如果答得出来具体报错和解决过程，基本就能稳住。

6.3 拿到这套源码后还可以怎么扩展

毕设不是跑通就结束，合理的扩展能让项目更有深度。基于这套汽车服务管理系统，建议往这几个方向改进：

第一个方向，消息推送。用 WebSocket 实现工单状态实时通知，新工单到了、工单完工了，前端有实时提醒。这一个点就能让项目多一个实时通信的技术亮点，面试也爱听。

第二个方向，定时任务。用 SpringBoot 的@Scheduled做"保养提醒"功能，根据车辆上次保养时间和保养周期，自动算出哪些客户的车快该保养了，生成提醒记录。这个功能贴近真实业务，实现也不复杂，非常加分。

第三个方向，用 Redis 做缓存或验证码存储。登录验证码、用户信息缓存、热点数据缓存，Redis 都能接上。哪怕只做一个"验证码存 Redis、5 分钟过期"的小功能，也能体现你对常见中间件的掌握。

扩展时注意别贪多。功能可以做少一点，但每个都要能讲清楚实现原理。评委问"为什么这么做"时，你能答出"因为查询频繁，加缓存减轻数据库压力"这类理由，比功能数量更有价值。

最后再分享一点我自己的体会：做毕设最忌贪大求全，也最忌拿源码跑通就完事。跑通只是第一步，你要把"为什么用 SpringBoot、前端为什么选 Vue、数据库为什么这么建模、接口为什么这么设计"这些问题都琢磨明白。汽车服务管理系统这个题目，恰好能把整条 Java Web 链路完整走一遍，只要你顺着业务线把每个模块打通、把每个细节讲清楚，答辩老师很难挑出硬伤。这套源码加上 SQL 脚本和接口文档，就是一个很好的跳板，跑通之后它给你的价值远不止一个演示项目，而是一整套可复述、可扩展的 Java Web 知识体系。