企业官网建设流程全解析

简介：这是一套面向计算机专业本科生的毕业设计级二手车交易平台完整实现方案，基于SpringBoot+Vue技术栈构建，解决传统二手车信息不对称、交易流程不透明、车辆历史难追溯等核心问题。资源包共1177个文件，涵盖45个Java后端控制器与实体类（如OrderController、PingguController）、45个JS前端交互逻辑、92个HTML页面模板、74个CSS样式文件及大量图片与字体资源，完整呈现前后端分离架构下的系统开发全貌；压缩包大小22.82MB，结构清晰，便于按模块学习调试。已有37人下载学习，适合课程设计、毕设选题与JavaWeb工程实践参考。读者可直接部署运行，获得含用户前台（注册登录、搜索筛选、定金锁定、历史查询、评估提交）、后台管理（资讯/促销/订单/评价/车辆历史全流程管控）及配套论文、开题报告与答辩PPT在内的全套交付物。 去年做毕设那阵，我盯着导师给的选题列表纠结了整整两天。二手车交易系统、图书管理系统、学生选课系统……全是经典得不能再经典的Java Web题目。最后我选了“雪都出行-二手车交易系统”这个方向，不是因为题目多新鲜，而是我仔细盘了一下：二手车交易这个业务场景，比图书管理、学生选课复杂得多，有权限控制、有商品状态流转、有搜索筛选、有图片上传、还有订单和预约的关联关系。做完这一套，Spring Boot的核心用法基本都能过一遍，写论文的时候素材也充足。整个项目从零搭到写完论文、做完PPT，前后花了大概三周。这篇文章就把我完整的开发思路、设计取舍、踩过的坑和论文材料准备经验全部写出来，给准备做类似选题的同学一个可以直接参考的路线。

1. 为什么是“二手车交易系统”：选题背后的需求拆解

很多人选毕设题目只看“好不好做”，我建议反过来想——“这个题目能不能支撑起一篇论文的体量”。二手车交易系统之所以是Java领域的常青树选题，就是因为它的业务复杂度和技术覆盖面刚刚好：太简单了没东西写，太难了做不完。

1.1 从标题看系统的核心定位

“雪都出行”这个名字，说白了就是给系统起的一个品牌代号，很多学校要求项目名不能太通用，所以套一个地域/品牌词是很常见的做法。从题目“二手车交易系统”这个核心词能看出，系统要解决的是三个角色之间的真实业务关系：

• 个人卖家/车商：发布车源信息，管理自己的在售车辆，处理买家预约
• 买家（普通用户）：浏览车源、搜索筛选、查看详情、收藏心仪车辆、发起预约看车
• 平台管理员：审核车源上线，管理注册用户，处理违规信息，维护基础数据（品牌、车系等）

这三类角色对应了系统中最基本的三类权限，也就是后来说的“用户端、商家端、管理端”。第一次做这种多角色系统的人，最容易犯的错误是：一开始就把所有功能堆在一起，做到后面自己都分不清哪个接口是给谁用的。我建议在动手写代码之前，先把角色和权限边界画清楚，别急着一上来就创建Spring Boot工程。

1.2 这个题到底在考什么

从论文和答辩的角度看，这个题目最核心的考察点有三块：

第一，需求分析能力。你要能把“二手车交易”这种生活化的描述，转化成明确的“功能列表”“用例图”“数据字典”，这是论文第一章到第三章的重头戏。怎么转化？先列出用户故事，比如“用户王先生想浏览10万以下、3年以内车龄的SUV”，这就是一个典型的筛选需求；再根据用户故事去反推功能模块，需求自然就出来了。

第二，技术落地能力。Spring Boot项目不是把代码跑起来就完了，要能把JPA或MyBatis的持久层操作、Spring Security的权限控制、文件上传、分页查询这些知识点一一对应到具体功能上。我采用的是Spring Boot + MyBatis-Plus + MySQL的方案，后面会详细说为什么这么选。

