企业官网建设流程全解析

1. 题目拆解与整体设计思路

1.1 这个课题到底在做什么

“springboot+vue汽车修理管理系统”，乍看是个典型的“前后端分离”毕业设计题，但如果只是把它当成一套 CRUD 去凑功能，论文和答辩会很难看。我拿到这个题目时的第一反应是：它背后的业务到底是什么？

汽修厂的日常，无非就是：客户进店，前台登记车辆和故障，师傅检查、报价、维修、领料，最后结账、出门。这中间还穿插着配件采购、库存盘点、员工提成、工单统计这些辅助业务。你会发现，一个看似简单的汽修厂，实际上是一个“进销存+工单流转+员工绩效”三合一的信息系统。我这次做的系统，就是把这套线下流程完整搬到线上，让前台、车间、库房、老板各自有一个入口，操作留痕，数据能算。

这套系统适合谁参考？三类人最值得看：一是正在准备毕设、想要一个逻辑完整且能跑通的课题的同学；二是打算自己开汽修店，想低成本搭一套管理后台的店主；三是想学习 Spring Boot 与 Vue 前后端分离实践、想看看真实业务怎么落地的开发者。我按照“能撑住一家小型汽修厂真实运营”的标准去做，而不是做一个交了作业就删库的 Demo。

1.2 技术选型：为什么是 Spring Boot 加 Vue

先说后端。Spring Boot 是目前企业级项目里最主流的选择，没有之一。它把 Spring 那套繁琐的 XML 配置全部干掉，内嵌 Tomcat，打一个 jar 包就能跑，对于毕设和中小型管理系统来说非常合适。选 Spring Boot 3.x + Java 17，而不是老旧的 Spring Boot 2.x + Java 8，一方面是为了体现出你掌握了新版本特性，另一方面新版在性能和安全性上都有明显提升。配合 MyBatis-Plus 操作数据库，CRUD 不需要写繁琐的 Mapper XML，单表操作全都能直接继承 BaseMapper 拿到现成方法。

前端选 Vue 3 + Element Plus + Vite。Vue 3 的 Composition API 让代码逻辑复用更方便，Element Plus 是 Vue 3 生态下的成熟组件库，表格、表单、弹窗、分页这些后台管理系统的高频组件全都有，十几分钟就能把一套像样的管理界面搭出来。为什么不用 Vue 2？说实话，新项目再抱着 Options API 不放，答辩时导师问你“为什么不选 Vue 3”，你很难讲得有理有据。

数据库用 MySQL。当前后端分离模式下，项目里要配的东西也不复杂：后端统一返回 JSON，前端通过 Axios 请求接口，用 JWT 做登录鉴权。我会在后文把每一条线的核心配置和代码逻辑都拆开讲清楚。

1.3 功能模块边界划分

在动手写代码之前，最重要的不是先建工程，而是先把功能模块画清楚。我做这个系统时，把业务分成六个大模块：

模块边界划分得越清楚，数据库设计和接口设计就越顺。你去看很多失败的项目，代码写成一个巨大的 Service，所有逻辑都往里面塞，最后改一个需求就崩一片，根源就是一开始没有把模块边界想明白。做毕业设计也一样，就算只是一个学习项目，也要用工程化的思路去约束自己。

2. 数据库设计：汽修厂的业务模型落地

2.1 核心表结构与关系梳理

数据库是系统的地基。很多毕设项目被导师挑毛病，十有八九是表设计有问题：要么字段太少，要么关系混乱，要么一张表扛所有业务。我设计这个系统时，遵循了“一个业务实体一张表，关联关系靠外键逻辑维护”的原则，最终落库的核心表有这些：

• customer客户表：姓名、手机号、地址、会员等级。
• vehicle车辆表：车牌号、品牌型号、车架号、里程数、归属客户ID。
• repair_order维修工单表：工单号、车辆ID、接待员工ID、故障描述、当前状态、预计完工时间。
• repair_order_item工单明细表：关联工单ID，维修项目、工时费、所用配件、配件数量。
• parts配件表：配件编码、名称、规格、库存数、警戒库存、进价、售价。
• parts_stock_record配件出入库记录表：配件ID、类型（入库/出库）、数量、关联工单ID、操作人、时间。
• employee员工表：账号、姓名、手机号、角色ID、状态。
• role/menu/employee_role/role_menu四张表构成 RBAC 权限模型。
• settlement结算表：关联工单ID、应收金额、实收金额、结算方式、结算时间。

