Spring Boot汽车维修服务管理系统设计与实现全解析

1. 项目概述

“Springboot汽车维修服务管理系统”这个标题，几乎年年都在毕业设计选题榜单上占据一席之地。作为过来人，我第一眼看到它就明白这背后其实是一整套典型的JavaWeb企业级开发链路：前端页面、后端接口、关系型数据库、权限控制、业务状态流转，再加一套万字论文去支撑理论框架。麻雀虽小，五脏俱全，正因为它把主流技术栈全部串起来了，才会成为这么多计算机专业学生的“老朋友”。

这个系统解决的实际问题很简单，汽车修理厂还在用手工记账、Excel管配件、微信群报工单，信息散乱且容易丢。维修服务管理系统就是把“客户开单→派工维修→配件领用→结算出厂”这条业务线搬上线，让前台、车间、库房和老板都能在同一个系统里协作。它能做到车辆信息一查就有、维修进度实时可看、配件库存自动扣减、工时费用一键计算，对中小型汽修门店的管理效率提升非常明显。

适合谁来参考这份拆解？第一类是正在做毕业设计、需要从零搭建并写论文的同学，第二类是刚学完Spring Boot基础、想找一个完整项目练手的Java开发者，第三类则是真有小微汽修厂信息化需求、想评估技术方案的人。这篇文章不会只停留在“这个系统有什么功能”的层面，而是会把标题背后涉及的技术选型、数据表设计、权限模型、部署调试细节、论文写作思路全部铺开来讲，尽量做到拿过去就能用、照着做就能跑通。

我当年做类似项目的时候，最头疼的并不是Spring Boot本身的API使用，而是“不知道一个完整业务系统的代码到底该怎么组织”。看完这篇，你应该能少走不少弯路。

2. 核心业务与整体设计思路

2.1 汽修门店的真实业务场景

在拆解系统之前，得先搞清楚汽修厂每天到底在忙什么。这不是空对空的理论分析，而是整个项目功能设计的源头。

一家典型的综合汽修店，日常业务大致可以画成一条线：客户进店或者电话预约，前台登记车辆信息和故障描述，开出一张维修工单；工单派给车间主管，由主管分配给具体的机电技师或者钣金喷漆师傅；技师检查车辆，可能需要领用机油、滤芯、刹车片等配件，这些配件从仓库出库并登记；修完之后质检，通知客户取车，结算工时费和材料费；最后客户付款离店，这笔单子归档。如果车辆问题复杂，流程还可能反复，比如增项维修、客户追加项目、配件缺货需要订货等待。

这个流程里有几个关键痛点：纸质工单容易丢、维修历史查不到、库存经常对不上账、月底统计营收崩溃。系统设计要解决的核心，就是把这些线下动作搬到线上，让每个环节的状态变化都留痕。所以，我建议在设计功能模块之前，先画一张业务流程图，把角色、动作、数据实体之间的关系梳理清楚，再去建表写代码。很多同学一上来就写Controller，写到后面发现字段对不上、状态流转混乱，基本都是因为跳过了这一步。

2.2 技术选型为什么是Spring Boot

现在JavaWeb领域的框架选择挺多的，但毕业设计和中小企业项目里Spring Boot依然是绝对的主流。原因不复杂，首先是“约定大于配置”，一个内嵌Tomcat的jar包就能跑起来，省掉了传统SSH（Spring MVC + Spring + Hibernate）时期繁琐的XML配置；其次是生态太完整，Spring家族把数据访问、安全认证、任务调度、消息队列全部统一收编，网上能搜到的解决方案几乎都是基于Spring/Spring Boot的；第三是招人容易，现在企业里Java后台开发基本绕不开Spring Boot，学这个东西的投入产出比很高。

需要特别提醒的是Spring Boot版本选择的问题。我见过不少同学在GitHub上拉了一个项目，发现pom.xml里写着2.7.x，结果本地装的是JDK 17甚至JDK 21，一启动就报错。Spring Boot 2.x基于Spring Framework 5.x，官方推荐JDK 8或11，你用JDK 17强行跑，很多老版本的依赖库会直接抛异常。Spring Boot 3.x虽然也流行，但它基于Jakarta EE规范，很多旧项目用的javax包路径全部要改，工作量并不小。所以毕业设计求稳的话，Spring Boot 2.7.x配JDK 1.8或JDK 11是我个人最推荐的组合，足够稳定、资料最多、不怕掉坑。

