企业官网建设流程全解析

1. 立项与需求整理

1.1 这类选题的核心诉求

我看到这个题目的时候，第一反应是：终于不是满大街的图书管理系统和学生选课系统了。汽车销售管理系统，尤其加了“租售一体化”这个定语之后，业务复杂度一下子起来了，但它又没复杂到让学生做不出来的程度。正好卡在毕业设计最舒服的区间：业务场景真实、需求边界清晰、技术点覆盖全、答辩有东西讲。

先说清楚这个项目到底是干什么的。传统的4S店管理系统通常只管新车销售和售后维修，而“租售一体化”是在这个基础上，把车辆的短租、长租、以租代购、试驾预约、二手车置换这些业务全部塞进同一套系统里面。用户在前台能看到可售车辆和可租车辆，能在线预约试驾、下单租车、发起购车咨询；管理员在后台管车辆档案、订单审核、租赁计费、客户跟进、经营报表。

实际动手做毕设的时候，很多同学容易掉进一个坑：一上来就打开编辑器写代码，写到一半发现业务关系理不清，租的车和卖的车到底是一批车还是两批车？租赁中的车辆能否被销售？订单状态怎么流转？计费从哪天开始算？这些问题不提前想明白，后面就是反复改表结构、改逻辑，越改越乱。

我个人的建议是：拿到题目之后，先别急着谈技术，先把业务场景在纸上捋一遍。你就把自己想象成一家小4S店的老板，你每天要处理哪些事情——进车、展示、卖车、租车、收钱、算账、催客户保养。把这一条线串起来，系统的模块自然就出来了。

1.2 功能需求梳理顺序

需求层面，我建议按三个层次来梳理，层层递进，答辩的时候也能讲出逻辑感。

第一个层次是基础信息管理。车辆是核心对象，车辆的品牌、型号、颜色、排量、车架号、发动机号、排放标准、厂商指导价、实际成交价、当前状态（在库、已预定、已售出、出租中、维修中）这些是必有的。客户信息也要管，普通个人客户和企业客户分开，企业客户可能涉及开票信息。员工信息主要是销售顾问和仓库管理员，每个订单要关联销售顾问，方便后面做业绩统计。

第二个层次是核心交易流程。销售流程包括客户咨询、报价、订单创建、收款、财务确认、车辆出库、交付确认。租赁流程稍微复杂一点，涉及租期起止、押金收取、租金计算（日租/月租/整租）、续租、提前还车、违约金计算、车辆归还检查。如果做“以租代购”，还要考虑租期满后车辆所有权转移的逻辑，这个在毕设里可以简化成一种特殊状态的租赁订单，但要在文档里明确提出，作为系统的亮点。

第三个层次是统计分析与辅助决策。这个层面很多毕设项目会忽略，但它恰恰是拿高分的点。销售排行榜、租赁收入趋势、库存周转天数、热销车型TOP5、客户意向跟进记录，这些在答辩演示的时候非常出彩。技术上实现也不难，无非就是几个聚合查询和图表展示，但能直观证明你的系统不是玩具，是真能辅助经营决策的。

需求梳理完，你会发现这个项目的核心难点不在于某个单点功能有多难，而在于车辆状态和订单状态的联动。车从入库到售出/租出，再到回库，整个生命周期要在系统里形成闭环。后面所有业务逻辑、数据库设计、接口设计都要围绕这条状态链来展开。

2. 技术选型与架构设计

2.1 为什么是SpringBoot + MySQL

这里先说结论：SpringBoot + MySQL 是当前毕业设计里最稳的组合，没有之一。不是因为它们是最先进的技术，而是因为它们恰好覆盖了毕设评审最看重的几个维度——工程化规范、生态成熟、学习资料丰富、环境搭建简单。

SpringBoot 相对于传统 Spring MVC 的最大优势是自动配置和起步依赖。你不需要手动配置一堆 XML 文件，引入一个 spring-boot-starter-web 依赖，内嵌的 Tomcat 就起来了，直接写 Controller 就能跑通 HTTP 接口。对于要做前后端分离或者有一个后台管理界面的毕设来说，这点太重要了，你大部分的精力应该花在业务逻辑上，而不是纠结配置文件写错了哪个标签。

MySQL 这边，选 5.7 或者 8.0 都行，建议直接上 8.0，因为默认字符集是 utf8mb4，对中文支持更友好，而且窗口函数、CTE 这些语法在写统计报表的时候非常好用。数据库连接池用 HikariCP，SpringBoot 2.x 默认就是它，性能好，配置少。

