企业官网建设流程全解析

前阵子帮一个准备毕设答辩的学弟，把“基于Spring Boot的汽车销售管理系统”从需求梳理一路做到跑通、写文档、做PPT，最后顺利通过答辩。整个过程走下来最大的感受是：这个题目网上模板确实多，但绝大多数都是把登录、增删改查拼一拼就完事，答辩老师只要多问两句“订单怎么防重”“库存怎么扣减”“统计报表怎么算”，当场就容易卡壳。这篇就把我这套完整的设计思路、表结构、核心代码逻辑、踩坑记录全部写出来，给同样拿到这类题目的同学一个参考。如果你准备用Spring Boot做课设或毕设，不管最后是自己照着写，还是拿现成源码二次开发，把这几个关键点吃透，项目质量会明显不一样。

1. 这个题目真正在考什么：汽车销售的业务本质

先别急着打开IDE写代码，拿到这个题目的第一步是理解业务。汽车销售管理系统表面上是“车辆、客户、订单”的增删改查，但它和图书管理系统、学生信息管理系统有一个本质区别——库存模型不是连续数量，而是离散唯一实体。

1.1 真实车行的销售链路长什么样

在真正的4S店或二级经销商那里，一位客户买车不是点一下“购买”按钮就结束。完整的链路是这样的：

• 客户进店或来电，留下姓名、电话、意向车型，这是潜客登记
• 销售员接待，带客户看实车、试驾，记录跟进情况，这是客户跟踪
• 双方谈妥价格，客户交定金，销售员开单，锁定某一辆具体车辆，这是下订
• 客户付尾款、办保险、提车，销售员安排交车，记录交车时间，这是交车
• 如果客户反悔，需要退订，释放车辆库存，这是退单

所以这个系统管理的核心对象不只是“某型号的车有多少辆”，而是“某一辆具体的车在什么状态”。每一辆实体车都有唯一的VIN码（车辆识别代号），可能还有车架号尾号、发动机号、颜色、配置、入库时间、库里位置这些独有属性。你卖出去的，不是“一辆某型号的车”，而是“VIN码为XXX的那一辆车”，这个观念直接决定了后面的表结构设计。

1.2 从业务反推功能模块

把上面这条链路落到系统里，功能模块就自然出来了：

• 车辆管理：车型档案维护、车辆入库、在库车辆查询、车辆状态修改
• 客户管理：潜客登记、跟进记录、客户级别（A/B/C）、成交客户归档
• 销售订单：创建订单、交车、退单、订单查询
• 员工与权限：管理员、销售员、库管三类角色，各自看到不同的菜单
• 统计分析：销量趋势、库存预警、销售员业绩排行

你会发现，这个题目表面考的是Spring Boot CRUD，实际考的是业务建模能力：能不能把真实流程抽象成数据模型，能不能把订单、客户、车辆、销售员之间的关系设计清楚，能不能在答辩时把“为什么这样设计”讲明白。我把这一点放在最前面，是因为后面所有技术选型和表结构都是围绕它展开的。

2. 技术选型：为什么我把组合定在 Spring Boot + MyBatis-Plus

技术选型不能只看“流行”，要看它在你这个场景下的收益和成本。我做这个项目时，确定的核心技术栈是：Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + Thymeleaf + Layui。很多人会质疑：现在不都流行前后端分离吗？为什么不直接用Vue？

2.1 版本选择：2.7.x 对课程设计最友好

Spring Boot 3.x 虽然已经出了很久，但它要求JDK 17，而很多学校机房、教材、老教程还在用JDK 8。我见过不少同学辛辛苦苦装好环境，一启动直接报UnsupportedClassVersionError，排查半天发现是JDK版本不匹配。Spring Boot 2.7.x 是最后一个默认支持JDK 8的版本，依赖生态也最成熟，网上碰到问题一搜一大把解决方案。做课程设计，稳是第一位的，没必要追新版本。

2.2 持久层选 MyBatis-Plus 的真实理由

持久层我选了MyBatis-Plus而不是原生MyBatis，也不是Spring Data JPA。理由很直白：

• 通用Mapper级别的单表CRUD，MyBatis-Plus直接提供ServiceImpl和BaseMapper，不用写XML，能省下大量时间
• 分页插件PaginationInnerInterceptor一行配置就能用，做列表查询很方便
• LambdaQueryWrapper 链式查询写条件非常直观，后期维护容易

但我也刻意保留了手写SQL的位置——多表关联查询和统计报表必须自己写SQL。比如查订单列表要关联客户姓名、车辆型号、销售员姓名，查月度销售报表要GROUP BY DATE_FORMAT(create_time, '%Y-%m')，这些场景让MyBatis-Plus去拼Wrapper反而绕，不如直接写XML里的自定义SQL，逻辑清晰、性能也可控。