必要的关系：客户与车辆是 1:N，一辆车可以多次维修，所以维修工单挂在车辆之下而不是直接挂在客户之下，这样方便查“某台车的历史维修记录”。维修工单与维修项目是 1:N，一张单子可能包含保养、换刹车片、做钣金等多个项目。配件出入库记录要与工单关联，否则年底盘点对不上账。为什么强调这个关系？我见过有人把配件直接写死在工单表里一个字段，但那意味着一次维修只能用一个配件，完全不符合现实业务。

2.2 关键字段的设计细节

有几处字段设计是想清楚后写出来特别加分的点。

第一，金额字段一律用DECIMAL(10, 2)，绝对不能用FLOAT或DOUBLE。浮点数在二进制的存储里天然存在精度丢失，比如 0.1 加 0.2 在计算机里算出来是 0.30000000000000004，这在涉及钱的系统里是致命的。Java 后端与数据库配套，BigDecimal对接DECIMAL字段。

第二，状态字段用TINYINT存数字，不在数据库里存中文。维修工单状态我用 0～5 来标识：0 待接待、1 维修中、2 待质检、3 待结算、4 已完成、5 已取消。存数字的好处是排序、索引、查询都更快，而且状态含义单独建一个数据字典去管理，前端拿到数字后翻译成对应的中文标签。

第三，逻辑删除字段delete_flag必须有，且默认值为 0。真实业务中，客户信息、配件信息是不能物理删除的，否则历史工单的关联数据会丢。我用 MyBatis-Plus 的@TableLogic注解配合逻辑删除，删除操作自动变成UPDATE ... SET delete_flag = 1，查询会自动带上WHERE delete_flag = 0。

2.3 状态机与数据字典设计

维修工单是整个系统的核心，它的状态流转很讲究。我花了一张状态图时间，实际上每次只是对应图片标记，没有用代码，但表现在数据库设计上就是一条status字段。这里有个容易踩的坑：不做状态约束，任何状态都能任意跳到任何状态。比如“待质检”的单子，直接改成“已完成”，这在业务上是不合理的。我建议做成一个状态机校验的机制：后端在每次更新工单状态时，先判断当前状态是否能流转到目标状态。

// 状态机校验：允许的流转路径 private static final Map<Integer, List<Integer>> ORDER_STATUS_FLOW = new HashMap<>(); static { ORDER_STATUS_FLOW.put(0, Arrays.asList(1, 5)); // 待接待 -> 维修中 / 已取消 ORDER_STATUS_FLOW.put(1, Arrays.asList(2, 5)); // 维修中 -> 待质检 / 已取消 ORDER_STATUS_FLOW.put(2, Arrays.asList(3, 5)); // 待质检 -> 待结算 ORDER_STATUS_FLOW.put(3, Arrays.asList(4, 5)); // 待结算 -> 已完成 }

你问为什么这么设计？核心原因是为了让流程可控、责任清晰。师傅没修完车就不能点结算，这是基本逻辑。现实业务中不可能让一个工单从“待接待”直接跳“已完成”，修车是有顺序的。状态机字段配合数据字典表，既保证了后端数据的严谨性，又让你在论文里写得出来“业务闭环”这四个字。

3. 后端核心实现与业务逻辑

3.1 项目骨架与统一返回结构

后端项目结构我采用的是标准的分层架构：controller接收请求，service处理业务逻辑，mapper操作数据库，entity承载数据实体，common放通用工具和返回结构。统一返回结构是前后端分离项目的标配，我定义了一个Result<T>类，包含code、message、data三个字段。