ORM 层我建议用 MyBatis-Plus，而不是原生 MyBatis 或者 Spring Data JPA。原因有三点：第一，MyBatis-Plus 的 BaseMapper 帮你把单表 CRUD 全封装好了，写代码效率高很多；第二，它的 LambdaQueryWrapper 写条件查询特别直观，不用记一堆 XML 标签；第三，分页插件 PageHelper 或者 MyBatis-Plus 自带的分页拦截器都很成熟，列表页的分页查询直接一套带走。

前端这块，毕设一般有两种选择：一种是传统的服务端渲染，用 Thymeleaf 模板引擎，配合 Bootstrap 或 AdminLTE 后台模板，好处是开发量小，不需要懂前后端分离，适合前端基础薄弱的同学；另一种是前后端分离，Vue + Element UI（或 Element Plus）作为后台管理端，微信小程序或 H5 作为用户端，好处是界面好看、交互流畅，但工作量会明显增加。

如果你时间比较紧，比如开题之后只有两三个月，我强烈建议用 Thymeleaf + AdminLTE 的方案。先把业务跑通，界面不丑就行，答辩老师看的永远是业务逻辑和技术深度，不是你的 CSS 写得有多花。如果你时间充裕，或者你本来就会 Vue，那前后端分离肯定更出彩。

2.2 项目分层与包结构设计

包结构这件事，很多同学不重视，觉得反正是自己写，想放哪放哪。真到了写文档和答辩的时候才发现，包结构混乱会让整个项目看起来水平很低。我建议按照标准的 MVC 分层来组织，同时兼顾模块化。

大致包结构如下：

com.xxx.carmanage ├── controller // 控制层，接收请求、参数校验、返回结果 ├── service // 业务层，核心业务逻辑 │ └── impl // 业务实现类 ├── mapper // 数据访问层，MyBatis接口 ├── entity // 实体类，对应数据库表结构 ├── dto // 数据传输对象，接收前端参数、返回自定义结构 ├── vo // 视图对象，给前端展示用的封装 ├── config // 配置类，如跨域、拦截器、自定义异常处理 ├── common // 公共类，如统一返回结果、分页结果、常量 ├── utils // 工具类，如日期处理、金额格式化 └── CarManageApplication.java // 启动类

controller 只做两件事：接收参数、调用 service。千万不要在 controller 里写业务逻辑，比如写个订单还得先查库存再扣减，这些都是 service 层的活。service 层写核心业务，事务控制也都在这一层加 @Transactional。mapper 层就是接口加 SQL，尽量用注解或者 XML 写复杂查询，不要用实体类硬拼条件。

有一个细节需要提醒，就是关于金额的存储。车的价格动辄几十万，租金、押金也有明确的精度要求，数据库里一定用 DECIMAL(10, 2) 或 DECIMAL(12, 2) 来存，Java 实体用 BigDecimal 来接收。千万不要用 Double 或 Float 存金额，浮点数存在精度丢失问题，比如 0.1 + 0.2 可能得到 0.30000000000000004，这在涉及钱的系统里是不可接受的。做金融分期计算、租金计算的时候尤其要小心。

3. 核心业务模块拆解与实现

3.1 车辆档案与库存管理

车辆档案是这个系统的“主数据”，其他所有模块都是围绕车辆转的。车辆表的字段设计要足够完整，但也不要无脑堆。

我的建议核心字段分组如下：

• 基础属性：品牌、车系、车型、年款、车身颜色、内饰颜色、变速箱类型、燃料类型、排量、座位数
• 身份标识：车架号（VIN，必须唯一）、发动机号、车牌号（上牌后才有）
• 商务属性：厂商指导价、销售报价、最低成交价、采购成本价
• 库存属性：入库时间、库位编号、当前状态、里程数（新车通常为0）、是否展车
• 备注信息：车辆描述、选装配置、图片路径

车辆状态字段我建议用整数或者字符串常量来维护，例如：1-在库、2-已预定、3-已售出、4-出租中、5-维修保养、6-已下架。不直接在数据库里用中文，是为了后面写代码判断方便，在页面展示的时候再通过枚举转为中文。