2.3 前端方案的取舍：模板渲染还是前后端分离

这是很多人在选题阶段纠结最多的问题。我的建议很明确：如果不是为了练Vue技术，这个题目老老实实用服务端模板方案。

Spring Boot + Vue 前后端分离听起来更“高级”，但做课程设计意味着你要同时处理跨域、Token鉴权、Nginx或本地代理配置，还有Node环境依赖。答辩现场最容易翻车的恰恰是这些“技术债”——你在自己电脑上能跑，换到教室电脑上，前端起不来、接口跨域报错，演示直接中断。

我用的方案是Thymeleaf模板引擎配合Layui前端组件库。Layui自带表格、分页、弹窗、表单验证，页面写起来快，而且它是基于jQuery的，上手几乎没有门槛。后端Controller直接返回视图名，数据用ModelAndView或者@ResponseBody返回JSON给前端异步渲染。这套方案演示时的稳定性极高，我至今没见它在答辩现场出过问题。

3. 数据模型设计：五张核心表和一个状态机

整个系统我设计了十张左右的表，但支撑核心业务的只有五张。下面把这几张表的字段结构和设计意图拆开讲，这是论文数据库设计章节的核心，也是整个项目的骨架。

3.1 核心表结构与字段说明

用户表sys_user

车型表vehicle_model

存储品牌、车系、型号配置这类“一类车”的信息。字段包括brand、series、model_name、configuration、guide_price（指导价）、stock_threshold（库存预警阈值）。把车型和具体的车辆拆成两张表，是为了避免“同一型号的十辆车”重复存配置信息，也方便统计某个车型的库存。

车辆表vehicle_info

这是全项目最核心的表，代表“某一辆具体的车”。关键字段：

VIN码加唯一索引，是数据库层面防止“一辆车重复卖”的第一道防线。

客户表customer_info

字段包括name、phone、id_card、address、intention_model（意向车型）、customer_level（客户级别）、source（来源：到店/电话/转介绍）、follow_status、create_time。系统里销售员能维护潜客跟进记录，后续可以扩展一张独立的跟进记录表。

订单表sales_order

3.2 状态机设计与数据库层面的防重复卖车

车辆和订单各自有一组状态，两者强关联：

• 车辆状态status：0在库 → 1锁定 → 2已售出；退单时从1锁态回到0在库
• 订单状态order_status：0待交车 → 1已交车；0待交车 → 2已退单

订单表的vehicle_id加上唯一约束，意味着一辆车最多只能出现在一条未删除的订单里。再加上车辆表status字段配合条件更新，能挡住绝大多数并发场景下的“一车两卖”。

这里要特别说明为什么不在订单表里冗余客户姓名、车辆型号。我见过很多同学的课设为了图查询方便，订单表里塞一堆冗余文本字段，结果改客户姓名时到处不一致。我的做法是订单表只存ID，查询时用SQLJOIN关联客户表、车辆表、车型表、员工表，一次性把要展示的数据查出来。关系型数据库本来就应该这样用，答辩时这也是一个可讲的点。

4. 核心业务实现：事务、条件更新与订单流转

功能模块再多，核心业务其实就是三个动作：下单、交车、退单。这三个动作写好了，系统的技术含金量就有了。

4.1 下单：一条 UPDATE 解决并发抢车

下单最怕什么？两个销售员同时看中同一辆车，都点“创建订单”，如果代码是这样写的：

// 错误示范：先查状态，再插入订单 VehicleInfo vehicle = vehicleMapper.selectById(vehicleId); if (vehicle.getStatus() == 0) { // 状态正常，创建订单 }

两个人同时查到status=0，然后都往下执行，就会出现一辆车被下两个订单。正确做法是把“状态校验 + 状态修改”合并成一条原子SQL，利用MySQL的行锁保证同一时刻只有一个事务能执行成功：