2.3 单体架构加模块化分包

这个系统不需要搞微服务，一台服务器、一个应用、一个数据库就够了。微服务解决的是高并发、独立部署、团队协作的问题，汽修门店单日可能就几十张工单，没有那个量级。单体架构的好处是开发简单、排查问题方便、部署成本低，正好切合毕业设计的体量。

代码组织上，我建议采用标准的包分层结构，而不是所有类堆在一起：

com.example.autorepair ├── config // 配置类，如跨域、拦截器、异常处理 ├── controller // 前端接口入口 ├── service // 业务逻辑层接口 ├── service.impl // 业务逻辑实现 ├── mapper // MyBatis数据访问接口 ├── entity // 数据库实体类 ├── dto // 数据传输对象，用于请求和响应 ├── vo // 视图对象，用于前端展示 ├── utils // 工具类 ├── common // 公共返回结果、常量、枚举

分层的目的不是形式主义，而是为了以后好维护。一旦业务逻辑复杂起来，Controller里堆SQL的写法会让你寸步难移。另外，前后端交互最好统一一个Result对象，比如{code: 200, message: "success", data: ...}，这样前端处理起来很顺手，后端异常也能统一包装，不至于一报错就返回一坨默认异常堆栈。

我记得有一次做联调，前端同事问我“接口返回的数据结构是什么”，我当时没统一包装，每个接口返回格式都不太一样，结果他解析数据解析到崩溃。后来花了一个下午把所有接口改成统一的Result风格，一下就顺畅多了，这个教训我记得很深。

2.4 数据访问层：MyBatis还是Spring Data JPA

数据访问层的选型，可以说是这个项目里最有争议的技术点。MyBatis和Spring Data JPA各有拥趸，选哪个都有道理，但考虑因素不一样。

MyBatis的优势是SQL完全可控，复杂查询、多表关联、动态条件都能精确定制，对于工单查询这种经常要“按时间范围+状态+车牌号”组合筛选的场景特别友好。而且国内很多企业老项目都是MyBatis体系，学了以后工作上手快。缺点是每个表都要写Mapper接口和XML映射，代码量偏大。

Spring Data JPA的优势是开发效率高，基础增删改查只要定义接口方法就行，连SQL都不用写，而且实体类和表结构的映射关系是由框架自动维护的，配合Hibernate的自动建表功能，本地开发非常省事。缺点是复杂查询写起来比较绕，JPQL或者Specification对新手来说有学习成本。

我的个人建议是：如果目标是快速出成果、论文以业务功能为主，选Spring Data JPA；如果想把SQL功底展示出来，后期应对复杂统计报表更顺手，选MyBatis。汽车维修管理系统涉及大量的多表关联查询（工单联客户、联车辆、联配件、联员工），还有按日期统计营收这类聚合查询，用MyBatis写SQL会更直观，排查问题也更快。

这里插一句，不管用哪个框架，数据库连接池都建议用Druid或者HikariCP，其中HikariCP是Spring Boot默认推荐的，性能很好，Druid的优势则是有监控页面，可以看到SQL执行情况，调试时比较实用。

3. 数据库设计：核心表结构与状态流转

3.1 从业务实体到数据模型

数据库设计是整个系统的地基，地基不稳，后面写代码全是坑。汽修维修服务管理系统的核心实体其实就那些，我根据实际业务场景整理了一张清单：

• 客户（customer）：姓名、电话、地址、会员等级、备注
• 车辆（vehicle）：车牌号、品牌、型号、颜色、里程数、车架号、所属客户
• 员工（employee）：姓名、账号、密码、角色、手机号、入职时间
• 维修工单（repair_order）：单号、客户、车辆、接车人、故障描述、状态、开单时间、预计完工时间、实收金额
• 工单明细（order_item）：所属工单、维修项目、工时费、配件费、状态、执行技师
• 配件（part）：编码、名称、规格、单价、库存数量、预警阈值、供应商
• 配件入库记录（part_stock_in）：配件、数量、进货价、供应商、入库时间
• 配件出库记录（part_stock_out）：关联工单明细、配件、数量、单价
• 结算记录（payment）：关联工单、应收、实收、支付方式、收款人、时间

这些表之间的关系很清晰：客户和车辆是一对多；工单和客户/车辆是多对一；工单和工单明细是一对多；工单明细和配件出库是一对多。外键关系建好之后，整个数据血缘就理清了。