这里有一个业务设计上的关键点，也是租售一体化和纯销售系统的最大区别：一辆车到底能不能既被销售又被租赁？我的答案是：物理上同一辆车可以，业务上必须通过状态机来严格限制。比如一辆车当前状态是“在库”，那么管理员可以发起销售订单，也可以发起租赁订单；一旦销售订单创建成功，车辆状态变为“已预定”，租赁模块就不能再选中这辆车；如果租赁订单签订成功，车辆变为“出租中”，销售模块就不能再卖这辆车。等租赁结束车辆归还，状态回到“在库”，才重新开放销售。

这个状态联动的实现不复杂，关键是所有修改车辆状态的代码必须集中到 service 层的一个方法里，例如updateCarStatus(carId, targetStatus)，任何业务模块要改状态都走这个方法，而不是到处直接改 vehicle 表的 status 字段。这样既保证了逻辑统一，也方便后续加状态流转日志。

3.2 销售订单流程

销售订单是整个系统最核心的流程，建议状态设计如下：

• 1-待审核：销售顾问录入订单，包括客户信息、车型、成交价、付款方式
• 2-已审核：销售经理审核通过（权限管理用角色区分，普通员工没有审核权限）
• 3-待付款：客户还没付完款，可能是一次性付清，也可能是分期首付
• 4-已付款：财务确认收款，系统登记收款流水和支付方式
• 5-待交车：车辆做PDI检测、清洗、上牌手续准备
• 6-已交车：客户完成提车，订单闭环，车辆状态变为“已售出”
• 7-已取消：订单取消，车辆释放回“在库”

这里面有两个容易被忽略的细节。第一个是订单编号的生成。不要用数据库自增ID当订单号展示给用户看，容易暴露业务量，也不好看。建议格式化为XS + 日期 + 随机数，比如 XS20250512001，这样看着正规，也方便通过订单号直接反查日期。第二个是取消订单的约束，只有“待审核”和“待付款”状态的订单允许取消，一旦财务已经确认收款，取消就必须走退款流程，不能直接改状态，这个要在文档里强调，体现你的逻辑严谨性。

付款方式上，毕设做全款和分期两种基本就够了。全款逻辑简单，就是记录收款金额和付款时间。分期稍微复杂，需要记录首付比例、贷款金额、分期期数、每期应还金额、利率。这里建议单独建一张 installment_plan 表来存分期计划，和订单主表做外键关联，不要往主表里塞一堆分期相关字段。

交车环节可以加一个交车确认单，记录客户签字确认、交付时间、交付时里程数、随车附件（钥匙、说明书、保养手册）等，这些细节在答辩时很有说服力，能体现你确实考虑到了实际业务场景。

3.3 租赁订单与计费逻辑

租赁模块是“租售一体化”系统的差异化亮点，也是很多同学觉得比较陌生、不知道从何下手的地方。其实只要把业务规则先定清楚，代码实现并不难。

租赁订单的状态我建议这样设计：

• 1-待审核：客户提交租车申请，选择车辆、租期、取车时间
• 2-已审核：管理员确认有车可租，审核通过
• 3-待取车：客户到店取车，此时需要缴纳押金（通常按车型价值收取）和首期租金
• 4-租赁中：车辆已在客户手中，按日/按月计费
• 5-待还车：客户申请还车，等待管理员验车
• 6-已还车：车辆归还，验车通过，结算尾款（可含超时费、清洁费、违章押金退还），订单闭环
• 7-已取消

计费逻辑是这个模块的核心。日租是最常见的模式，公式是：租金总额 = 日租金 × 租赁天数。这里有个坑是“租赁天数怎么算”，是按自然日算还是按24小时算？比如客户 5月1日 上午10点取车，5月3日 下午4点还车，按自然日算是3天，按实际小时算是 2天6小时。实际业务中，4S店通常按自然日计算，超过还车时间按小时加收超时费。毕设里我建议按自然日计算，但在代码里要写清楚边界条件——取车当天算第一个自然日，还车当天也算一个自然日，也就是说 5月1日取、5月3日还，算3天。

代码实现的时候，租赁天数我用ChronoUnit.DAYS.between(takeDate, returnDate)来算，注意这里返回值至少要加1，因为起始日算一天。如果客户提前还车，剩余天数对应租金不退——这在实际业务里是有争议的，但作为系统原型你可以先这么定，然后在文档里说明，表示你考虑了这种业务歧义并给出了明确规则。

