企业官网建设流程全解析

做汽车维修预约服务系统这个项目之前，我其实在门店端踩过不少坑。很多车主打电话预约保养，前台拿纸质本子记，记完还得扯着嗓子喊技师确认时间，赶上高峰期，同一个工位能排两队。后来我接手这套基于Spring Boot的汽车维修预约服务系统，才真正把预约、工单、车辆档案、结算这一条链跑通。今天就把这个项目的设计思路、核心表结构、预约逻辑和部署遇到的那些坑，一次性讲透。

这篇内容适合谁看？如果你是在校生拿Spring Boot做毕业设计，或者小维修厂想上一套预约系统，再或者你纯粹是想知道一个完整的预约业务怎么从零落地，这篇文章都能给你一个能直接抄作业的底子。我不打算只列代码，更想讲清楚每一步为什么这么设计。

1. 项目定位与整体设计思路，先想清楚再动手

1.1 汽车维修预约到底在预约什么

很多人刚拿到这个题目时，第一反应是做一个在线选时间的日历，类似预约理发那种。但汽车维修预约和理发预约有一个本质区别：维修预约不只是占一个时间段，它还涉及技师技能匹配、工位资源、配件库存和预计工时。车主想预约的是“明天上午把车开过去做个大保养”，而系统要回答的不只是“有没有空位”，还要回答“明天上午哪个技师会做这个车型”“对应工位空不空”“保养套餐里的机油有没有库存”。

所以我做需求分析的时候，把系统拆成了四类使用角色，每类角色的诉求完全不同：

• 车主端：绑定车辆、选择服务项目、查预约记录、看维修进度、收结算单。
• 接待前台：代客下单、确认预约、到店核销、引导车辆入场。
• 维修技师：查看今日预约列表、接单、登记检查结果、填报工时和配件。
• 老板/管理者：看门店工位利用率、技师工作量、预约取消率、营业收入。

这四类角色在同一个Spring Boot项目里，其实不需要拆成四个服务，单应用按角色区分接口权限就行，前期不引入微服务那套复杂的东西。关键是把业务闭环打通：车主预约到店，前台确认，技师开工，完工结算，记录沉淀到车辆档案里，下一次保养提醒从档案里计算出来。

1.2 技术栈为什么选 Spring Boot

这套系统我用了 Spring Boot 3 + MyBatis-Plus + MySQL + Redis + Vue 3 的组合，选型不是拍脑袋，是实际对比过的。

Spring Boot 相比传统 SSM 的最大优势，是自动装配和起步依赖。以前做SSM项目，配置数据源、配置事务管理器、配置Spring MVC每个都要写一大堆XML，现在一个spring-boot-starter-web就把Web容器、JSON序列化、默认异常处理全部带进来了。内嵌Tomcat的特性也让部署变得非常轻量，一个jar包放到服务器就能跑，不要求运维懂太多Java中间件。

持久层我用 MyBatis-Plus 而不是纯 MyBatis，原因是预约列表的查询条件太碎了：按门店查、按状态查、按车辆查、按日期范围查，手写SQL虽然也可以，但工作量明显变大。MyBatis-Plus 的条件构造器让我可以很快拼接查询条件，分页插件也是现成的。Kepp in mind：MyBatis-Plus 在 Spring Boot 3 时代要用新版本，老版本会因为包路径变化直接启动失败，这个坑后面细说。

Redis 在这个项目里不是摆设，主要做了三件事：缓存当天预约时间槽、做分布式锁防止同一个时间段被重复下单、存储预约待支付的临时单。前两件事是预约系统的核心稳定性保障，后面我会展开讲。

前端选了 Vue 3 + Element Plus，和后端通过 JSON 交互，属于典型的前后端分离方案。实际部署时默认推荐 Nginx 反向代理到后端接口，但为了让学生项目或者小门店能简单部署，我也会讲怎么把 Vue 打包好的静态文件放进 Spring Boot 的静态目录里，打成单 jar 运行。

