前阵子帮一个准备毕设答辩的学弟把“基于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。很多人会质疑现在不都流行前后端分离吗为什么不直接用Vue2.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级别的单表CRUDMyBatis-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字段类型说明idbigint主键usernamevarchar(50)登录名唯一passwordvarchar(255)密码MD5加盐存储real_namevarchar(50)真实姓名roletinyint角色0管理员1销售员2库管phonevarchar(20)联系电话statustinyint账号状态0启用1禁用车型表vehicle_model存储品牌、车系、型号配置这类“一类车”的信息。字段包括brand、series、model_name、configuration、guide_price指导价、stock_threshold库存预警阈值。把车型和具体的车辆拆成两张表是为了避免“同一型号的十辆车”重复存配置信息也方便统计某个车型的库存。车辆表vehicle_info这是全项目最核心的表代表“某一辆具体的车”。关键字段字段类型说明idbigint主键vinvarchar(50)VIN码唯一索引model_idbigint关联车型表colorvarchar(20)颜色factory_pricedecimal(10,2)成本价/采购价guide_pricedecimal(10,2)销售指导价statustinyint0在库1锁定2已售出warehouse_locationvarchar(100)库位VIN码加唯一索引是数据库层面防止“一辆车重复卖”的第一道防线。客户表customer_info字段包括name、phone、id_card、address、intention_model意向车型、customer_level客户级别、source来源到店/电话/转介绍、follow_status、create_time。系统里销售员能维护潜客跟进记录后续可以扩展一张独立的跟进记录表。订单表sales_order字段类型说明idbigint主键order_novarchar(32)订单编号唯一customer_idbigint客户IDvehicle_idbigint车辆ID唯一约束salesman_idbigint销售员IDorder_pricedecimal(10,2)成交价depositdecimal(10,2)定金pay_methodvarchar(20)支付方式order_statustinyint0待交车1已交车2已退单create_timedatetime下单时间deliver_timedatetime交车时间3.2 状态机设计与数据库层面的防重复卖车车辆和订单各自有一组状态两者强关联车辆状态status0在库 → 1锁定 → 2已售出退单时从1锁态回到0在库订单状态order_status0待交车 → 1已交车0待交车 → 2已退单订单表的vehicle_id加上唯一约束意味着一辆车最多只能出现在一条未删除的订单里。再加上车辆表status字段配合条件更新能挡住绝大多数并发场景下的“一车两卖”。这里要特别说明为什么不在订单表里冗余客户姓名、车辆型号。我见过很多同学的课设为了图查询方便订单表里塞一堆冗余文本字段结果改客户姓名时到处不一致。我的做法是订单表只存ID查询时用SQLJOIN关联客户表、车辆表、车型表、员工表一次性把要展示的数据查出来。关系型数据库本来就应该这样用答辩时这也是一个可讲的点。4. 核心业务实现事务、条件更新与订单流转功能模块再多核心业务其实就是三个动作下单、交车、退单。这三个动作写好了系统的技术含金量就有了。4.1 下单一条 UPDATE 解决并发抢车下单最怕什么两个销售员同时看中同一辆车都点“创建订单”如果代码是这样写的// 错误示范先查状态再插入订单 VehicleInfo vehicle vehicleMapper.selectById(vehicleId); if (vehicle.getStatus() 0) { // 状态正常创建订单 }两个人同时查到status0然后都往下执行就会出现一辆车被下两个订单。正确做法是把“状态校验 状态修改”合并成一条原子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;charsetUTF-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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456serverTimezoneAsia/Shanghai不写会报时区错误allowPublicKeyRetrievaltrue不写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: GMT8不过要注意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我建议按这个顺序讲选题背景 → 需求分析 → 技术选型 → 系统功能演示 → 核心代码讲解 → 总结与展望。系统功能演示的时间要留足至少演示这几条完整链路登录并切换角色展示权限差异新增客户 → 新增车辆入库 → 下单 → 交车故意演示一次“车辆已被锁定”的提示配合讲解并发控制打开销售趋势图和业绩排行讲统计SQL核心代码讲解选两段就够一段是下单事务里的条件更新一段是月度统计SQL。这两个最能撑起技术含量。7.3 源码包交付时的建议交付的源码包结构要清爽backendSpring Boot工程、sql初始化脚本、docs文档、PPT、README.md。README里必须写清楚环境要求JDK版本、MySQL版本、启动步骤、默认账号密码。不要小看这个文件答辩前如果要在其他电脑上部署它就是你最快的资料。按这个思路整理完哪怕老师临时让你换个数据库跑一遍你也能有条不紊地操作。前提是——所有代码你真的动手敲过一遍而不是只做了“下载-改名-提交”。我在实际整理这套材料时还有个体会与其花大把时间改一个看不见细节的模板系统不如老老实实把这个管理系统用自己熟悉的技术从头搭一遍。搭的过程中踩的每一个坑最后都能变成答辩场上挡住老师追问的底气。这套项目做完Spring Boot的核心用法、数据库设计、事务和并发控制的理解基本就都过关了。
Spring Boot汽车销售管理系统：表结构、事务与报表设计详解
前阵子帮一个准备毕设答辩的学弟把“基于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。很多人会质疑现在不都流行前后端分离吗为什么不直接用Vue2.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级别的单表CRUDMyBatis-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字段类型说明idbigint主键usernamevarchar(50)登录名唯一passwordvarchar(255)密码MD5加盐存储real_namevarchar(50)真实姓名roletinyint角色0管理员1销售员2库管phonevarchar(20)联系电话statustinyint账号状态0启用1禁用车型表vehicle_model存储品牌、车系、型号配置这类“一类车”的信息。字段包括brand、series、model_name、configuration、guide_price指导价、stock_threshold库存预警阈值。把车型和具体的车辆拆成两张表是为了避免“同一型号的十辆车”重复存配置信息也方便统计某个车型的库存。车辆表vehicle_info这是全项目最核心的表代表“某一辆具体的车”。关键字段字段类型说明idbigint主键vinvarchar(50)VIN码唯一索引model_idbigint关联车型表colorvarchar(20)颜色factory_pricedecimal(10,2)成本价/采购价guide_pricedecimal(10,2)销售指导价statustinyint0在库1锁定2已售出warehouse_locationvarchar(100)库位VIN码加唯一索引是数据库层面防止“一辆车重复卖”的第一道防线。客户表customer_info字段包括name、phone、id_card、address、intention_model意向车型、customer_level客户级别、source来源到店/电话/转介绍、follow_status、create_time。系统里销售员能维护潜客跟进记录后续可以扩展一张独立的跟进记录表。订单表sales_order字段类型说明idbigint主键order_novarchar(32)订单编号唯一customer_idbigint客户IDvehicle_idbigint车辆ID唯一约束salesman_idbigint销售员IDorder_pricedecimal(10,2)成交价depositdecimal(10,2)定金pay_methodvarchar(20)支付方式order_statustinyint0待交车1已交车2已退单create_timedatetime下单时间deliver_timedatetime交车时间3.2 状态机设计与数据库层面的防重复卖车车辆和订单各自有一组状态两者强关联车辆状态status0在库 → 1锁定 → 2已售出退单时从1锁态回到0在库订单状态order_status0待交车 → 1已交车0待交车 → 2已退单订单表的vehicle_id加上唯一约束意味着一辆车最多只能出现在一条未删除的订单里。再加上车辆表status字段配合条件更新能挡住绝大多数并发场景下的“一车两卖”。这里要特别说明为什么不在订单表里冗余客户姓名、车辆型号。我见过很多同学的课设为了图查询方便订单表里塞一堆冗余文本字段结果改客户姓名时到处不一致。我的做法是订单表只存ID查询时用SQLJOIN关联客户表、车辆表、车型表、员工表一次性把要展示的数据查出来。关系型数据库本来就应该这样用答辩时这也是一个可讲的点。4. 核心业务实现事务、条件更新与订单流转功能模块再多核心业务其实就是三个动作下单、交车、退单。这三个动作写好了系统的技术含金量就有了。4.1 下单一条 UPDATE 解决并发抢车下单最怕什么两个销售员同时看中同一辆车都点“创建订单”如果代码是这样写的// 错误示范先查状态再插入订单 VehicleInfo vehicle vehicleMapper.selectById(vehicleId); if (vehicle.getStatus() 0) { // 状态正常创建订单 }两个人同时查到status0然后都往下执行就会出现一辆车被下两个订单。正确做法是把“状态校验 状态修改”合并成一条原子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;charsetUTF-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?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: 123456serverTimezoneAsia/Shanghai不写会报时区错误allowPublicKeyRetrievaltrue不写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: GMT8不过要注意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我建议按这个顺序讲选题背景 → 需求分析 → 技术选型 → 系统功能演示 → 核心代码讲解 → 总结与展望。系统功能演示的时间要留足至少演示这几条完整链路登录并切换角色展示权限差异新增客户 → 新增车辆入库 → 下单 → 交车故意演示一次“车辆已被锁定”的提示配合讲解并发控制打开销售趋势图和业绩排行讲统计SQL核心代码讲解选两段就够一段是下单事务里的条件更新一段是月度统计SQL。这两个最能撑起技术含量。7.3 源码包交付时的建议交付的源码包结构要清爽backendSpring Boot工程、sql初始化脚本、docs文档、PPT、README.md。README里必须写清楚环境要求JDK版本、MySQL版本、启动步骤、默认账号密码。不要小看这个文件答辩前如果要在其他电脑上部署它就是你最快的资料。按这个思路整理完哪怕老师临时让你换个数据库跑一遍你也能有条不紊地操作。前提是——所有代码你真的动手敲过一遍而不是只做了“下载-改名-提交”。我在实际整理这套材料时还有个体会与其花大把时间改一个看不见细节的模板系统不如老老实实把这个管理系统用自己熟悉的技术从头搭一遍。搭的过程中踩的每一个坑最后都能变成答辩场上挡住老师追问的底气。这套项目做完Spring Boot的核心用法、数据库设计、事务和并发控制的理解基本就都过关了。