第三，系统设计能力。数据库表怎么建、状态字段怎么设计、表与表之间的关联关系怎么处理，这些是答辩时老师最容易追问的地方。我的经验是：哪怕功能做少一点，也要保证核心表的设计是严谨的，因为你论文里的ER图、数据字典都来自这里。

1.3 系统整体业务流程

在正式动手之前，我先把“一辆车从发布到成交”的完整链路走了一遍：

1. 卖家注册登录后，在“发布车源”页面填写车辆信息并上传照片，提交后车辆状态为“待审核”
2. 管理员在后台看到待审核列表，检查信息与图片，审核通过后车辆状态变为“在售”
3. 买家通过首页的搜索筛选找到车辆，查看详情，点击“预约看车”并选择时间
4. 卖家收到预约通知（我的做法是“个人中心-预约记录”里显示未读标记），确认后线下联系
5. 交易成功后，卖家在系统里把车辆状态改为“已售”

这套主流程走通之后，再往里填充辅助功能：收藏、留言咨询、公告管理、用户信息修改等，系统的骨架就非常清晰了。我画这张流程图的时候用了大约一小时，但后面写代码、写论文的效率都因此提升了不少，所以强烈建议先做这一步。

2. 技术选型为什么是Spring Boot，而不是SSH或SSM

很多人在毕设技术选型时喜欢跟风，看到别人用Spring Boot自己也用，问起来却说不清Spring Boot到底解决了什么问题。答辩的时候老师一句“你为什么选这个框架”就能把人问住。所以我把当时做选型比对的过程完整记录下来，也算也是给答辩准备了一份参考答案。

2.1 Spring Boot相比传统SSM的优势

几年前Java Web毕设的主流方案还是Spring + SpringMVC + MyBatis（SSM），或者更古老的SSH（Struts2 + Spring + Hibernate）。SSM本身没有大问题，但当时的痛点在于配置极其繁琐：web.xml要配、spring-mvc.xml要配、mybatis-config.xml要配、数据源要配、事务要配，光是搭环境就能耗掉一两天，而且一旦版本之间有兼容问题，排查起来非常痛苦。

Spring Boot最大的贡献是“约定大于配置”，它把大量默认配置内置化了。我只需要在pom.xml里引入相关依赖，再写一个application.yml，就能快速拿到一个可运行的Web应用。Spring Boot内置Tomcat，一个java -jar就能跑起来，这是我最终选择它的决定性原因——我不想把宝贵的开发时间浪费在环境配置上，而是要把精力集中在业务功能的实现上。

2.2 持久层框架的选择：MyBatis-Plus

Spring Boot本身只管自动配置和快速启动，真正操作数据库还需要一个持久层框架。常见选项是Spring Data JPA和MyBatis，我当时选了MyBatis-Plus。

• JPA适合实体关系比较简单的场景，写起来快，但遇到复杂查询时需要写JPQL或者原生SQL，其实并不省事
• MyBatis的SQL掌控力强，但单表增删改查的XML代码写起来很烦，全是重复劳动
• MyBatis-Plus相当于MyBatis的增强版，把单表CRUD、分页、条件构造器全部内置了

实际体验下来，像“车辆信息表”这种单表操作，我用MyBatis-Plus的BaseMapper接口直接搞定，不需要手写XML；需要用多表关联查询的地方（比如查车辆同时关联出车主昵称），我再写自定义SQL。这套组合简直是为毕设量身定制的——琐碎操作省时省力，复杂查询还能自己掌控SQL。

2.3 前端方案：服务端渲染还是前后端分离

这里要特别提醒一个问题：毕设项目跟企业项目最大的区别是，你要在论文里把每个功能模块的运行逻辑讲清楚，所以不要盲目追求“前后端分离”这个时髦词。