押金管理也要单独设计。押金不是总收入，只是暂扣款，客户归还车辆且无违章、无损坏后退回。建议押金单独记录在 deposit 表，和订单关联，退还时单独走一笔流水。千万不要把押金混在租金收入里统计，那样财务数据就会不准。

续租场景可以加一个简单实现：客户发起续租申请，管理员确认后，修改租赁订单的预计还车日期，并补录一笔租金流水。提前还车则结算时多退少补？我们上面规定了不退，那么只需生成还车订单即可。

3.4 客户管理与意向跟进

客户管理模块在评委眼里往往是一个“默默加分”的模块。销售这种业务，核心资源就是客户线索。你系统里要是有个像样的客户关系管理（CRM）功能，显得整个系统非常完整。

客户表核心字段：姓名、电话、性别、年龄区间、所在城市、客户来源（自然进店、线上线索、老客转介绍、车展留资等）、客户类型（个人/企业）、意向车型、预算区间、意向等级（A/B/C/D）、最后跟进时间、下次跟进时间。

意向跟进记录单独建一张表，每一条记录包括跟进人、跟进时间、跟进方式（电话/微信/到店）、沟通内容摘要、客户是否同意到店、是否成交。销售顾问在系统中可以按“今日需跟进客户”来查询，快到逾期没跟进的客户自动标红提醒。这个功能实现起来不复杂，但能体现你对“销售业务如何运转”的理解，答辩的时候很好讲。

我喜欢在客户模块加一个“成交转化漏斗”统计——新增线索数、到店数、成交数、转化率，按销售顾问维度展示。这就是典型的老板视角。你不用做得很精美，用 ECharts 画个柱状图或者折线图就行，但一定要有这个功能。

4. 数据库设计与核心SQL

4.1 核心表结构概览

数据库设计是文档里占篇幅最大、答辩最容易深挖的部分。这里我给出一个精简过但仍然完整的表结构规划，核心是 8 张业务表 + 3 张支撑表。

支撑表包括字典表（存车辆品牌、状态枚举等可配置项）、上传文件表（存车辆图片、合同附件等）和操作日志表（记录关键业务操作，方便追溯）。

建表的时候有几个细节值得注意。第一个，所有表都要有 create_time 和 update_time，这是基本功，但确实有同学不写，到后面对账或者写审计的时候才发现没有时间字段。第二个，逻辑删除字段，比如deleted用 0 和 1 表示是否删除，不要物理删除数据，否则后面做统计报表的时候会漏数据。第三个，外键约束我在毕设里建议不要强制执行，逻辑外键就够了。物理外键在数据量大、订单流程复杂的时候确实会影响更新性能，而且 MyBatis-Plus 对物理外键的维护也没有原生支持，逻辑外键配合业务层的校验完全可以保证数据一致性。

4.2 租售一体的库存联动设计

租售一体化的核心表设计难点在于：同一张 vehicle 表要同时服务销售和租赁两条业务线，怎么办？

我的方案是：不拆表，用“车辆生命周期”来统一管理。一张 car_info 表，一个 status 字段，通过状态的流转来区分当前车辆是销售状态还是租赁状态。

具体来说：

• 待售/待租状态都是“在库”，即 status = 1
• 被销售订单锁定，设置 status = 2（已预定）
• 完成销售交付，设置 status = 3（已售出）
• 被租赁订单锁定，取车后设置 status = 4（出租中）
• 租赁归还验车后，设置 status = 1（回到在库）

这里有一个经典问题：一辆车在“出租中”的时候，如果有人想买这辆车，系统怎么办？实际业务中，经营性租赁的车辆一般不作为新车销售，但可以用“先租后买”的方式转化——客户一直租这辆车，租期满后选择购买，此时生成销售订单，车辆状态从“出租中”转为“已售出”。

在代码层面，为了保障并发安全（比如两个人同时看中同一辆车、同时下单），我强烈建议在车辆表加一个乐观锁版本号字段 version。更新状态时执行UPDATE car_info SET status = ?, version = version + 1 WHERE id = ? AND version = ?，如果影响行数为 0，说明车辆状态已被别人变更过，本次操作失败，提示“车辆状态已变化，请刷新后重试”。这个技术在项目答辩里提出来，评委老师会觉得你考虑过真实世界的并发问题，而不是只能跑通Demo。

4.3 最常用的几条查询SQL

下面我列几条必须会写、答辩也可能被问到的SQL，直接截图放到论文里也是好的素材。