3.2 工单状态机设计

维修工单是整个系统状态流转最复杂的实体，它的状态变化一定要设计好，不能随便拿一个字符串字段然后到处改。我建议用一个整数或者短字符串表示状态，然后定义清晰的转移规则：

• 待接单：前台开单成功，等待车间接车
• 维修中：车间师傅已经接过单，正在检查或维修
• 待质检：维修完成，等待质检确认
• 待结算：质检通过，等待客户付款结算
• 已完成：付款完成，工单归档
• 已取消：客户取消维修或异常作废

这里有个细节，工单状态必须遵循顺序流转，不能从“维修中”直接跳到“已完成”，否则前端展示的历史流程就乱了。实现方式可以在Service层里对状态转移做前置校验，也可以在前端把按钮的可用状态绑定到当前状态上。更严谨的做法是用状态机模式封装，但对毕业设计而言，在业务逻辑里加一层状态校验已经足够。

许多同学的数据表里只放了“状态”这一个字段，没有状态变更历史表，结果论文里写“系统可以实现维修进度的全程跟踪”时底气不足。如果要让系统更有说服力，可以增加一张order_status_log表，记录每一次状态变更的操作人、旧状态、新状态、变更时间。这样查询车辆维修历史时，就能像物流轨迹一样展示每一步，功能完整度立刻上一个档次。

3.3 关键表结构示例

车辆表是相对容易被忽视但其实很重要的表，它承担了“一车多修”的历史档案功能。设计时要注意车牌号设为唯一索引，同时把车架号（VIN）也存下来。车辆常见字段如下：

vehicle ├── id BIGINT PK ├── plate_no VARCHAR(20) -- 车牌号，唯一索引 ├── vin VARCHAR(50) -- 车架号 ├── brand VARCHAR(50) -- 品牌 ├── model VARCHAR(50) -- 型号 ├── color VARCHAR(20) ├── mileage INT -- 当前里程 ├── customer_id BIGINT -- 所属客户 ├── create_time DATETIME

工单表则要把业务关键信息都带上，单号建议生成一个可读性强的编号，比如“20240512-001”，前缀是日期加当天序号。这个单号在客户电话咨询和前台查单的时候非常好用，比纯数字ID直观得多。普通项目里很多人直接就用自增ID当单号，客户报ID说数字太大，前台一脸懵，改成这种可读编号之后体验会好很多。

工时费和配件费要分开存，因为实际结算时涉及不同税率和提成规则。工单表里加一个total_amount字段作为冗余合计也没问题，报表统计时不用反复聚合。业务上，工时费由维修项目决定，配件费由出库配件的数量和单价累加得到，这个逻辑在后面计算结算单时要写清楚。

3.4 库存设计与数据一致性

汽修厂的配件库存是容易被忽略的模块，但它是整个系统里最能体现工程素质的地方。配件表里必须有库存数量和预警阈值，每次维修工单领用配件时，库存表要同步扣减，如果库存不足则不允许出库或给出提示。采购入库时库存增加。

这一块有个经典的坑：并发扣库存。假设两个技师同时领用同一款机油滤芯，如果代码没有加锁或者数据库没有事务控制，就可能出现超卖，库存变成负数。解决方式很简单，在扣减库存的SQL语句里加上条件：

UPDATE part SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}

如果更新影响行数为0，说明库存不足，直接抛出业务异常。同时用@Transactional注解保证“扣减库存+登记出库记录+更新工单明细配件费”这三个操作要么全部成功，要么全部回滚。这条经验我真心建议写进论文的“关键技术”部分，面试时被问到“高并发下如何保证数据一致性”也能有话说。

4. 功能模块设计与核心实现

4.1 系统角色与权限控制

汽修管理系统不是给单一角色用的，不同身份的人看到的界面和操作权限完全不同。我在系统里划分了几个角色：

• 管理员：拥有全部权限，包括员工管理、数据统计、系统设置
• 前台接待：负责客户登记、车辆录入、开单、结算
• 车间主管：派工、审核工单、质检
• 技师：查看分配给自己的工单、填写维修项目、领用配件
• 库管员：配件入库、出库、库存盘点

权限控制这一块，毕业设计最常见的两种方案是Spring Security和拦截器/过滤器。Spring Security功能强大，但学习曲线陡，配置不当反而容易出问题；拦截器方案简单直接，维护成本低，对业务系统来说完全够用。