1.3 核心业务闭环

这个系统的核心业务闭环是我反复给团队讲的一张流程：

注册登录 → 绑定车辆（VIN码/车牌） → 选择服务项目 → 选择门店和时间槽 → 提交预约 → 前台确认/系统自动确认 → 到店核销 → 技师接车检查 → 生成维修工单 → 报价确认 → 维修执行 → 完工质检 → 结算 → 回访记录 → 车辆档案更新（保养里程、维修历史）

每一个环节在数据库里都对应明确的状态字段和操作记录，这也是项目能上线运营而不是停留在演示Demo的关键。下面重点拆解数据库设计和核心逻辑。

2. 数据库设计，别把预约做成“假日历”

2.1 用户与车辆档案表

用户表我保持了相对简单的设计，单表存用户，用role字段区分角色。这里不推荐做多张用户表然后 join 来 join 去，那是在给自己找麻烦。角色就四类：车主、前台、技师、管理员，一个数字字段就能表达。

车辆档案表是整个系统的“资产表”，这辆车做过什么保养、什么时候换过刹车片、保险公司是哪家、VIN码对应什么车型配置，全部沉淀在这里。核心字段有car_id、user_id、plate_no、vin_code、brand、model、mileage、last_maintain_mileage、insurance_expire_date。

有一个很容易忽略的点：VIN码一定要做格式校验，17位，排除字母I、O、Q。前挡风玻璃上那一串码如果录错一次，后面所有保养记录都会对不上。我的做法是在前端做正则校验，后端再加一道@Pattern校验，双保险。

2.2 预约与工单核心表

预约主表service_appointment我设计的字段大概是这个思路：

时间槽表appointment_slot是预约系统的核心资源表，我会在第3章详细讲。工单表repair_order关联预约单，记录技师实际执行的维修项目、配件明细、工时费用和结算状态。

这三张表的关系是：预约单是“客户意愿”，工单是“实际干活”，时间槽是“资源占用”。三者通过预约单号关联起来，但状态各自独立，因为预约被取消不代表工单已经被删掉，工单一旦生成就要归档。

2.3 状态流转设计

预约状态和工单状态是两套状态机，别混在一起。

预约状态我控制在7个以内，状态只允许按固定方向流转：待确认 → 已确认 → 已到店 → 维修中 → 待结算 → 已完成。取消这个动作从待确认和已确认状态都可以直接跳到已取消，但不能从维修中直接取消，除非这个预约对应的工单已经废弃。这个限制在代码里用枚举校验实现，不能仅仅靠前端按钮隐藏，不然用Postman直接调接口就能把状态改乱。

工单状态我简化成更轻量的流程：检查中 → 待报价 → 维修中 → 待质检 → 已完工 → 已结算。注意工单是“干活的事”，它不关心预约是否被放鸽子，只要车开进来了，工单就开始独立流转。

我用整数枚举而不是字符串存状态，一个是为了查数据库时索引效率更好一点，另一个是避免字符串拼写错误导致状态判断失灵。比如写status = "confirmed"和status = "Confirm"你肉眼很难发现，但Integer.valueOf(1).equals(status)这种判断就永远不会错。

3. 预约时间槽与冲突处理，核心逻辑要稳

3.1 时间槽怎么生成和扣减

预约模块最容易踩坑的地方就是时间槽。一开始我图省事，只存了预约的expect_start_time，然后在查询空闲技师/工位时，直接数据库里查找时间段有重叠的预约记录。功能看起来能跑，但当预约数量多起来之后，每次选时间都要实时算一遍，数据库压力大，而且容易出现间隙。

后来我改成“预生成时间槽”方案。门店提前一天按配置生成第二天的全部时间槽，比如营业时间是 09:00 到 18:00，每个时段30分钟，那么一台工位一天生成18个时段，一个是“空闲/已占”的二进制判断，另外再记录起始时间和结束时间。