第一，统计某个月份的销售总额：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(total_amount) AS total_sales FROM sales_order WHERE order_status = 6 AND create_time BETWEEN '2025-05-01 00:00:00' AND '2025-05-31 23:59:59' GROUP BY DATE_FORMAT(create_time, '%Y-%m');

这里把订单状态限制为已成交，避免把取消和被审核的订单算进去。实际业务中统计口径很讲究，不同的口径结果差异很大，你最好在文档里说明白你的统计口径是“已交车订单”。

第二，查询当前可租车辆列表（排除出租中、预定、售出状态）：

SELECT id, brand, series, model, daily_rate FROM car_info WHERE status = 1 AND daily_rate IS NOT NULL ORDER BY daily_rate ASC;

第三，租赁收入按月汇总（注意要把押金排除在外，押金不是收入）：

SELECT DATE_FORMAT(create_time, '%Y-%m') AS month, SUM(amount) AS lease_income FROM finance_record WHERE order_type = 'LEASE' AND pay_type != 'DEPOSIT' GROUP BY DATE_FORMAT(create_time, '%Y-%m');

第四，库存周转天数估算：

SELECT brand, series, AVG(DATEDIFF(sell_date, in_date)) AS avg_turnover_days FROM car_info WHERE sell_date IS NOT NULL GROUP BY brand, series;

这几条SQL看着不难，但能把它们串起来回答“系统如何帮助管理者做决策”，就能让答辩站在很稳的位置。

5. 关键业务逻辑与难点解决

5.1 车辆状态自动流转

车辆状态的自动流转是系统业务逻辑的骨架。如果全部靠人工在页面上改状态，容易出错，也不够智能。我的做法是：状态流转不依赖用户主动操作，而是随订单节点的推进自动触发。

用销售订单举例：

• 创建订单时，程序检查车辆状态是否为 1（在库），校验成功后，将车辆置为 2（已预定），同时给车辆绑定一条锁定记录（哪个订单锁的，什么时候锁的）
• 订单财务确认付款后，车辆状态从 2 变更为 5 对应的“待交车”状态
• 交车确认后，车辆状态变更为 3（已售出）
• 如果订单取消，释放车辆，状态回到 1（在库）

这个设计最大的优点是：数据一致性非常高，车辆状态不会和订单状态“打架”。你只要保证对车辆的操作都封装在 service 层的交易型方法里，配合 @Transactional 注解，就不会出现“订单状态已经变成已交车，车辆还是已预定”这种脏数据。

在实现的时候，我会给车辆状态变更增加一张操作日志表。