当时我原本想用Spring Boot + Vue做前后端分离，理由是热搜词里“springboot vue前后端分离”热度很高，显得技术含量高。但后来我仔细评估了一下自己的时间，选择了现成的Thymeleaf模板引擎做服务端渲染，页面直接由后端渲染返回，整个应用打成一个jar包部署。这个决定帮我省了至少一周的时间：我不需要处理跨域问题，不需要单独部署Node服务，不需要搞接口鉴权，session会话管理框架天然支持。

你要是已经熟练掌握了Vue，且时间充裕，做前后端分离完全可以；但如果你是临时赶毕设，我真心建议用Thymeleaf。技术上它依然用到Spring Boot的MVC体系，论文里照样能写出东西来，关键是把核心业务做好，而不是把时间耗在脚手架工程上。

2.4 运行环境版本建议

Spring Boot版本选择是一个容易被忽视的坑。我当时看到Spring Boot 3.x发布，忍不住想用新版本，但后来发现很多老教程还是基于2.x写的，遇到问题参考起来非常费劲。

建议直接使用Spring Boot 2.7.x + JDK 8或JDK 11，这是目前网上资料最多、坑最少、最稳妥的组合。Spring Boot 3.x要求JDK 17以上，如果你的电脑装的是JDK 8，直接上3.x会在启动阶段就报错。先把自己的运行环境定下来，完整写下来就是：

• JDK: 1.8（对应Spring Boot 2.x）
• 数据库: MySQL 5.7或8.0，我用的是8.0，用前者也可以
• 构建工具: Maven 3.6+
• 前端模板: Thymeleaf + Bootstrap + jQuery
• ORM: MyBatis-Plus 3.5.x
• IDE: IntelliJ IDEA

这套组合我跑下来非常顺畅，教程案例也最多，遇到任何问题基本都能搜到解决方案。

3. 数据库设计：二手车业务核心表的拆解过程

如果说技术选型决定了项目的上限，数据库设计就决定了项目的下限。答辩时老师一般不怎么逐行看代码，但极大概率会打开你的数据库看表结构。我在做“雪都出行”的时候，花了整整一个晚上专门设计数据库，后来证明这个投入非常值得。

3.1 核心数据表一览

我最终规划了8张主要数据表：

这个表结构里有个小设计点想特别说一下：用户表为什么不分买家和卖家？我在设计时考虑到现实中很多人既可能卖车也可能买车，分开建表反而要处理账号绑定关系。用一个role字段（0-普通用户，1-卖家，2-管理员）来区分，登录后根据角色显示不同菜单，代码和逻辑上都简单很多。

3.2 车辆信息表的设计细节

t_car表是整个系统最核心的表，字段设计直接决定功能能做多细。我把一辆二手车的核心属性拆成了这么几类：

• 基础信息：标题、品牌、车系、车型年款、车身颜色、上牌城市
• 车况信息：上牌时间、表显里程、排放标准、变速箱类型（手动/自动）、排量、车况描述
• 交易信息：售价、是否含过户费、卖家id
• 系统信息：状态（0待审核，1在售，2已下架，3已售）、发布时间、浏览量

当时卡了我一下的是“表显里程”和“上牌时间”这两个字段到底存什么类型。我的最终做法是：表显里程用double存万公里，比如5.2表示5.2万公里；上牌时间用date类型。筛选时就可以直接用SQL的between做范围查询。有些人喜欢用字符串拼接“5.2万公里”，但那样筛选的时候就非常痛苦，只能like匹配。

3.3 状态字段为什么要用整数而不是字符串

刚设计status字段时我也纠结过，是直接存“待审核”“在售”这样的中文，还是存数字？后来写代码时才意识到数字才是正确选择：

1. 数据库存储空间小、查询效率高
2. Java代码里可以用常量类做映射，避免魔法值
3. 前端页面上通过th:if判断显示对应的中文标签，逻辑清晰

我在项目里专门建了一个CarStatus常量类：