@Transactional(rollbackFor = Exception.class) public ResultVO createOrder(OrderCreateDTO dto) { // 1. 条件更新：只有状态为0（在库）的车才能被锁定为1 int updated = vehicleMapper.lockVehicle(dto.getVehicleId()); if (updated == 0) { return ResultVO.error("车辆不存在或刚被其他客户预定"); } // 2. 创建订单，状态为待交车 SalesOrder order = buildOrder(dto); salesOrderMapper.insert(order); // 3. 记录操作日志，返回成功 return ResultVO.success("下单成功", order); }

对应的Mapper SQL是：

UPDATE vehicle_info SET status = 1 WHERE id = #{vehicleId} AND status = 0

这套做法的本质是乐观锁思想，不显式加SELECT ... FOR UPDATE，而是用WHERE status = 0作为条件版本判断。update返回影响行数updated，如果为0说明车已经被锁定或售出，直接给用户返回友好提示。整个方法加上@Transactional，后续创建订单失败时车辆状态也会回滚，不会出现“车锁了但订单没生成”的脏数据。

4.2 交车与退单：状态流转的边界处理

交车动作相对简单，但边界要处理好：

@Transactional(rollbackFor = Exception.class) public ResultVO deliverOrder(Long orderId) { SalesOrder order = salesOrderMapper.selectById(orderId); // 状态校验必须是待交车，已交车和已退单都不能再交 if (order == null || order.getOrderStatus() != 0) { return ResultVO.error("订单不存在或当前状态不允许交车"); } // 更新订单状态为已交车，记录交车时间 salesOrderMapper.markDelivered(orderId); // 更新车辆状态为已售出 vehicleMapper.markSold(order.getVehicleId()); return ResultVO.success("交车成功"); }

退单则要判断订单是什么状态。待交车订单可以直接退订，把车辆状态释放回在库；已交车订单原则上不能直接退单，实际业务里要走审批流程。在课设阶段，我处理成：已交车订单调用退单接口直接提示“该订单已完成，请联系管理员处理”，这样既体现了对业务边界的认知，又不用把审批流程做得很复杂。退单代码核心就两步：

// 更新订单状态为已退单 salesOrderMapper.markCanceled(orderId); // 释放车辆：只要车辆状态是“锁定”，就回到“在库” vehicleMapper.releaseVehicle(vehicleId);

注意releaseVehicle也要有WHERE status = 1条件，防止把已售出的车错误地释放回在库。

4.3 权限拦截与全局异常处理

权限这块我没有上Spring Security，原因前面说过——课设场景引入它会大幅增加配置复杂度。我用的是拦截器 + Session判断：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user = request.getSession().getAttribute("loginUser"); if (user == null) { // 未登录，AJAX请求返回JSON，页面请求重定向到登录页 response.setContentType("application/json;charset=UTF-8"); response.getWriter().write(new JSONObject().fluentPut("code", 401).toString()); return false; } return true; } }

再加上@RestControllerAdvice全局异常处理器，把BusinessException、参数校验异常、兜底异常统一包装成ResultVO结构的JSON返回。这套组合代码量少，而且能覆盖“未登录跳转”“非法操作提示”等答辩必演示场景。

5. 报表统计：让系统跳出“增删改查”的三个功能

答辩老师对课设项目最腻味的就是“又是一个CRUD”。所以这个项目里我专门留了三个统计功能，全部是手写SQL，成本和收益都很划算。

5.1 销售趋势统计

按月份统计销售额和订单量，用一条SQL就出来了：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, COUNT(*) AS orderCount, SUM(order_price) AS totalAmount FROM sales_order WHERE order_status = 1 GROUP BY month ORDER BY month DESC

前端拿到结果后用ECharts画一个柱状图或折线图，PPT上展示出来非常直观。做这个功能时建议加一个时间区间筛选，让图表能“动”起来，演示效果更好。

5.2 库存预警

每个车型设置一个stock_threshold阈值，比如某款车低于3辆就预警。查询逻辑：

SELECT vm.brand, vm.series, vm.model_name, COUNT(vi.id) AS stockCount, vm.stock_threshold FROM vehicle_model vm LEFT JOIN vehicle_info vi ON vi.model_id = vm.id AND vi.status = 0 GROUP BY vm.id HAVING stockCount < vm.stock_threshold

注意这里要在JOIN时加上vi.status = 0，只统计真正在库的车，已售出的不算。HAVING里面做库存数量与阈值的比较，结果集就是需要提醒补货的车型列表。

5.3 销售员业绩排行

按销售员汇总已交车订单金额，按降序排：

SELECT u.real_name, COUNT(o.id) AS soldCount, SUM(o.order_price) AS totalAmount FROM sales_order o JOIN sys_user u ON u.id = o.salesman_id WHERE o.order_status = 1 GROUP BY o.salesman_id ORDER BY totalAmount DESC

业绩排行可以用表格展示，也可以做成条形图。这个功能的意义在于体现了“运营视角”——老板最关心的就是谁卖得多、哪个月卖得好、哪些车压库存。答辩时能主动讲报表的设计思路，比被动回答问题加分太多。

6. 从源码到跑通：我实际踩过的五个坑

这部分全是实际操作经验。代码写好了，结果项目在别的电脑上跑不起来、页面样式乱了、数据显示一串数字，这些坑我基本都踩过，逐个说。

6.1 MySQL 8 驱动与连接串

现在大多数人本地装的是MySQL 8，如果还在配置里写com.mysql.jdbc.Driver，启动直接报ClassNotFound。正确写法：

spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/car_sales?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: root password: 123456

serverTimezone=Asia/Shanghai不写会报时区错误；allowPublicKeyRetrieval=true不写，MySQL 8 某些版本用非root或加密插件登录时会报公钥检索错误。这几个参数建议直接复制过去。

6.2 MyBatis-Plus 分页不生效

如果直接new Page<>(pageNum, pageSize)然后selectPage，返回的数据永远是全量——这是因为没有注册分页插件。必须加一个配置类：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

忘了这个配置，页面上的“下一页”全都没用，属于典型的问题。

6.3 LocalDateTime 序列化变成一串数字

实体类里如果用LocalDateTime且没做任何配置，JSON返回给前端时可能会显示一串数字，或者格式不对。两个办法：字段上加注解，或者全局配置：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss") private LocalDateTime createTime;

我更推荐全局配置，不用每个字段都加：

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

不过要注意，LocalDateTime类型不受spring.jackson.date-format完全控制，稳妥起见在字段上加上@JsonFormat双保险。

6.4 端口占用与静态资源路径

8080端口经常被其他程序占着，启动报Port already in use。这时改一下配置即可：

server: port: 8081

还有一个容易忽视的问题：Spring Boot默认静态资源放在resources/static下，如果你把页面作为静态页访问，路径就要和Controller的@RequestMapping错开，否则会被Controller拦截，显示404或跳去登录。页面统一放在templates下用Thymeleaf渲染会省心很多。

6.5 数据库初始化与测试数据

源码包里我特意附带了一个sql/init.sql，包含建库、建表、初始账号和一批模拟数据。为什么强调这个？因为很多同学打开项目发现登录进去是空的，车没有、客户没有，演示效果非常差。预置数据至少包含：3个角色账号、10辆左右的车、5个客户、若干订单，时间跨度覆盖最近三个月，这样统计图表一打开就有内容。答辩前一天，务必在另一台电脑上用全新环境跑一遍整个流程，这是最有效的防翻车手段。

7. 文档、PPT、源码的配合：答辩前一天的整理心得

最后说说“含文档+PPT+源码”这件事本身。现在很多课程设计资源包都会附带文档和PPT，但内容质量参差不齐。我的经验是，这三者一定要围绕同一套设计逻辑来组织，而不是各写各的。

7.1 设计文档怎么写到点子上

文档里需求分析章节最常见的毛病，是把功能列表抄一遍：“系统支持登录、系统支持增删改查……”这等于没写。正确的写法是写用例描述和业务流程：比如“销售员下单”这个用例，要写清楚前置条件（客户已登记、车辆在库）、主流程（选择车辆→锁定→生成订单→收定金）、异常流程（车辆已被锁定→提示重选）。数据库设计章节，则直接把表结构、字段含义、状态机关系放进去，这部分是论文评阅老师重点看的。

7.2 PPT 的讲解顺序与演示路径

PPT我建议按这个顺序讲：选题背景 → 需求分析 → 技术选型 → 系统功能演示 → 核心代码讲解 → 总结与展望。系统功能演示的时间要留足，至少演示这几条完整链路：

1. 登录并切换角色，展示权限差异
2. 新增客户 → 新增车辆入库 → 下单 → 交车
3. 故意演示一次“车辆已被锁定”的提示，配合讲解并发控制
4. 打开销售趋势图和业绩排行，讲统计SQL

核心代码讲解选两段就够：一段是下单事务里的条件更新，一段是月度统计SQL。这两个最能撑起技术含量。

7.3 源码包交付时的建议

交付的源码包结构要清爽：backend（Spring Boot工程）、sql（初始化脚本）、docs（文档、PPT）、README.md。README里必须写清楚环境要求（JDK版本、MySQL版本）、启动步骤、默认账号密码。不要小看这个文件，答辩前如果要在其他电脑上部署，它就是你最快的资料。

按这个思路整理完，哪怕老师临时让你换个数据库跑一遍，你也能有条不紊地操作。前提是——所有代码你真的动手敲过一遍，而不是只做了“下载-改名-提交”。

我在实际整理这套材料时还有个体会：与其花大把时间改一个看不见细节的模板系统，不如老老实实把这个管理系统用自己熟悉的技术从头搭一遍。搭的过程中踩的每一个坑，最后都能变成答辩场上挡住老师追问的底气。这套项目做完，Spring Boot的核心用法、数据库设计、事务和并发控制的理解，基本就都过关了。