@Transactional public void confirmDelivery(Long orderId) { SalesOrder order = salesOrderMapper.selectById(orderId); // 校验订单状态 if (!"5".equals(order.getOrderStatus())) { throw new BizException("订单状态不正确，无法交车"); } // 更新订单状态 order.setOrderStatus("6"); salesOrderMapper.updateById(order); // 更新车辆状态 CarInfo car = carInfoMapper.selectById(order.getCarId()); car.setStatus(3); car.setSellDate(new Date()); carInfoMapper.updateById(car); // 记录车辆日志 CarStatusLog log = new CarStatusLog(); log.setCarId(car.getId()); log.setFromStatus(5); log.setToStatus(3); log.setOperateUser(CurrentUser.id()); carStatusLogMapper.insert(log); }

这段代码看起来普通，但你能在答辩的时候把它讲到三层意思：一是事务保证一致性，二是日志保证可追溯，三是状态机设计保证业务规则不被绕过。这就够了。

5.2 金融分期计算逻辑

销售模块里带一个分期购车计算器，属于能给项目加分的点。它的业务逻辑也不复杂，核心就是等额本息的计算公式。

等额本息的公式是：

每月还款额 = [贷款本金 × 月利率 × (1 + 月利率)^还款月数] ÷ [(1 + 月利率)^还款月数 - 1]

Java代码实现如下：

public BigDecimal calculateMonthlyPayment(BigDecimal loanAmount, BigDecimal annualRate, int months) { BigDecimal monthlyRate = annualRate.divide(BigDecimal.valueOf(12), 6, RoundingMode.HALF_UP); BigDecimal factor = BigDecimal.ONE.add(monthlyRate).pow(months); BigDecimal numerator = loanAmount.multiply(monthlyRate).multiply(factor); BigDecimal denominator = factor.subtract(BigDecimal.ONE); return numerator.divide(denominator, 2, RoundingMode.HALF_UP); }

这里有个细节要注意，BigDecimal 的 divide 必须指定小数位数和舍入模式，否则会抛 ArithmeticException。我自己写过太多遍，交过学费，所以这里敲黑板强调一下。

前端页面上，用户输入车价、首付比例、贷款期数，后端返回每期本金、每期利息、总利息、总还款额，并生成一个简单的还款计划表，显示在订单详情页里。这个功能的实现成本很低，但展示效果很好，尤其论文里可以放一张截图，配一段“降低客户购车决策成本”的说明，整体项目格调就上来了。

5.3 数据统计与图表报表

报表模块是区分“管理系统”和“演示项目”的分水岭。如果你做了三个核心报表，整个项目的完成度会明显提升。

第一个报表是销售业绩看板，核心指标：本月销售额、本月订单数、成交客户数、客户转化率、销售顾问排名。销售顾问排名用一条带窗口函数的SQL就能实现：

SELECT user_id, COUNT(*) AS order_count, SUM(total_amount) AS total_sales, RANK() OVER (ORDER BY SUM(total_amount) DESC) AS rank_no FROM sales_order WHERE order_status = 6 AND create_time >= '2025-05-01' GROUP BY user_id;

MySQL 8.0 支持窗口函数，这比在Java代码里做排序高级得多，论文公式截图也好看。

第二个报表是租赁收入趋势图，按周展示租赁订单数量和收入，用于观察业务波动。第三个报表是库存结构分析，统计当前在库车辆的品牌分布、价格区间分布、库存天数分布，帮助管理者决定哪些车型需要促销清库存，哪些车型可以多进货。

图表用 ECharts 就可以，柱状图、折线图、饼图各来一个，数据通过后端接口返回 JSON 格式，前端用 Ajax 拉取。注意图表不要做成一打开页面就加载所有数据，需要带上时间筛选条件，这样更有“工具”的感觉。

6. 搭建调试与踩坑实录

6.1 开发环境准备

环境这块是不少同学起步就卡住的地方，我再整理一下。

JDK 用 1.8 或 11，Maven 3.6+，IDE 用 IntelliJ IDEA，数据库用 MySQL 5.7/8.0，再装一个 Navicat（或者 DataGrip）做可视化操作，Redis 如果用到可以做缓存（这个项目不强制），最后用 Postman 测接口。

SpringBoot 版本我建议用 2.7.x，稳定且资料多。如果用了 SpringBoot 3.x，JDK 必须 17 以上，很多同学的机器上可能没有配置好，没必要给自己增加环境变量。MyBatis-Plus 用 3.5.x。

初始化项目的时候，可以直接在官网 start.spring.io 生成骨架，选 Web、MySQL Driver、Validation 这几个依赖。如果配了 MyBatis-Plus，就得手动加依赖坐标和配置。

一个常见的坑是：SpringBoot 启动时报Failed to configure a DataSource。这个的原因通常很简单——application.yml 里没有配置数据源，或者配置了但数据库没建好。排查思路是：先确认本地 MySQL 服务是否启动，然后用 Navicat 看能否连上数据库，最后检查 yml 里的 url、username、password 是否和本地环境一致。

url 的写法要注意：

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

serverTimezone=Asia/Shanghai必须带上，否则8.0驱动会报时区错误。useSSL=false是本地开发用的，避免安全证书导致的连接问题。characterEncoding=utf8保证中文不乱码。

6.2 常见报错与排查

我把毕设期间最容易踩的坑整理成了一张速查表，直接保存，遇到问题对着查就行。

单独挑一个最隐蔽的坑说说：MyBatis-Plus 的字段映射问题。如果你数据表的字段是create_time，Java 实体是createTime，一定要在 application.yml 里加 MyBatis-Plus 的驼峰映射配置：

mybatis-plus: configuration: map-underscore-to-camel-case: true

不加这个配置，查询结果里createTime是 null，页面显示全是空。更隐蔽的是，如果表字段是order_no，实体是orderNo，没开驼峰映射的话，update 操作时该字段会被置空——因为order_no字段没有被赋值，SQL 生成时把它当 null 更新了。我见过不止一个同学在这里排查到半夜。

6.3 答辩常见问题预案

答辩的时候，评委老师问得比较多的问题，我提前整理一下，你们可以直接拿去做预案。

第一个问题是：为什么选 SpringBoot 而不是 SSM？回答思路是：SpringBoot 是 Spring 生态对“约定优于配置”理念的深化实现，它通过起步依赖和自动配置大幅降低了项目搭建成本，让开发者聚焦业务逻辑。SSM 当然也很好，但配置繁琐，且学习曲线更陡峭。对于中小型管理系统的快速交付，SpringBoot 优势非常明显。

第二个问题是：车辆状态如果并发修改怎么办？回答思路是用乐观锁，基于 version 字段的 CAS 机制，更新失败则提示用户重试，从而避免两个人同时下单同一辆车的超卖问题。同时说明订单创建时先锁定车辆再写订单，保证数据一致性。

第三个问题是：订单金额为什么用 BigDecimal？回答思路是 float/double 在二进制中无法精确表示部分十进制小数，可能产生精度丢失，而 BigDecimal 基于十进制运算，可精确保存金额。同时说明 DECIMAL(10,2) 在数据库侧的存储方式。

第四个问题是：这个系统的最大难点是什么？最好的回答是车辆状态在“租售一体”场景下的统一建模与状态流转控制，以及订单主数据与车辆状态之间的联动一致性保障。这里你把状态机设计讲清楚，评委基本就会满意了。

7. 项目扩展与经验心得

7.1 可以继续深化的方向

如果核心系统做完之后精力还有余，有几个扩展方向可以加，每一个都能让项目“长”出层次来。

第一个扩展是消息通知模块。比如订单状态变更后，给客户发短信通知；租赁到期前一天，自动提醒客户续租或还车。实现上可以用 Spring 的事件机制，在订单状态变更的地方发布一个事件，监听器负责发消息。这个设计可以讲出解耦的思路，也是加分项。

第二个扩展是引入 Redis 做高频数据的缓存。比如车辆列表的查询结果，首页看板的统计数据，这些相对稳定但访问频繁的数据可以缓存起来，减少数据库压力。再配合一个“刷新缓存”的后台按钮，保证数据不陈旧。这个扩展能展示你对性能优化的思考。

第三个扩展是给系统加一个操作日志审计模块，用 AOP 切面记录每个关键操作的用户、时间、IP、操作内容、修改前后的数据快照。这个在企业系统里是刚需，答辩的时候讲出来很有说服力。

第四个扩展是做一个客户微信端或Pad端。微信端可以查车型、预约试驾、在线看租赁价格和下单，Pad端可以用来在车展现场给销售顾问演示车辆信息和报价单。工作量可控，但展示效果拔群。

7.2 我的一些实操体会

最后聊几句个人感受。

做毕设最大的敌人不是技术难点，而是“需求飘忽不定”。今天想加个积分商城，明天想弄个抖音算法，最后哪个都没做完。我的建议是：先用一周时间把需求定死，写在文档里，后面除非答辩老师明确要求，否则绝对不加新功能。先把主线做通，再做加分项，这是所有做系统类毕设的通用的节奏。

其次，一定要给自己留出至少两周的“答辩准备时间”。这期间不是写代码，而是把论文调顺、准备演示数据、排练讲解流程。演示数据不要太寒酸，多准备一些真实的车辆品牌、客户姓名（虚构的）、订单记录，把整个系统跑在一个“看起来用了一个月”的状态。评委老师点开车辆列表，看到里面有小几十条不同品牌型号的车辆数据、页面上有本月销售额曲线，印象分会高很多。

数据库初始化数据可以用一段 SQL 脚本做，也可以用 MyBatis-Plus 的 DataInitializer 在启动时插入。演示前重置数据库到一个指定的初始快照，这样可以保证每次演示的状态一致，不会出现“上次测试的数据把页面弄乱了”的尴尬。

再补充一点关于论文的事。业务流程图用 Visio 或 ProcessOn 画，一定要画清楚两条主线：一条是销售流程，一条是租赁流程。两张图走完，再加上一张“车辆状态流转图”，核心设计就讲完了。数据库的 ER 图也要画，不用画太细，核心表 8 张就够了，多了反而不清晰。

这个项目的代码量，按我的经验，Controller + Service + Mapper 加前端页面，大概在 6000 到 8000 行之间。听着很多，但实际上大部分是模板代码和前端页面，真正的核心业务逻辑可能不到 2000 行。前面两周框架打好、表建好之后，后面就是按部就班的填充，不会特别赶。只要你不是最后三天才开始，时间是完全够用的。