public class CarStatus { public static final Integer PENDING = 0; // 待审核 public static final Integer ON_SALE = 1; // 在售 public static final Integer OFF_SALE = 2; // 已下架 public static final Integer SOLD = 3; // 已售 }

这样在代码里写if (car.getStatus() == CarStatus.ON_SALE)，语义非常清楚，论文里也可以把这个类截图放进设计文档中。

3.4 创建表SQL示例

这里贴一段当时写的车辆信息表SQL，供直接参考：

CREATE TABLE `t_car` ( `id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL COMMENT '车辆标题', `brand` varchar(30) NOT NULL COMMENT '品牌', `series` varchar(50) NOT NULL COMMENT '车系', `model_year` varchar(10) DEFAULT NULL COMMENT '年款', `mileage` double DEFAULT NULL COMMENT '表显里程（万公里）', `gearbox` varchar(10) DEFAULT NULL COMMENT '手动/自动', `displacement` varchar(20) DEFAULT NULL COMMENT '排量', `price` decimal(10,2) DEFAULT NULL COMMENT '售价（万元）', `seller_id` int(11) NOT NULL COMMENT '卖家ID', `description` text COMMENT '车况描述', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图', `status` tinyint(4) DEFAULT '0' COMMENT '状态：0待审核 1在售 2下架 3已售', `view_count` int(11) DEFAULT '0' COMMENT '浏览量', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_status` (`status`), KEY `idx_price` (`price`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

索引这块我加了status和price的组合索引，因为列表页最常用的查询就是“按状态过滤+按价格排序”，这也是一个可以在论文中写进去的优化细节。

4. 核心功能实现：从登录鉴权到车辆发布的完整链路

数据库设计好之后，就到了最让人兴奋也最容易熬夜的编码阶段。我没有按模块一个个写，而是沿着业务主流程推进：先搞定登录和权限，再实现车辆的发布、列表、详情、预约。这样做的好处是，每一个功能做完都是能实际跑通的，不像按代码分层写，写到一半程序根本运行不起来。

4.1 登录鉴权：Spring Boot如何管理会话

我用的是最传统也最稳妥的Session方案。用户登录成功后，把用户对象放进session：

@PostMapping("/user/login") public String login(String username, String password, HttpSession session) { User user = userService.login(username, password); if (user != null) { session.setAttribute("loginUser", user); return "redirect:/index"; } return "redirect:/login?error=1"; }

需要拦截未登录访问时，我写了Spring Boot的拦截器（HandlerInterceptor）做登录检查：

@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) { response.sendRedirect("/login"); return false; } return true; } }

然后通过WebMvcConfigurer注册拦截路径。为什么用Session而不是JWT？核心原因是这个项目是服务端渲染的，session天然契合；如果用JWT还要处理token存储、请求头传递、刷新机制，增加了复杂度但收益不高。如果以后做前后端分离的项目，再考虑用JWT或者其他无状态方案也不迟。