public class Result<T> { private Integer code; // 200 成功，500 失败 private String message; // 提示信息 private T data; // 数据体 }

为什么必须统一返回结构？因为如果没有它，前端每次收到响应都要自己判断返回的是对象还是列表还是错误字符串，代码会非常零乱。统一之后，前端 Axios 的响应拦截器只认code是否为 200，不是 200 就全局弹错误提示，异常处理完全集中。配合一个@RestControllerAdvice全局异常处理器，所有异常都能被捕获并转成统一的错误 JSON，不会出现后端抛出异常前端界面直接白屏的情况。

登录鉴权我用的是 JWT。用户在登录接口提交账号密码，后端校验通过后生成一段带签名和过期时间的 Token 返回给前端。前端把它存到 localStorage，每次请求在请求头里带上Authorization。后端写一个拦截器，对所有非登录接口做 Token 校验，解析出来的用户信息放进 ThreadLocal，后续业务代码里直接取当前登录人的 ID，方便记录操作日志。

3.2 维修工单流转的核心逻辑

工单是整个系统最复杂的业务，这里我具体走一遍它的核心 Service 逻辑。创建工单时，前端传入的是车辆ID、故障描述、选择的维修项目列表和配件列表。后端接收之后，在事务内做这几件事：

1. 根据车辆ID检查客户信息是否完善，手机号为空时直接提示补充。
2. 生成工单号。格式是GD + yyyyMMdd + 三位流水号，比如GD20250601001。用日期加流水的好处是工单号可读性强，打印出来贴在工位上，师傅和前台一看就知道是哪天的单子。生成规则用 Redis 自增或者查询当天已有工单数量加一都行。
3. 计算预估金额。遍历维修项目，把工时费和配件费累加，生成明细记录。这里工时费在repair_item表里有基准价，但实际维修中师傅可能临时加项目，所以明细要支持修改。
4. 扣减配件库存。每使用一个配件，就更新parts表的库存数量，并向parts_stock_record表写入一条出库记录。

你可能要问：为什么创建工单时就扣减库存而不是等结算时再扣？因为真实工厂流程是维修完成时配件已经装到车上了，库存必须在中途就反映真实耗材情况，否则库房看到的库存数永远是虚高的。这个决策在答辩时讲出来非常加分，体现的是业务思维而不只是编码能力。

3.3 库存扣减的并发与事务处理

库存扣减不做并发控制，最后一定出问题。汽修厂同时接十几台车很常见，如果两个工单同时要用某一款配件，恰好库存只剩一个，两条请求同时读到库存数为 1，各自判断充足，都去扣减，库存就变成了 -1。解决这个问题我用的是“乐观锁 + 库存充足条件判断”的结合方案。

UPDATE parts SET stock = stock - #{count} WHERE id = #{partsId} AND stock >= #{count}

这是一条带条件的原子更新语句。数据库在更新时会锁住这条记录，多个并发请求串行执行，后到的请求会因为stock >= count条件不成立而更新失败，影响行数为 0。Java 侧根据影响行数判断，如果是 0 就抛出库存不足的异常，事务回滚，前端就能看到“配件库存不足”的友好提示，而不是库存变成负数。这个写法比先查再减的方式安全得多，也不需要引入分布式锁，对一个单体管理系统来说刚刚好。

3.4 权限控制的落地方式

系统里有三个角色：管理员、前台、库管、修理工。权限控制要是写死在代码里判断角色名称，功能一多就会乱。我用标准的 RBAC 模型，用了employee、role、menu、employee_role、role_menu五张表。核心思路是：不直接给员工分配菜单权限，而是给角色分配，再把员工挂到角色下。

// 后端接口级别的权限控制示例 @PreAuthorize("hasAuthority('parts:inbound')") @PostMapping("/inbound") public Result<String> inbound(@RequestBody StockRecordDTO dto) { partsStockService.inbound(dto); return Result.success("入库成功"); }

前端拿到的菜单树是根据当前用户的角色动态生成的，没有权限的菜单根本不显示。后端接口再用@PreAuthorize做二次拦截，防止有人绕过前端直接调用接口。这里我想强调一句：前端的菜单隐藏永远只是为了用户体验，真正的权限安全必须落在后端，这是很多初学者最容易忽略的问题。

4. 前端页面与接口对接

4.1 Vue 项目结构与动态路由

前端我用 Vite 创建 Vue 3 项目，目录结构如下：

• src/api：所有接口请求封装，按模块拆成order.js、parts.js、customer.js。
• src/router：路由配置。
• src/store：Pinia 状态管理，存用户信息、菜单列表、Token。
• src/views：页面组件，按模块建子目录。
• src/utils：Axios 封装、工具函数。

动态路由不是难点，但很重要。登录成功之后，后端返回当前用户的菜单列表，前端拿到之后用router.addRoute动态添加路由。为什么不能把路由写死在代码里？因为不同角色能访问的页面不同，如果路由写死，前端仍然可以手动输入 URL 跳转到无权限页面，虽然后端接口会拦截，但会留下糟糕的使用体验。

4.2 Axios 封装与请求拦截

Axios 封装是前端的核心基建。我在utils/request.js里做了一层统一封装：

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res; } if (res.code === 401) { // Token 过期：清除本地信息，跳转登录页 localStorage.clear(); window.location.href = '/login'; return Promise.reject(new Error('登录已过期')); } ElMessage.error(res.message); return Promise.reject(new Error(res.message)); }, error => { ElMessage.error('网络异常，请检查后端服务是否启动'); return Promise.reject(error); } );

这套封装的优点非常明显：所有接口请求自动带上 Token，所有错误统一弹提示，所有 401 统一处理跳转登录。每个页面里不用再重复写错误判断逻辑，代码量大幅减少。我实际开发中体会最深的是 401 统一处理，否则每个接口都要自己判断“登录是否过期”，页面一旦多了，哪里漏处理哪里就白屏。

4.3 关键页面的实现细节

工单管理页面是整个前端最复杂的一页，它要完成的功能是：列表展示所有工单、按状态筛选、点击创建弹窗、编辑工单明细、查看详情、状态流转操作。我实现时用 Element Plus 的el-table展示数据，el-dialog嵌套表单组件。这里有三个值得提的细节：

第一，创建工单时，维修项目和配件是动态增减的表格行。用户点击“添加项目”，表格就多出一行，下拉框里可以选维修项目；选择维修项目后，配件下拉框联动显示该项目常用的配件。这个联动效果如果用 Vue 3 的响应式做起来非常简单，但体现出的产品完成度很高。

第二，状态流转按钮根据当前状态动态控制。比如当前状态是“待接待”，操作按钮显示“派工”；状态是“维修中”，显示“提交质检”。按钮的显示逻辑用一个函数统一生成，没有散落在模板里写大量v-if。

第三，列表页的搜索条件与控制。我做的查询条件有：工单号模糊查询、车牌号、状态、创建时间范围。时间范围用 Element Plus 的日期选择器，传给后端的参数是时间戳，后端配合 MyBatis-Plus 的QueryWrapper.between()精确过滤。

5. 实战中踩过的坑与排查记录

5.1 金额精度丢失问题

开发结算功能时我踩过一次数据不一致的坑：客户结算时应收金额对不上账，总是差几毛钱。排查了很久发现是我在 Java 里用Double去计算工时费和配件费的和。Double在计算时会有精度丢失，1.1 加 2.2 结果不是 3.3 而是 3.3000000000000003。这在小数位少的时候可能不明显，但当多个明细累加之后，误差就会累积。

后来我统一改成BigDecimal，而且构造函数必须使用字符串形式：

new BigDecimal("19.90");

这个坑的关键在于：new BigDecimal(19.90)也是不安全的，因为 19.90 在浮点类型里已经失真，传给 BigDecimal 的时候失真就被带进来了。用字符串构造完全没有这个问题。最终我把涉及金额的字段全部确定为BigDecimal，数据库全部用DECIMAL(10,2)，前端展示时再调用Number(value).toFixed(2)格式化，彻底解决了金额误差问题。

5.2 时间字段的时区陷阱

接口联调时发现：前端提交的工单预计完工时间，在后端数据库里总是少了 8 小时。一开始我以为是传输过程被截断，后来排查发现是时区问题。前端浏览器默认用东八区时间，后端连接数据库的 JDBC URL 里如果配了serverTimezone=Asia/Shanghai，时间就能正确转换；如果配的是 UTC，时间就会相差 8 小时。这是前后端分离项目最经典的坑之一。

我的解决方案是：数据库连接串统一加serverTimezone=Asia/Shanghai，Java 侧的LocalDateTime类型不手动干预时区转换，前端展示时直接渲染字符串。这里还要提醒一下：不要用Date类型去接收前端传来的字符串，因为它会受系统默认时区影响，最好用LocalDate或LocalDateTime，配合 Jackson 的序列化配置，全局格式化yyyy-MM-dd HH:mm:ss。

5.3 级联逻辑与数据关联问题

起初我在删除客户时，直接在前端发起DELETE /customer/{id}，后端执行物理删除，结果发现该客户名下的历史维修记录全部悬空——工单表的客户ID指向了一个不存在的记录。后来我做了两处调整：

第一，全局启用逻辑删除。客户、车辆、配件这些带有历史业务关联的数据表，都换成逻辑删除。这能在数据库层面保证历史数据仍可追溯。

第二，删除前做业务校验。如果客户名下有未完成的工单，后端直接返回错误信息“该客户存在未完成工单，无法删除”。这个操作的意义是避免脏数据链断裂。我给车辆也加了同样的校验，如果车辆存在未完结的工单，则不允许删除。你可能觉得多此一举，但真实使用场景里，前台误删了正在修车的客户档案，那问题就大了，做开发，一定要有关联意识。

5.4 MyBatis-Plus 更新空字段的坑

用updateById()更新数据时，实体中为null的字段默认不参与更新。这个特性大多数时候是好事，因为避免了误将表里已有字段清空。但有一种场景会踩坑：当业务上明确要把某个字段置空时，比如管理员要清空某条备注，刚好把remark设置为null，前端传过来是空字符串，而我在后端转成了 null。结果updateById一调用，数据库里的备注根本没有被清空。

解决方法有两个：要么更新前判断，使用实体字段上的@TableField(updateStrategy = FieldStrategy.IGNORED)注解显式允许更新为 null；要么写专门的 SQL 语句，直接UPDATE table SET remark = NULL WHERE id = ...。我更推荐第二种，因为这属于特定场景的明确操作，喷淋式更新容易误伤其他字段。这个坑在真实开发中出现频率极高，写出来让大家少走点弯路。

6. 演示答辩与项目扩展的一些建议

6.1 演示 Demo 时的数据准备

系统写完之后，给导师演示或者自己录制演示视频的时候，不要拿空数据库去测试。空列表的页面毫无说服力。我提前准备了大概一个月的模拟数据：20 个客户、50 个车辆、100 多张工单，横跨不同的状态，配件库存里刻意把两个配件的库存调到低于警戒线。这样打开仪表盘页面时，图表不会空荡荡，库存预警也马上有数据展示，演示效果会非常饱满。

模拟数据我用 SQL 脚本生成。写一段存储过程，循环随机插入数据即可。这里的一个小技巧是：生成日期要体现出业务规律，不要每天均匀分布。比如周末修车的人多，工作日相对少，让模拟数据在日期分布上呈现这种波动，一看就是真实运营场景，而不是造出来的假数据。

6.2 代码设计与网上的教程如何消化

很多同学从网上拿到的源码，根本跑不起来。我总结了三条经验，几乎适用于所有 Spring Boot 加 Vue 的毕设项目：一是看数据库脚本版本，MySQL 5.7 和 MySQL 8.0 的驱动配置不同；二是看配置文件application.yml，数据库账号密码、端口、文件上传路径这几个位置是最容易出错的地方；三是前端项目装了依赖还是报模块缺失，多半是 Node 版本不对，Vue 3 项目建议 Node 18 以上。把这三件事排查清楚了，项目跑通的成功率能提高八成。

源码拿到手不要急着改功能，先把业务流程跑通，再用“单点替换”的方式逐步改造成自己的代码。比如先改客户管理模块，把它完全理解了再动下一个模块。这样既能深入到代码细节，又不至于一手包办踢到自己。

6.3 再往后还可以怎么做

这个系统的扩展空间还很大，我自己的后续计划里列了两条：一是增加维修进度推送能力，工单状态变化时推送提醒给客户；二是把统计报表做得更细致，比如按项目类型分析利润、按员工分析工单量。如果工作后接触云服务，还能把整个系统容器化，用 Docker Compose 一键部署。别小看这些扩展，它们每一个都能撑起一篇小论文，也是答辩时展示自己思考深度的亮点。

做毕设的这段经历，我最大的体会是：编码只是最后落地的那一步，前面梳理业务逻辑、设计数据结构、划分模块边界，这些功夫占了七八成。把一个看似普通的“汽车修理管理系统”做到流程严谨、界面好用的过程，会让你真正理解什么叫“从需求到交付”。就算以后不做汽修行业，这种把现实业务抽象成系统的能力，到哪个岗位都通用。