我倾向于在登录接口生成一个token（可以简单用UUID或者JWT），存入Redis或者数据库，然后写一个拦截器，在进入Controller之前校验token和角色权限。这种方案的优点是不用引入太多概念，出现Bug也好定位，论文里还能把“基于Token的身份认证机制”作为亮点来写。缺点是对于真正要做企业级项目的人来说可能不够严谨，但毕业设计的角色定位恰好是“学习与演示”，够用即可。

实际编码时，可以用一个自定义注解@RequireRole("ADMIN")标注在Handler方法上，拦截器读取注解然后比对当前用户角色。这样权限逻辑集中管理，代码看着也清爽。

4.2 核心业务流程：从开单到结算

整个系统最重要的业务闭环就是工单主流程，我拆成了几个关键接口：

1. 前台创建工单：接收customerId、vehicleId、故障描述，生成工单号，状态设为“待接单”
2. 车间主管派工：将工单分配给技师，同时可以添加多个维修项目，状态改为“维修中”
3. 技师填写维修记录：在工单明细里补充实际执行内容、工时、使用的配件，系统自动计算配件费
4. 质检确认：主管或专职质检员标记质检通过，状态改为“待结算”
5. 生成结算单：根据工单明细合计工时费和配件费，生成应付款项，客户支付后状态改为“已完成”

这里有一个需要特别注意的点：工单明细和配件领用是两个不同的操作。一个维修项目对应一条detail记录，一个detail可以对应多条配件出库记录。如果把配件直接一股脑塞到detail表里，后面统计配件消耗和库存对账就会非常痛苦。所以在数据库设计阶段就把这两张表分清楚，编码时才能保持条理。

4.3 前端页面设计思路

标题里提到“系统界面在最后面”，说明这个项目包含完整的前端页面。我在实际开发中强烈建议，除非公司或学校明确要求前后端分离，否则毕业设计用Spring Boot + Thymeleaf + Bootstrap就足够，理由很简单：不用解决跨域问题、不用单独部署前端、模板语法简单，而且对于传统“点击表单提交→刷新页面”的管理系统体验并不差。

如果确实想用Vue + Spring Boot分离开发，那就要把跨域、Token鉴权、异步请求这些环节处理好，工作量会明显增加，但对前端技能提升也有帮助。我的建议是：如果你的前端基础一般，就用Thymeleaf；如果目标企业是前后端分离团队，那做一套Vue3 + Element Plus的前端会更有展示力。

页面清单大致如下：登录页、工作台/首页（待办工单数量、今日营收）、客户管理页、车辆管理页、工单列表页（支持按状态/时间/车牌筛选）、工单详情页（维修项目+配件明细时间线）、配件管理页、库存预警页、报表统计页。这里提一个小技巧，列表页的筛选条件尽量做得丰富一点，既能提升用户体验，也能在论文里写上“支持多条件组合查询”，这是评审老师比较看重的能力点。

4.4 报表统计与数据可视化

汽修系统里老板最关心的其实不是工单操作，而是“这个月赚了多少、哪些项目卖得好、配件成本占多少”。做报表统计模块，本质上是把工单表和结算表的数据按时间维度聚合并展示成图表。

毕业生在这个模块可以选两种做法。一种是使用ECharts这个纯前端图表库，后端只提供JSON数据，前端渲染柱状图、折线图、饼图。另一种是后端直接用Apache POI导出Excel报表，老板可以下载到本地保存。二者并不冲突，有时间可以都做。

实现统计接口时，SQL可以用MyBatis直接写聚合语句：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(total_amount) AS revenue, COUNT(*) AS order_count FROM repair_order WHERE status = '已完成' AND create_time >= #{startTime} AND create_time <= #{endTime} GROUP BY DATE_FORMAT(create_time, '%Y-%m') ORDER BY month

这种统计报表是论文里“系统测试与效果分析”章节最直观的素材，一张趋势图比一千文字说明都更有说服力。

5. 调试部署与开发环境构建全流程

5.1 开发环境清单与版本匹配

构建开发环境，最忌讳的是一台机器上多个大版本软件互相冲突。我给出一套经过验证的组合，按这个来基本不会出问题：