生成时间槽的定时任务我用 Spring 自带的@Scheduled实现，每天凌晨2点生成所有门店、所有工位未来7天的时间槽。如果发现某个时间槽已经生成了就跳过，保证幂等。这里还活跃了一个变量：每个工位在同一时间最多只能被一个预约占用，所以扣减时间槽时，不能简单地把整个时间槽标记为已占用，而是要判断新预约的时间范围是否和已有的预约重叠。

简化后的判断逻辑是这样的：一个新的预约[start, end)要成功，必须满足它覆盖的所有最小时间槽里，没有一个已经被其他预约占用。比如预约9:00到10:30，那必须9:00、9:30、10:00三个槽全部可用才能下单。

3.2 三种冲突场景，一个都不能漏

预约冲突我归纳成三类：

• 同技师冲突：同一个技师在同一个时间区间里不能接两辆车。这个判断要按人维度做，不能只看工位。因为有的门店技师少工位多，工位闲着但技师满了。
• 同工位冲突：同一个举升机上不能同时放两辆车。这个按工位维度判断。
• 同车辆冲突：同一辆车不能在同一个时间段有两笔有效预约。这个比较容易忽略，车主有可能手滑重复提交。

对应到数据库设计里，建议建一个唯一性约束，虽然表面看起来是业务级校验，但数据库约束是最后的兜底。MySQL 的 InnoDB 支持索引，所以在预约表上建立一个(car_id, status, expect_start_time)的联合索引，能明显提升冲突查询速度，同时对高并发下单也有一定的锁保护作用。

3.3 分钟级锁定与超时释放

在线预约经常出现的情况是：车主选好了时间、填完了车辆信息，但是卡在支付押金或者犹豫要不要提交这一步。如果不做任何机制，这个时间槽会被他白白占住，别的车主想选却选不了。

我的方案是“预占 + 超时释放”。车主提交预约请求时，系统先不真正写预约单，而是在 Redis 里以slot:{storeId}:{date}:{time}为 key 做一个15分钟的占位，value 存用户ID。15分钟内如果用户确认支付，这个占位转成真正的预约记录并释放锁；超时的话，用一个延迟任务把 Redis key 删掉，时间槽恢复空闲。

实现超时释放有两种做法：一种是用 Redis 的 Key 过期事件，配合 Spring 的监听类来感知；另一种是启动一个定时任务，每1分钟扫一次 Redis 中过期时间小于当前时间的占位 key。我用的是第二种，更可控，因为 Redis 过期事件默认不是精确触发的，在低版本上有延时。

4. 核心模块实现与代码实操

4.1 创建 Spring Boot 项目与基础配置

用 IDEA 创建 Spring Boot 3 项目时，记住几个重点：Java 选择 17 及以上，Spring Boot 3 不支持 Java 8；依赖里把 Spring Web、MySQL Driver、MyBatis-Plus、Lombok、Validation 都选上。如果你是手动往pom.xml加依赖，建议用下面这个基线版本组合，实测稳定：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>3.5.7</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> </dependencies>

这里要强调一个坑：MyBatis-Plus 在 Spring Boot 3 下要用mybatis-plus-spring-boot3-starter这个独立坐标，而不是旧的mybatis-plus-boot-starter。旧坐标在 Spring Boot 3 里会报ClassNotFoundException或者自动配置不生效，并且通常不会告诉你是版本问题，排查起来很费时间。

然后在application.yml里配置数据源、端口和 MyBatis-Plus 的日志打印。开发环境我习惯打开 SQL 日志，方便追踪自动生成的 SQL 是否符合预期。加一句：

mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

生产环境记得关掉，或者切到Slf4jImpl按日志级别输出，不然控制台会被 SQL 刷爆。

4.2 预约下单接口：事务加锁缺一不可

预约下单是整个项目里最考验代码功底的一个接口，因为涉及到多步操作：校验时间槽、生成预约单、扣减时间槽、记录操作日志，每一步都可能抛异常，所以必须加事务。如果哪一步失败，前面已扣减的时间槽必须回滚，否则会出现“预约失败但时间被占”的情况。