角色权限这块，我只是对路径做了简单区分：/admin/**路径下的页面只允许管理员访问，非管理员请求直接跳转403页面。这招虽然简单粗暴但非常实用，论文里可以说“采用基于URL粒度的权限控制策略”。

4.2 车辆发布功能的实现

车辆发布是卖家端最核心的功能，前端是一个大表单，包含车辆基本信息、车况描述和图片上传。后端接口接收后，先把封面图保存到本地磁盘，再插入t_car表，图片列表循环插入t_car_image表。

这里有一个我最初做错后来改正的地方：图片存储路径绝对不能写绝对路径，因为部署环境不同，路径就会失效。正确的做法是：项目配置文件里设置一个上传目录变量，根据当前系统动态拼接路径。

# application.yml upload: path: ./uploads/

然后在Controller里这样用：

@Value("${upload.path}") private String uploadPath; @PostMapping("/user/car/publish") public String publishCar(Car car, @RequestParam("files") MultipartFile[] files) { // 保存封面图 if (files.length > 0) { String fileName = UUID.randomUUID() + "-" + files[0].getOriginalFilename(); files[0].transferTo(new File(uploadPath + fileName)); car.setCoverImage(fileName); } car.setStatus(CarStatus.PENDING); carService.save(car); // 保存更多图片 for (int i = 1; i < files.length; i++) { String fileName = UUID.randomUUID() + "-" + files[i].getOriginalFilename(); files[i].transferTo(new File(uploadPath + fileName)); carImageService.save(new CarImage(car.getId(), fileName)); } return "redirect:/user/car/list"; }

这里用UUID重命名文件是一个关键细节，避免出现用户上传的两张图片同名导致互相覆盖的问题。同时前端表单上做了简单的图片格式和大小的校验，后端也要重复校验一次——永远不要相信前端传来的数据，这是一个前端后端的通用原则。

4.3 车辆筛选与分页查询

二手车列表页有一个典型的多条件筛选功能，包括品牌、价格区间、里程区间、变速箱类型，我用MyBatis-Plus的条件构造器来实现：

public Page<Car> searchCars(int page, int size, String brand, Double minPrice, Double maxPrice, String gearbox) { Page<Car> pageObj = new Page<>(page, size); LambdaQueryWrapper<Car> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Car::getStatus, CarStatus.ON_SALE) .eq(StringUtils.hasText(brand), Car::getBrand, brand) .eq(StringUtils.hasText(gearbox), Car::getGearbox, gearbox) .ge(minPrice != null, Car::getPrice, minPrice) .le(maxPrice != null, Car::getPrice, maxPrice) .orderByDesc(Car::getCreateTime); return carService.page(pageObj, wrapper); }

MyBatis-Plus的LambdaQueryWrapper可以直接用方法引用指向实体字段，避免把数据库字段名硬编码成字符串，万一重构字段名会漏改。分页插件别忘了在配置类里加：

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

没有这行配置，Page的返回值虽然不为空，但里面的记录会是空的，这是一个很容易踩的坑。

4.4 预约看车的状态流转

预约功能的核心是状态流转。我设计了t_reservation表的status字段：0表示待确认，1表示已同意，2表示已拒绝，3表示已取消。每次用户或卖家操作，就更新状态。这个字段虽然简单，但保证了买卖双方的沟通有最基本的流程约束，后台管理里也能统计所有预约的记录和状态分布。

用户端发起预约时，要同时校验车辆当前是否在售，防止对“已售”车辆发起预约。我在service层加了一行检查：

Car car = carService.getById(carId); if (car == null || car.getStatus() != CarStatus.ON_SALE) { throw new RuntimeException("车辆不存在或已下架"); }

4.5 后台管理模块

管理员端我实现了用户管理、车辆审核、公告发布、品牌车系维护四个核心功能，全部放在/admin/**之下。车辆审核的操作逻辑是：点击“通过”，车辆状态从0变为1；点击“驳回”，车辆状态不变但可以填一条驳回原因，系统会以留言形式通知卖家。

很多人在做管理后台时会陷入“功能追求大而全”的泥潭，把系统的管理功能做得比业务功能还复杂。我当时控制住了自己，只保留真正必要的功能。答辩的实际经验告诉我：把核心功能做完整、做严谨，比堆砌十个半成品功能有用得多。

5. 开发期最容易踩的五个坑

整个开发过程大概两周，中途遇到的各种问题加起来可能比写代码的时间还多。我把印象最深的五个坑列出来，希望你看完能跳过这些弯路。

5.1 Spring Boot版本与JDK版本的兼容性

我第一次新建工程时，IDEA默认生成了Spring Boot 3.4.3，但本机JDK是8，一启动就报类似“无法读取模块描述符”之类的错误。后来把Spring Boot降级到2.7.18，并把pom.xml里的Java版本改为1.8才正常运行。

判断版本是否兼容其实很简单：看Spring Boot官方文档的版本说明，2.x支持JDK 8及以上，3.x要求JDK 17及以上。如果看到java.lang.UnsupportedClassVersionError，基本就是版本不匹配。所以在你动手之前，先确认好自己的JDK版本，再决定用哪个Spring Boot版本。

5.2 图片上传后刷新页面显示不了

这是个经典问题：文件上传到了本地目录，但浏览器访问http://localhost:8080/xxx.jpg却404。原因是Spring Boot默认的静态资源映射不会映射到项目外的目录。解决办法是写一个WebMvcConfigurer，把本地目录映射成一个URL路径：

@Configuration public class WebConfig implements WebMvcConfigurer { @Value("${upload.path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler("file:" + uploadPath); } }

注意Windows和Linux下file:前缀后面接的路径格式有差异，Windows是file:D:/xxx/uploads/，Linux是file:/usr/local/xxx/uploads/，我后来又写了一个工具类根据系统自动补正。

5.3 MyBatis-Plus分页查询返回空数据

见上面提到的分页插件配置问题。我一开始没加PaginationInnerInterceptor，页面显示“共0条”，但是同样的查询条件去掉分页又能查到数据。这个问题排查了好几个小时，最终发现就是漏了那一行配置。如果你在MyBatis-Plus里使用分页，请一定确认加了分页插件。

5.4 数据库连接失败：时区与驱动问题

用MySQL 8.0时，如果JDBC连接串不指定时区，启动后第一次查库就会报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。当时看到一堆乱码还以为是编码问题，结果是时区。解决办法是在JDBC地址里加参数：

jdbc:mysql://localhost:3306/xuedu_car?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

另外，如果你是MySQL 8.0，数据库驱动要用com.mysql.cj.jdbc.Driver，这是新版驱动类名，旧的com.mysql.jdbc.Driver虽然也能配但会打警告，推荐直接使用新版。

5.5 IDEA的Spring Boot项目启动后页面样式丢失

列表页加载出来文字是有的，但所有CSS和JS都404。排查后发现是Thymeleaf模板里引入静态资源时写的是以/static开头的路径，但Spring Boot静态资源的默认URL前缀并不包含/static，而是直接从根路径映射。

正确的写法是把/static去掉，直接引用/css/style.css、/js/jquery.js。模板引擎的th:href="@{/css/style.css}"会自动解析到classpath下的static目录。如果路径写成了@{/static/css/style.css}，在页面中也能访问到，但部署到服务器上后非常容易出现问题，最好统一规范。

6. 论文、开题报告和PPT的准备策略

代码写完，项目跑起来，毕设工作其实才完成了一半。论文、开题报告、答辩PPT这三个文档性材料的质量，很多时候决定了最终成绩的上限。我见过不少同学代码写得不错，但论文写成一团乱麻，答辩时被老师问得说不出话。所以这一章专门讲讲文档怎么配合项目来写。

6.1 开题报告：重点在“研究现状”和“研究内容”

开题报告是毕设的第一步，字数要求通常2000到3000字。结构大致是选题背景、国内外研究现状、研究内容、拟解决的关键问题、技术路线、进度安排。

很多人开题报告的“国内外研究现状”写成了纯粹的“百度百科简介”，列举了一堆二手车平台的名字但没说清楚它们与自己系统的关系。我的建议是：每个平台列出来之后，要说明它采用的什么技术路线，这个技术路线给了我的系统什么启示。比如“某二手车平台通过大数据技术分析车辆价格走势，本文则侧重Spring Boot框架下的轻量级系统实现，重点关注二手车信息的管理与展示流程”。

“研究内容”部分要和系统的功能模块一一对应。我当时把论文研究内容分成了三个层面：基础信息管理层面、业务交互层面、系统保障层面，分别对应后台管理、车辆发布预约、用户权限与数据安全，这样逻辑非常清楚。

6.2 论文：结构与图表是灵魂

论文我建议按照经典的“绪论-相关技术-需求分析-系统设计-系统实现-系统测试-总结”章节结构来走。我最想提醒的是三件事：

第一，相关技术介绍不要写成教材复读机。不要抄一大段“Spring Boot是什么”，而是要有“本文为什么选择它”的分析，这是我前面2小节里做的选型比对的书面版本。写“Spring Boot通过自动配置减少了传统SSM中大量的XML配置工作，使开发者可以更专注于业务逻辑实现”，比粘贴项目介绍有意义得多，老师也能看出你是真用过、真想过的。

第二，图表数量和质量要够。数据库ER图、系统架构图、功能结构图、时序图、流程图，以及关键界面的截图，都是论文的加分利器。所有的图不要用截图替代，用Visio或者ProcessOn重画一遍，保持风格统一。一张清晰的功能结构图，比一百句文字描述都管用。

第三，测试结果要真实。我当时把每个功能模块的测试用表格形式整理出来：测试项、操作步骤、输入数据、预期结果、实际结果、是否通过，一共整理了几十个用例。这部分太能体现工作量了，答辩时老师看一眼你的测试表格就知道你有没有实际跑过系统。

6.3 PPT：讲清楚五个问题就够了

答辩PPT不需要炫技，核心是把评委最关心的五个问题讲清楚：

1. 你为什么要做这个选题？（背景与意义）
2. 你做了什么？（功能模块与界面展示）
3. 你怎么做的？（技术架构与设计思路）
4. 做出来的效果如何？（功能演示与测试结果）
5. 哪些地方做得还不够好？（不足与展望）

我当时PPT一共做了18页，其中功能演示占了8页。每一页放一个明确的功能点截图和一句话说明。页面切换不要太花哨，答辩现场极有可能用的还是学校的旧电脑，动画太多很容易卡死。

有一个小技巧：答辩前一定准备一套完整的数据和操作流程。比如提前在数据库里插入几条车辆数据和预约记录，答辩现场演示时不会手忙脚乱。我当时还准备了一份“系统部署启动说明”文档，评委如果问部署细节，就直接翻出这页回答，应对非常从容。

7. 这个项目还能怎么扩展

做完整个系统后，我曾经认真想过一个问题：如果时间允许，我会在哪些方向上继续完善？列出这几个方向，也是给想在这个题目上进一步提高的同学一些思路。

第一是消息通知机制。目前的预约确认是通过卖家登录后查看预约列表被动获取的，如果能引入WebSocket或者邮箱提醒，买家发起预约后卖家能实时收到通知，用户体验会有明显提升。对于毕设来说，这也可以作为论文中“系统不足与展望”里的一节来写。

第二是车辆价格评估模块。可以通过爬虫采集公开二手车平台的挂牌价数据，按品牌、车龄、里程等维度计算一个估值范围，给买家提供参考。技术上可以简单做一个基于规则的价格估算，甚至跟进机器学习模型，这个方向工作量不大，但确实能显著提升系统的实用性。

第三是前后端分离重构。把Vue作为前端框架，与后端通过REST API交互，不仅界面可以实现更丰富的交互效果，也让项目更加接近企业真实开发模式。如果你找工作方向是Java后端，简历里能写一个有Vue+Spring Boot分离项目的经历，会比纯模板渲染加分不少。

第四是文件存储的云化。把图片上传从本地磁盘改成对象存储或者云服务器存储，能去掉部署环境对文件路径的强依赖，同时也能学会如何在业务代码中调用第三方存储服务。这个方向对以后的工作也很有帮助。

我没有把这些扩展功能全部做进去，是因为毕设的时间和精力是有限的，与其追求大而全，不如把一个主流程做到稳定可靠。但你完全可以根据自己的学习目标和答辩要求，选择合适的扩展方向来强化项目。

做这个项目期间我最大的感受是：Spring Boot本身并不难，真正需要花心思的是业务建模和流程设计。我按照“先想清楚业务、再设计表结构、最后写代码”的顺序推进下来，后面几天基本没有返工。如果你现在还在纠结选题或者还没开始动工，听我一句劝：不要急着打开IDEA创建工程，先拿张纸把你项目里最核心的那条业务链路完整走一遍，把涉及的实体和状态理清楚。这个过程确实很枯燥，但它是整个项目最值得花时间的地方。做完这一步之后，后面的一切都会顺畅很多。

本文还有配套的精品资源，点击获取