• JDK：1.8（对应Spring Boot 2.7.x最稳）
• IDE：IntelliJ IDEA Community Edition 或 Ultimate
• Maven：3.6.3或3.8.x
• 数据库：MySQL 5.7或8.0
• 数据库可视化工具：Navicat或者DBeaver
• Redis（可选，做Token存储时使用）

这里我想特别强调JDK和Spring Boot的版本匹配，这是新手翻车最多的地方。很多教程视频用的Spring Boot 2.x JDK 1.8，自己去官网下载却装了最新的JDK 21，编译的时候代码没问题，但启动直接报”UnsupportedClassVersionError”。建议在安装JDK之前先确定项目的Spring Boot版本，再有针对性地安装对应JDK，不要盲目追求“最新”。

5.2 从GitHub拉取项目到本地跑通

假设你已经拿到了源码压缩包或者从仓库克隆下来，第一步是检查项目结构，看看是Maven工程还是Gradle工程。Maven就看pom.xml，Gradle就看build.gradle，Spring Boot项目一般都有个主启动类，标注了@SpringBootApplication注解。

接下来修改application.yml或application.properties里的数据库连接配置：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/auto_repair?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 jpa: hibernate: ddl-auto: update show-sql: true

如果你用的是MyBatis，记得确认mapper-locations路径是否指向resources/mapper目录。很多报错“Invalid bound statement (not found)”都是因为application.yml里没配mybatis.mapper-locations。

然后执行src/main/resources目录下提供的SQL脚本，把数据库和基础数据初始化好。不要嫌麻烦，直接按顺序执行建库脚本、建表脚本、插入测试数据脚本。线上项目可能用Flyway这样的迁移工具，毕业设计手工执行SQL就够了。

最后启动主类，控制台出现“Started Application in xxx seconds”并且Tomcat started on port(s): 8080，说明启动成功。如果端口被占用，修改server.port为8081或其它。

5.3 调试技巧与常见报错

调试阶段是花时间最多的地方，我把自己踩过的坑整理一下，大家可以直接对照排查。

第一类是依赖下载问题。Maven第一次构建会下载大量依赖，国内网络环境下经常卡在中央仓库，解决方法是配置阿里云镜像：

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

在settings.xml里加完镜像，构建速度会快很多。

第二类是时区问题。MySQL连接参数里没有加serverTimezone=Asia/Shanghai，报错“The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized”或者查询出来的时间差8小时。加参数就好，另外可以直接在MySQL里执行set global time_zone = '+08:00'。

第三类是数据库编码问题。插入中文数据出现乱码，建库时一定要指定utf8mb4。MySQL的utf8mb3只能存基本多语言字符，存不了emoji和部分生僻字，用utf8mb4才是正确姿势。建库SQL可以这样写：

CREATE DATABASE auto_repair DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

第四类是Lombok插件问题。实体类用了@Data注解但IDE报错找不到getter/setter，大概率是IDEA没装Lombok插件，或者Maven没有引入依赖，逐个排查即可。

第五类是JPA或MyBatis的N+1查询问题。工单列表要展示客户名称和车型，如果循环里逐条查关联表，数据量小的时候没感觉，数据量大了接口响应就会很慢。解决办法是用关联查询一次性查出，或者在列表VO中批量组装。这个点在论文“性能优化”章节里也很加分。

5.4 部署到云服务器

本地跑通只是第一步，真正的毕业答辩如果能现场演示一个部署在服务器上的系统，效果会好很多。部署方案有两种，第一种最直接，在服务器上安装JDK和MySQL，然后把项目打成jar包，执行：

mvn clean package -DskipTests

然后上传jar包到服务器：

nohup java -jar auto-repair-0.0.1-SNAPSHOT.jar > server.log 2>&1 &

第二种更现代化的方案是容器化部署，写一个Dockerfile，把jar包打进去，再加docker-compose编排MySQL和Redis：

FROM openjdk:8-jdk-alpine VOLUME /tmp COPY target/auto-repair-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java","-jar","/app.jar"]

容器化部署的好处是环境隔离，以后迁移服务器非常方便。注意开放服务器安全组的8080端口，并配置好防火墙规则，不然外部访问不了。

6. 论文写作与答辩准备要点

6.1 万字论文的章节规划

标题里特意提到“带论文文档1万字以上”，说明论文份量不能太水。我见过不少人的论文是东拼西凑，查重直接飘红。写论文的核心思路是用“问题导向”来组织内容，不要单纯堆功能。