我提供了两种实现方式。单机部署就选同步锁加事务，直接简单。核心代码如下：

@Transactional(rollbackFor = Exception.class) public AppointmentResult createAppointment(AppointmentCreateDTO dto) { // 1. 校验车辆属于当前用户 Car car = carMapper.selectById(dto.getCarId()); if (car == null || !car.getUserId().equals(dto.getUserId())) { throw new BusinessException("车辆信息不存在"); } // 2. 锁定时间槽，防止并发冲突 boolean locked = slotService.tryLockSlot(dto.getStoreId(), dto.getExpectStartTime(), dto.getExpectEndTime()); if (!locked) { throw new BusinessException("该时段已被预约，请选择其他时间"); } // 3. 计算预计结束时间 LocalDateTime endTime = calcEndTime(dto.getServiceType(), dto.getExpectStartTime()); // 4. 插入预约记录 Appointment appointment = buildAppointment(dto, endTime); appointmentMapper.insert(appointment); // 5. 记录时间槽占用明细 slotService.occupySlot(appointment); return AppointmentResult.success(appointment); }

tryLockSlot底层在单机环境我用的是基于数据库的行锁加上一个 Redis 预占的逻辑。核心就是不要让两个请求同时通过“该时段空闲”的检查，否则后面的插入会互相覆盖。

参数校验我用@Validated注解，请求 DTO 里加上@NotNull、@Future这些约束。有个细节：expectStartTime必须要求在提交时是未来10分钟之后的时间，不然客户提交秒级预约，技师刚看到消息车就到了，完全没有准备时间。

4.3 报价计算：工时费加配件费还要考虑套餐

维修报价是门店老板最看重的模块。简单做一个“项目单价乘数量”不难，但实际业务里报价涉及工时定额、门店工时费率、配件成本、套餐折扣、会员折扣。我采用的是策略模式加明细表，避免把一堆判断逻辑写在一个calcPrice方法里。

工时费的计算逻辑是：每个服务项目在service_item表里有标准工时，比如换机油是0.5小时，大保养是2.5小时。门店可以设置自己的工时单价，比如120元/小时。所以一单的工时费 = 工时定额 × 工时单价。配件费则来自part_item表，维修工单创建时逐个录入配件，最后累计。

报价明细单独存一张repair_order_item表，每条记录都带item_type（1工时 2配件 3套餐），然后主表repair_order里冗余一个total_amount，方便列表页直接显示，不用每次汇总。

这里要特别注意：报价保存后，技师后面又加了维修项目，这一单的金额会变化，所以在状态流转到“待结算”之后，要禁止修改工单明细。除非走“价格调整单”流程，并记录操作人和调整原因，这既是业务要求，也是事后审计的依据。

4.4 保养提醒与消息通知

车辆档案里记录了上次保养的里程和到期日期，系统要能自动算出“这辆车是不是该保养了”。计算规则不复杂：当前里程减去上次保养里程大于等于5000公里，或者距离上次保养时间超过6个月，满足任一条件就触发提醒。

这个提醒不是单纯的系统日志，要真正推到车主那里才有价值。我的做法是维护一张remind_record表，定时任务每天扫描车辆档案，生成待提醒列表，然后通过微信服务号模板消息或者短信 API 推送给车主。因为是 Spring Boot 项目，消息推送的客户端只需要封装一个 HTTP 请求的 Service 类即可。

定时任务建议单独开一个配置类，用@EnableScheduling启动。不要写在 Web 层的 Controller 里，一个是不安全，另一个是启动时会执行两遍导致重复提醒。定时任务的执行时间选在早上10点和下午4点，避开晚上推送，否则容易被用户投诉骚扰。

5. 前端联调与部署，流程走通才算数

5.1 前后端联调的三个高频问题

前后端分离开发的模式确定下来之后，联调阶段我总结了三个高频问题：

第一个是跨域。前端在 localhost:5173 起的 Vite 开发服务，后端跑在 localhost:8080，浏览器会拦截非同源请求。解决方式是在 Spring Boot 里写一个跨域配置类，实现WebMvcConfigurer的addCorsMappings，允许的前端源明确写出来，不要图省事直接allowedOriginPatterns("*")，那样会把后端暴露给所有网站，不安全。

第二个是 Token 传递。后端的登录接口返回 token 后，前端每次请求要在 Header 里带上Authorization: Bearer xxx。我在 Spring Boot 里加了一个拦截器，统一从 Header 取 token，解析出用户信息后放到ThreadLocal里，后面的 Controller 方法直接用。好处是业务代码不用每处都传 userId，缺点是要小心线程池场景下的ThreadLocal内存泄漏，所以过滤器最后必须在 finally 里 remove。

第三个是日期格式。前端传递的日期字符串通常是2025-06-13 09:00:00，后端如果用LocalDateTime接收，要提前在配置里指定 Jackson 的反序列化格式，否则会报DateTimeParseException。统一在application.yml里写：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

这个 time-zone 一定要写，不然服务器在 UTC 时区、数据库存的是本地时间，返回给前端会少8小时。时区问题我排查过一次，查了半小时最后发现是默认UTC。

5.2 Vue 打包放进 Spring Boot 的单 jar 方案

Nginx 反向代理是标准部署方案，但如果目标环境只有一台小服务器、还不想装 Nginx，那就可以把前端构建产物放进 Spring Boot 的静态资源目录，打成单 jar 直接跑。

方法并不复杂。前端项目在vite.config.js里把base设置为相对路径或你希望访问的上下文路径，然后执行npm run build，生成的dist目录里的静态文件复制到后端src/main/resources/static下。后端里加一段路由转发，把前端路由（例如/和/appointment等页面路径）转发到index.html，否则直接访问这些路径是404。

@Controller public class PageForwardController { @GetMapping(value = {"/", "/appointment", "/order", "/car", "/admin/**"}) public String forward() { return "forward:/index.html"; } }

需要特别注意的是，后端接口路径必须和前端页面路由避免冲突。比如后端@GetMapping("/order")和前端路由/order就会撞上。我的做法是后端所有接口统一加/api前缀，前端页面路由不加这个前缀，从根上断开冲突。

5.3 服务器部署与日常维护

单 jar 部署的方式在 Linux 服务器上非常简单，把打包好的appointment-system.jar上传后，执行：

nohup java -jar appointment-system.jar --spring.profiles.active=prod > appointment.log 2>&1 &

第一次启动时建议先不用nohup，直接在终端前台跑，方便看到启动日志里有没有报错。启动成功后再用 nohup 放到后台。

我用的另外一条习惯是把启动参数放到外面：

nohup java -Xms256m -Xmx512m -jar appointment-system.jar \ --spring.config.additional-location=/opt/app/config/application-prod.yml \ > /opt/app/logs/appointment.log 2>&1 &

配置文件外置的好处是：哪天改数据库密码或者端口，不用重新打包 jar，直接编辑外置的 yml 然后重启即可。日志文件一定要按月切割，可以用 logback 配置，不切割的话一个月下来单个文件能到几个 GB，查日志变得非常痛苦。

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

6.1 Spring Boot 版本太高带来的连锁反应

市面上不少教程还在用 Spring Boot 2.x，有些同学图新鲜直接创建 Spring Boot 3.3 甚至 3.4，结果碰到一连串问题：JDK 版本不够、MyBatis-Plus 不兼容、javax 包名找不到。

Spring Boot 2.x 用的javax.servlet在 3.x 里变成了jakarta.servlet，如果你看的是老教程，import javax.servlet.http.HttpServletRequest会直接编译报错，这不是你写错，是包名整体迁移了。解决方案就是要么把 Spring Boot 版本降到 2.7.x，要么把所有javax替换成jakarta，二选一，别纠结。

还有 Lombok 版本也可能有问题，Spring Boot 3 要求 Lombok 1.18.30 以上。遇到Lombok @Data生成的 getter/setter 找不到方法，先查 Lombok 版本是不是太老。

6.2 预约时间槽并发下单导致超卖

预约系统最怕的问题就是“超卖”，两个车主同时抢同一个时间槽，最后两个人都付了押金，但门店只能接一辆车。

我在秒杀类场景里常用的方法是 MySQL 乐观锁。时间槽表加一个version字段，更新时先查 version，然后执行更新时带WHERE version = 旧值，如果更新影响行数为0，说明这一秒被其他事务抢先修改了，当前请求直接返回“该时段已被预约”。

UPDATE appointment_slot SET status = 2, version = version + 1 WHERE slot_id = #{slotId} AND status = 1 AND version = #{oldVersion}

配合 Redis 预占位之后，这个方案在几十个用户同时抢两个热门时段的情况下没出过问题。如果哪天门店规模大到上千人同时抢，那就得引入消息队列削峰，但中小门店完全没必要。

6.3 事务不生效的经典场景

我帮别人看代码时经常发现一个错误：在同一个类里，一个方法调用另一个带@Transactional的方法，结果事务死活不生效。原因是 Spring 的事务是基于 AOP 代理的，类内部方法调用走的不是代理对象，而是原始对象，所以注解被忽略了。

解决办法是让它们互相分离，把事务方法放到另一个 Service Bean 里，或者像下面的代码一样通过代理对象调用：

((AppointmentService) AopContext.currentProxy()).createAppointment(dto);

不过AopContext.currentProxy()需要额外开启@EnableAspectJAutoProxy(exposeProxy = true)，我Preferred的做法还是拆类，代码更清晰，也避免测试时搞不清代理状态。另外要注意，事务方法如果被 try-catch 吞掉了异常，事务也会失效，因为框架根本不知道发生了错误。推荐把业务异常包装成RuntimeException抛出，统一由全局异常处理器转换返回给前端。

6.4 查询列表越查越慢的隐患

预约列表、车辆列表这类页面，一开始数据量小速度还行，等跑了大半年，几万条预约记录之后，列表查询开始变慢。主要原因是没有用好索引，或者查询条件没有走索引。

我的做法是：每个页面查询都通过 MyBatis-Plus 的QueryWrapper构造，确保where条件里最常用的“门店+日期范围”“车辆+状态”都有对应复合索引。另外在列表页永远只返回当前页的数据，不要一次性把所有预约记录查出来。分页插件用MybatisPlusInterceptor配PaginationInnerInterceptor，每页默认20条，最多50条，防止有人手工改参数调出一个超大分页。

还有一个小技巧：appointment_no这种业务编号字段，如果频繁做精确查询，也要单独建索引。索引不是越多越好，当写入频繁时每个索引都增加写放大，所以我会在系统上线前根据实际运行日志里的慢SQL，有针对性地补索引，而不是一开始就把所有字段都建上。

7. 写在最后的实操体会

这个项目从需求梳理到上线，我最大的体会是：不要一上来就动手写代码，先把预约的“资源模型”想明白。你订的是时间、技师、工位这三样资源，任何设计如果漏掉了其中一个维度，后面再做都是打补丁。

另外，状态机一定要控制住。我接触过的失败项目中，有一半以上是状态字段失控：这个接口把已完成的单子改成维修中，那个接口把已取消的单子重新参与对账。解决思路就是严格用枚举定义合法流转，非法流转直接抛异常，宁可前端友好提示，也不要让脏数据进数据库。

最后分享一个实际运营中的小技巧：预约系统上线后，我会在后台加一个“预约完成率”的统计指标。看起来有点虚，但这个数据非常能反映问题——如果预约完成率低于70%，说明线上预约只是“看起来方便”，实际到店率不高，一定是确认流程或者提醒机制出了问题。做技术的人不能只盯着接口耗时和并发量，多关注这些业务指标，系统的价值才能真正体现出来。