一个比较合理的万字论文结构可以是：

• 第1章 绪论：研究背景与意义、国内外现状、研究内容、论文结构
• 第2章 相关技术介绍：Spring Boot、MyBatis/JPA、MySQL、前端技术、开发工具
• 第3章 系统分析：可行性分析（技术/经济/操作）、需求分析（功能性/非功能性）、用例图
• 第4章 系统设计：总体架构图、功能模块设计、数据库设计（ER图+表结构）、接口设计
• 第5章 系统实现：核心功能模块的实现过程、关键代码片段、页面效果截图
• 第6章 系统测试：测试环境、测试用例设计、功能/性能测试结果、测试结论
• 第7章 总结与展望：项目收获、不足与后续改进方向

关键技巧是把“技术选型对比”放在第2章，写得有分析性一些，评审老师最烦那种百科式的技术介绍。比如说“为什么选择Spring Boot而不是SSH”，要给出几条有逻辑的理由。

6.2 图表与测试用例是加分项

论文里一定要有ER图、系统架构图、用例图、时序图。很多同学不知道这类图怎么画，其实用StarUML、ProcessOn都可以。时序图画一个“开单→派工→维修→结算”的完整流程，基本就把业务逻辑说透了。

测试章节不能只写“系统运行正常”，要给出具体的测试用例表格。比如：

用例编号	测试场景	输入条件	预期结果	实际结果
TC001	前台登录	正确账号密码	登录成功进入首页	通过
TC002	创建维修工单	选择客户/车辆，填写故障描述	生成工单号，状态为待接单	通过
TC003	库存不足领料	配件库存1，领用2	提示库存不足，出库失败	通过

这种表格既容易写，又显得专业，还能证明你真的做了测试。

6.3 答辩现场的常见问题

答辩时老师一般会问几类问题。第一类是技术类，“Spring Boot的自动配置原理是什么”“MyBatis和Hibernate有什么区别”“你是怎么设计数据库的，为什么拆成这些表”；第二类是业务类，“如果两个技师同时领最后一个配件怎么处理”“客户维修过程中加项目怎么操作”；第三类是“你这个系统还有什么可以改进的地方”。

准备工作建议：把项目启动过程的关键日志看清楚，把数据库所有表的关系理清楚，把自己写的核心代码能讲清楚。如果回答不上来某个问题，不要慌，诚实地承认“这块我还没有深入”比硬编一个答案更容易过关，然后补一句“但是我有想过可以通过什么方式去解决”，把思考过程展示出来，老师一般就会放过。

7. 经验总结与避坑指南

做这个项目前前后后我踩了不少坑，最后分享几个比较实际的体会。

第一，不要为了炫技引入一堆用不上的技术。有些人看到网上的开源项目用了Redis、RabbitMQ、Elasticsearch，就想着全部塞进自己的毕业设计里。结果环境装了一个星期，项目还没跑起来。技术是为业务服务的，汽修管理系统用Spring Boot + MySQL + MyBatis就能覆盖90%的需求，先跑通再谈扩展。

第二，业务状态设计一定要提前想清楚。我看到很多项目的工单状态是随便定义的字符串，前端一个按钮调用接口改状态，没有任何约束。当时看着能用，等论文截图的时候发现状态乱跳，很尴尬。把状态机提前定义好，前端按钮按状态控制显隐，后端做个前置校验，两个下午的功夫，体验和严谨度完全不一样。

第三，每完成一个功能模块，就要记录测试数据和截图。论文写作阶段最怕回头补截图，界面已经改版了，功能参数也不对了，重新造数据浪费时间。开发过程中边做边截图，每张图配上文字说明，写论文的时候直接拼接，效率能提高很多。

第四，项目命名和代码注释要规范。代码里的类名、方法名、变量名用有意义的英文单词，不要用拼音缩写。评论区老师不一定会逐行看代码，但如果打开项目发现注释清晰、结构整洁，印象分会高一大截。我见过一个同学把“领取配件”写成“lingqupeijian”，答辩老师问了一嘴，场面非常尴尬。

这个项目后续其实还可以继续扩展，比如增加会员储值卡、微信小程序端、消息通知、维修进度实时推送、财务对账模块，甚至把多门店连锁管理做进去。做毕业设计只是第一步，把这些扩展点想明白，面试的时候跟面试官聊系统演进思路，反而更能展现你对整个业务系统的理解。