基于Java+SpringBoot+SSM的二手车交易平台系统设计与实现解析

三四年前我带过的不少学弟学妹做Java毕设，十个人里至少有四五个选了“XX交易平台”这类题目。后来自己参与过项目评审，也帮人看过好几百套下载来的源码，发现一个很普遍的现象：系统能跑起来的人不少，但能把自己的项目讲清楚、甚至在答辩时扛住老师追问的人，真的不多。大多数同学卡在同一个地方——只知道功能，不知道为什么要这么设计。

这次拿到的题目是“基于Java+SpringBoot+SSM二手车交易平台系统”，从标题就能看出来，这是一个典型的全栈Web开发毕业设计：有源码、有LW（论文）、有调试文档，还有讲解。标题背后其实藏着一整套完整的业务系统，值得好好拆一遍。这篇文章我打算从业务拆解、技术选型、数据库设计、核心功能实现、以及实际调试中容易踩的坑这几个角度，把整个项目翻个底朝天。无论你是准备拿它当毕设，还是想通过这类项目练SpringBoot+MyBatis的工程能力，这篇文章的价值都在于让你不仅“能跑”，还能“讲明白”。

1. 二手车交易平台到底在交易什么：业务定位与模块拆解

很多人拿到这种项目，第一反应就是去看代码、建表、启动项目。我建议反过来，先想清楚这个系统是给谁用的，解决什么问题。二手车交易平台本质上不是“卖东西的商城”，它是一个撮合类平台。平台本身不持有车源，车源来自卖家/个人用户，买家通过平台浏览、筛选、预约看车，最终完成线下或线上交易。这种业务模型和普通电商有明显区别，导致功能设计和表结构会不一样。

1.1 三类核心角色与操作路径

一个完整的二手车交易平台，至少要有这么几类使用者：

角色	核心诉求	典型功能
游客/未登录用户	先看看有什么车	浏览车辆列表、查看车辆详情、搜索筛选
注册买家	找到合适的车，约看车	搜索筛选、收藏车辆、预约看车、生成订单
注册卖家	把车卖出去	发布车源、管理自己发布的车辆、查看买家预约
管理员	保证平台内容可控	用户管理、车源审核/上下架、公告发布、订单管理

这里有个细节值得注意：在很多毕设版本里，买家、卖家不区分角色表，而是共用一张用户表，通过一个role字段区分。这样做的好处是简化系统，坏处是没有店铺/卖家认证的逻辑。但在毕设场景下，这种简化是合理的，而且也好解释：同一账号既可以买车，也可以卖车。

1.2 一单二手车交易在系统里的完整生命周期

我在给学弟学妹讲这个项目的时候，最喜欢让他们画一张状态流转图。只要把下面这条链路画清楚，项目就懂了一半：

• 卖家登录系统，发布车源，车辆初始状态为“待审核”或“在售”（取决于是否启用管理员审核）；
• 买家进入首页，按照品牌、价格区间、里程、变速箱等条件筛选车辆；
• 买家进入车辆详情页，看到车况描述和图片，如果感兴趣就点击“预约看车”或“立即购买”；
• 系统生成预约记录，同时车辆状态从“在售”变为“已预订”；
• 买家联系卖家线下看车、议价、成交；
• 管理员在后台把订单状态更新为“已成交”，车辆状态变为“已售出”；
• 如果交易未达成，买家或卖家取消预约，车辆状态自动回到“在售”。

这个状态机是整个系统最核心的业务逻辑。很多毕设只做了增删改查，缺的就是这种状态管理能力，而老师恰恰喜欢问这个。比如“两个买家同时预约同一辆车怎么办？”这个问题的答案，在第4章我会给出代码方案。

1.3 为什么这类系统是Java后端练级的好样本

二手车交易平台在技术难度上正好卡在“简单CRUD”和“复杂业务系统”之间。它比学生管理系统多了图片上传、条件查询、状态流转、权限拦截这些真实项目常见的东西，又没有电商那种需要秒杀、高并发、分布式事务才能撑起来的复杂度。用它来学SpringBoot和SSM整合，性价比非常高。

这个题目还有一个隐性价值：业务足够贴近生活，答辩时你需要解释的每一个业务规则，老师都听得懂。相比之下，“高校实验室设备管理系统”那种题目，老师还得先理解你的业务背景，沟通成本高很多。

2. 用SpringBoot重新组装SSM：技术选型背后的真实考量

标题里出现了“Java+SpringBoot+SSM”三个关键词，不少同学会困惑：SpringBoot和SSM不是两套东西吗，怎么放在一起？这个问题必须搞清楚，因为这是答辩时几乎必问的问题。

2.1 SpringBoot不是替代SSM，而是SSM的“新皮肤”

SSM指的是Spring、SpringMVC、MyBatis。SpringBoot则是一个自动装配和快速启动框架。实际上SpringBoot底层依然运行着Spring和SpringMVC，你照样可以在SpringBoot里整合MyBatis来操作数据库。

所以严格来说，这个项目应该叫“基于SpringBoot整合SSM的二手车交易平台”。SpringBoot在这里起的作用是：帮我省掉了Spring和SpringMVC的大量XML配置，用自动配置和注解把整个工程串起来。MyBatis仍然负责SQL和数据库映射，SpringMVC仍然负责接收请求和返回视图。

以SpringBoot 2.x为例，一套基础依赖如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.2.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.11</version> </dependency>

如果项目前端用了JSP（很多毕设版本确实用的JSP），还要额外加一个tomcat-embed-jasper依赖，否则JSP页面解析不了。这一点我后面专门讲，很多人在这个地方卡半天。

2.2 工程目录结构：先搭好骨架再谈功能

我见过太多新手把Controller写成几百行的巨型类，Service层干巴巴一层，SQL直接写在注解里。真到了答辩阶段，老师说“你把项目结构讲一下”，自己都理不清。正确的工程结构应该长这样：

src/main/java/com/example/car ├── CarApplication.java // SpringBoot启动类 ├── common/ // 通用返回结果、常量、异常处理 │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config/ // 配置类：拦截器、静态资源映射 │ ├── WebMvcConfig.java │ └── DruidConfig.java ├── controller/ // 控制层 │ ├── UserController.java │ ├── CarController.java │ ├── AppointmentController.java │ ├── OrderController.java │ └── AdminController.java ├── entity/ // 实体类 │ ├── User.java │ ├── Car.java │ ├── Appointment.java │ └── Order.java ├── mapper/ // MyBatis Mapper接口 │ ├── UserMapper.java │ ├── CarMapper.java │ └── AppointmentMapper.java ├── service/ // 业务层 │ └── impl/ └── utils/ // 工具类：JWT、文件上传、MD5等

有的同学喜欢用MyBatis-Plus来省掉大量Mapper XML，这个我不反对，但如果你是做毕设，而且想体现自己懂SQL，我建议还是手写XML。一方面手写SQL能让你对表结构非常熟悉，另一方面答辩时老师问“你的分页查询怎么实现”，你能顺着XML里那个LIMIT讲清楚，比一句“用MyBatis-Plus的selectPage”要有说服力得多。

2.3 SpringBoot版本选型：别一上来就上3.x

这是我在辅导时经常提醒的一个坑。现在SpringBoot 3.x已经有同学在用了，但它默认要求JDK 17，且一些老版本的MyBatis整合包、Druid适配都有兼容性问题。如果你的毕业设计环境里老师的JDK还是8，或者你手里的教程/源码基于SpringBoot 2.x，别盲目升级。

我的建议：毕设和练手项目，SpringBoot选2.7.x，JDK选1.8或11，MySQL选5.7或8.0。这套组合经过无数项目验证，网上能搜到的资料最多，出了问题最容易被排查。

3. 数据库怎么设计才像“交易系统”：核心表结构与字段陷阱

讲完技术选型，接下来是数据库设计。很多毕设的车辆表就是简单的id、title、price、image，然后开发时发现需求变来变去，最后SQL改得乱七八糟。我在这里直接给出一套经过验证的表结构，你可以在此基础上改。

3.1 车辆表：信息完整度和状态字段是两条主线

二手车交易平台里，车辆信息要比普通商品复杂得多。除了价格，买家还关心车龄、里程、排量、变速箱、排放标准、过户情况、车辆所在地。下面是我推荐的核心表结构：

CREATE TABLE t_car ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT '车辆ID', user_id INT NOT NULL COMMENT '卖家用户ID', brand VARCHAR(32) NOT NULL COMMENT '车辆品牌', series VARCHAR(64) COMMENT '车系', title VARCHAR(128) NOT NULL COMMENT '车源标题', price DECIMAL(18, 2) NOT NULL COMMENT '售价（元）', mileage INT COMMENT '行驶里程（万公里）', first_reg_date VARCHAR(16) COMMENT '首次上牌日期', engine_type VARCHAR(16) COMMENT '排量，如1.5T', gearbox VARCHAR(16) COMMENT '变速箱：自动/手动', emission_standard VARCHAR(16) COMMENT '排放标准', color VARCHAR(16) COMMENT '车身颜色', city VARCHAR(32) COMMENT '车辆所在地', image_url VARCHAR(255) COMMENT '封面图路径', detail TEXT COMMENT '车况描述', status TINYINT DEFAULT 0 COMMENT '0待审核 1在售 2已预订 3已售 4下架', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_brand_price (brand, price), KEY idx_status (status) ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT ='车辆信息表';

这张表里有两个容易被忽视的设计点。

第一，价格字段必须用DECIMAL(18,2)，不能用Double或Float。原因很简单：二进制浮点数对金额的表示存在精度误差，如果后续做统计报表或接入支付，会出大问题。同样设计思想的还有订单表里的订单金额、定金金额等。

第二，状态字段status是一个“状态机”，而不是一个给用户看的展示字段。在业务代码里，你应该用一个常量类或者枚举来定义：CAR_STATUS_PENDING=0、CAR_STATUS_ON_SALE=1、CAR_STATUS_BOOKED=2、CAR_STATUS_SOLD=3、CAR_STATUS_OFF=4。这样比散落在代码里的魔法值干净得多。

3.2 围绕车辆的关联表怎么组织

用户表、车辆表之外，还需要一组用来支撑业务流程的表：

• t_user用户表：id、username、password、nickname、phone、avatar、role（user/admin）、status、create_time。
• t_appointment预约看车表：id、car_id、buyer_id、seller_id、appointment_time、status（0待联系、1已完成、2已取消）、remark、create_time。记录每个买家针对某辆车发起的看车预约。
• t_order订单表：id、order_no、car_id、buyer_id、seller_id、amount、status（0待付款/1线下交易中/2已完成/3已取消）、create_time、pay_type。
• t_favorite收藏表：id、user_id、car_id、create_time。用户收藏车辆，类似“购物车”但不下单。
• t_news公告表：id、title、content、create_time。管理员在后台发布平台公告，前台滚动展示。

这组表设计的关键在关联字段。比如预约表里同时存了car_id和buyer_id，目的是查询时两边都好索引；seller_id是冗余字段，目的是卖家端查“谁来看过我的车”时，不用再关联车辆表查一圈。在业务逻辑不复杂的情况下，这种适当的冗余是提高查询效率的有效手段。

外键方面，我的建议是只在逻辑上关联，不要去建数据库层面的物理外键。毕设项目规模小，物理外键看起来问题不大，但一旦以后要拆表、做水平拆分，物理外键会变成灾难。用代码保证数据一致性，用索引保证查询效率，这才是主流做法。

3.3 字段类型、精度与字符集的几个实操建议

建表的时候，以下细节能帮你少踩很多坑：

• 用户表和车辆表都建议用utf8mb4编码，而不是utf8。utf8在MySQL里最多支持3字节字符，存不了emoji和部分生僻字，而utf8mb4是完整版。
• 所有时间字段用DATETIME，不要用VARCHAR存“2024-05-20”这种字符串。虽然查询时还能用字符串比较，但做日期加减、排序、统计时你会哭。
• 车辆图片不要直接存Base64文本，存文件路径；图片文件本身放到项目的/upload目录或者对象存储，数据库里只保留一个相对路径。下面会强调，文件路径在SpringBoot静态资源映射里需要单独配置。
• 车辆详情的车况描述用TEXT类型，足以存放几百上千字，不要用VARCHAR(255)硬撑，否则录入时超出长度会莫名报错。

如果你打算照着做，最好先把这几张表和核心字段设计好再动手写代码。很多系统做到一半推倒重来，根源就是表结构没想清楚。

4. 核心功能代码走一遍：登录鉴权、车源发布与预约下单

这一章是真正的重头戏。我会挑三个最有代表性的功能，讲清楚它们的实现思路和关键代码。整套代码你没必要逐行照抄，但核心思想一定要吃透。

4.1 登录注册、拦截器与权限控制

大多数毕设用的登录方案是Session+拦截器。相比引入SpringSecurity，这套方案在业务简单的前提下更容易讲清楚，也足够用。

注册时有一个容易被忽略的细节：密码不能明文存数据库。这里我一般建议至少做一次MD5加盐处理。更稳妥地，可以使用Spring Security自带的BCryptPasswordEncoder。毕设项目用MD5加盐即可，代码也不复杂：

String salt = UUID.randomUUID().toString().substring(0, 8); String encodedPwd = DigestUtils.md5DigestAsHex((plainPassword + salt).getBytes()); user.setSalt(salt); user.setPassword(encodedPwd);

登录后的权限拦截，用Spring MVC拦截器是最直接的方式。下面的拦截器可以拦截所有需要登录的路径：

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { String requestType = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestType)) { response.setStatus(401); } else { response.sendRedirect("/login"); } return false; } return true; } }

然后在WebMvcConfig里注册拦截器，并放行登录注册和静态资源：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/car/list", "/car/detail", "/css/**", "/js/**", "/img/**", "/upload/**"); } }

这里的关键经验是：一定要放行静态资源和上传目录，否则登录页和车辆图片全部加载不出来。很多系统“前脚点完登录后脚就404”，十有八九是拦截器路径没配好。

4.2 车源发布与图片上传：看似简单，坑在文件保存路径

车辆发布是卖家端的核心功能。它的难点不在数据库插入，而在图片上传。很多毕设系统的图片一刷新就挂，原因就是图片保存到了本地磁盘的某个临时目录，但访问时又把路径写错了。

先看Controller层：

@PostMapping("/car/publish") public String publishCar(@ModelAttribute CarForm carForm, @RequestParam("image") MultipartFile file, HttpSession session) throws IOException { User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { return "redirect:/login"; } Car car = new Car(); BeanUtils.copyProperties(carForm, car); car.setUserId(loginUser.getId()); car.setStatus(1); if (file != null && !file.isEmpty()) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String filename = UUID.randomUUID().toString().replace("-", "") + suffix; String uploadRoot = uploadProperties.getPath(); File target = new File(uploadRoot, filename); file.transferTo(target); car.setImageUrl("/upload/" + filename); } carService.publish(car); return "redirect:/car/detail?id=" + car.getId(); }

这里有两个容易写错的点。

第一，文件名不能直接用用户上传的原始文件名，可以用UUID重命名，避免中文文件名导致乱码，也避免同名文件互相覆盖。第二，数据库保存的image_url，一定要是浏览器可直接访问的URL路径“/upload/xxx.jpg”，而不是本机磁盘路径“D:/project/upload/xxx.jpg”。这就是为什么需要配置静态资源映射，让浏览器访问“/upload/**”时，SpringBoot去本地磁盘对应的目录文件。

配置方式如下：

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

application.yml里对应的配置是：

upload: path: /home/car/upload

Windows开发环境下，路径需要写成D:/car-upload这样的绝对路径，注意结尾不要少一个路径分隔符，否则file.transferTo可能失败或者保存到错误的位置。

4.3 预约看车与并发状态变更：一条UPDATE语句的巧劲

这个功能是全系统最有技术含量、也是最值得在答辩时拿出来讲的部分。它涉及一个经典问题：两个买家同时对同一辆车点击“预约看车”，系统必须保证只有一个人能预约成功。

如果在Service里写这样三步：先查车辆状态，如果是1在售；然后更新状态为2已预订；再插入一条预约记录。这个流程在高并发下会出现并发问题——两个请求同时查到了status=1，然后都去更新，后一个会把前一个的预约覆盖掉。

正确做法是使用带条件的更新语句，把“查询并判断”和“更新状态”合并成一步原子操作：

@Transactional public void bookCar(Long carId, Long buyerId) { int rows = carMapper.updateStatusToBooked(carId); if (rows == 0) { throw new BusinessException("该车辆已被人抢订或已下架"); } Appointment appointment = new Appointment(); appointment.setCarId(carId); appointment.setBuyerId(buyerId); appointment.setStatus(0); appointmentMapper.insert(appointment); }

对应的Mapper XML是这样：

<update id="updateStatusToBooked"> UPDATE t_car SET status = 2, update_time = NOW() WHERE id = #{carId} AND status = 1 </update>

这段SQL的意思是：只有当当前状态还是1时，才把状态改成2。MySQL的行锁会保证同一时刻只有一个事务能成功执行这条更新语句，另一个UPDATE影响行数为0，于是通过rows == 0这个判断抛出异常。

这个方案不需要加锁，不需要引入Redis，性能好，逻辑清晰，而且特别适合在答辩时讲。老师一听到“CAS思想”“乐观锁”“利用数据库行锁保证并发一致性”这几个词，基本这题的分数就稳了。

4.4 条件查询与分页：动态SQL的用法

车源列表最核心的是多条件搜索：按品牌、价格区间、里程、排量筛选。在MyBatis里用动态SQL实现，比在Java代码里拼接SQL字符串干净得多：

<select id="searchCars" resultType="com.example.car.entity.Car"> SELECT * FROM t_car <where> status = 1 <if test="brand != null and brand != ''"> AND brand = #{brand} </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> <if test="keyword != null and keyword != ''"> AND (title LIKE CONCAT('%', #{keyword}, '%') OR series LIKE CONCAT('%', #{keyword}, '%')) </if> </where> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

注意XML里的大于号、小于号要写成>和<，或者用 = #{minPrice} ]]> 包起来，否则XML解析会直接报错。这个小细节是新手最高频的一个报错点，我下一章专门讲。

分页这里没有推荐PageHelper插件，而是手动算offset和pageSize，原因有两个：一是毕设里手动分页更加透明，你能完全掌控SQL；二是在线上项目里数据量不大时手动分页也不会有性能问题。如果你确实想用PageHelper，记住一行配置：PageHelper.startPage(pageNum, pageSize)，查询完成后Controller里再用PageInfo封装结果。

5. 真正跑通系统时最容易卡住的三个坑：图片路径、时间格式、SQL映射

代码逻辑讲完了，现在聊实际操作。我从几十个人的提问里总结了三个频率最高的问题，每一个都能让项目从“运行正常”突然变得“无法访问”或“数据错乱”。

5.1 图片上传后页面显示404，原因不只是路径

系统跑起来了，车也发布成功了，结果点开详情页发现图片位置是个裂图。排查路径可以按下面三步走：

第一步，确认文件本身有没有保存成功。直接到upload.path对应目录下看文件在不在。文件不存在，问题在file.transferTo这行，通常是目录没有创建，或者Windows下权限不足。解决办法是在启动类或配置里先创建目录：

// 项目启动时创建上传目录 @Component public class UploadDirInitializer implements ApplicationRunner { @Value("${upload.path}") private String uploadPath; @Override public void run(ApplicationArguments args) { File dir = new File(uploadPath); if (!dir.exists()) { dir.mkdirs(); } } }

第二步，在浏览器直接访问 http://localhost:8080/upload/xxx.jpg ，如果能访问，那页面显示裂图一定是前端图片地址写错了；如果返回404，就是SpringBoot静态资源映射没有配置，或者配置的目录和实际保存目录不一致。

第三步，检查application.yml里是否配置了spring.web.resources.static-locations，如果你手动加了static-locations配置，它会覆盖SpringBoot默认的classpath:/static/，导致原来的/js/、/css/全部失效，页面变得光秃秃。

5.2 时间字段返回JSON格式不对

很多同学用MyBatis查询数据库得到LocalDateTime类型，返回给前端时变成了一串数字数组或者带T的格式，比如“2024-05-20T10:30:00”。这不是数据错了，是Jackson序列化时间类型时没有指定格式。

最简单的方案是在application.yml里全局配置：

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

不过这个配置对LocalDateTime不一定生效，因为它默认用的是JavaTimeModule。稳妥做法是在时间字段上直接加注解：

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

如果你用的是JSP+jstl，模板里显示时间又出现“2024-05-20 10:30:00.0”这种带着“.0”的结果，可以在格式化时用fmt:formatDate或Java代码里的DateTimeFormatter处理一下。

5.3 MyBatis XML中比较符报错与resultType/resultMap选择

第4章我已经提过，XML里出现小于号会直接导致解析失败，因为“<”在XML里是标签起始符号。解决办法有两个，一是转义字符，二是CDATA：

<if test="minPrice != null"> AND price <![CDATA[ >= ]]> #{minPrice} </if>

另外就是resultType和resultMap的选择。如果你是简单查询，列名和实体字段一致（或者通过数据库列别名对应），直接用resultType最省事。但如果遇到关联查询、字段名不一致、或者像“1代表在售/2代表已预订”这种需要转换的，就要用resultMap来显式映射，同时还可以在Service层或VO类里做字段翻译，把status数字显示成文字。

在这个项目中，车辆列表页往往需要显示卖家手机号、卖家昵称。如果车辆表里有seller_name冗余字段，resultType就够了。如果没有冗余，就得连表查询，在SQL里select c.*, u.nickname as sellerName，然后resultMap或resultType对应到CarVO的sellerName字段上。这也是为什么我前面推荐在预约表里冗余seller_id，目的就是减少不必要的连表。

5.4 数据库连接URL常见报错对照表

最后给一个数据库连接层面的报错排查表，这些都是我见过的高频问题：

报错信息	原因	解决方案
Access denied for user 'root'@'localhost'	用户名或密码错误，或账号不允许该ip访问	检查application.yml里的username/password，必要时修改MySQL授权
Unknown database 'car_db'	数据库不存在	先执行SQL脚本创建数据库
Not supported: CHARACTER 'utf8mb4'	驱动或MySQL版本过低	使用MySQL 5.7+，或把连接URL加characterEncoding=utf8
Server returns invalid timezone. Go to 'Advanced' tab and set 'serverTimezone'	MySQL8驱动要求指定时区	连接URL添加serverTimezone=Asia/Shanghai&useSSL=false
Public Key Retrieval is not allowed	MySQL8默认认证插件问题	连接URL添加allowPublicKeyRetrieval=true
Port 8080 was already in use	默认端口被占用	改application.yml的server.port，或用命令netstat -ano

其中Server returns invalid timezone这条，是MySQL 8和SpringBoot 2.x组合最高频的报错。很多同学以为数据库脚本或代码有问题，查了半天，结果只是在连接串上加一行参数的事。

6. 把毕设变成自己的作品：调试文档、论文与扩展改造

项目跑通只是及格线。真正让一个毕设项目“高级”起来的，是你对项目的理解和后续扩展能力。

6.1 拿到一套源码后，推荐的导入和启动顺序

如果你手里已经有一套二手车交易系统源码，包括源码、LW（论文）、调试文档，建议按下面顺序操作，不要拿着一堆文件直接双击Java文件：

1. 先看根目录下的README或调试文档，重点看数据库脚本位置（一般是.sql文件）、JDK版本要求、Maven版本和MySQL版本。
2. 用Navicat或命令行执行数据库脚本，确认所有表都建好，并且能select到初始数据。
3. 用IDEA导入项目，选择Import Project，然后以Maven方式加载。等待依赖下载完成，如果网络慢，可能需要十几分钟。
4. 检查application.yml里的数据库账号密码、端口号，注意改成你自己本机的。
5. 先启动一次，如果控制台报错，优先看是编译期错误还是运行期错误，不要盲目改代码。
6. 启动成功后再打开浏览器访问首页，优先测试登录、车辆列表、车辆详情、发布车源这几个主链路。

这个顺序的核心逻辑是“先数据、后代码、再联调”。很多人上来就点启动，报错后连项目结构都没看过，很容易被一个小配置卡很久。

6.2 从SSM到前后端分离：JWT与Vue改造思路

如果你不满足于JSP这套传统服务端渲染方案，想把它改成前后端分离项目，最值得做的改造是：

• 后端接口只返回JSON，不再返回视图。原来的Controller方法改为@RestController，返回Result统一结构体。
• 把Session登录替换成JWT（JSON Web Token）。用户登录成功后，服务端生成一个带有效期的token返回给前端；前端每次请求在Header头上带Authorization: token。后端用一个拦截器解析token并获取当前用户信息。
• 前端用Vue进行重构，路由控制页面跳转，axios发起请求。
• 静态资源分离部署，前端跑在Nginx或Node环境，后端只暴露接口。

这个改造会让你从“会写业务代码”进阶到“理解前后端交互本质”。完成它之后，不管项目是JSP版还是Vue版，你都能驾驭。

6.3 缓存、全文检索、支付模块等扩展方向

毕设如果要冲高分，以下几个扩展方向性价比最高：

• 给车辆列表页加Redis缓存：由于车辆列表是浏览最频繁的页面，把首页推荐车辆存入Redis，设置5分钟过期。讲解时可以说你减少了对MySQL查询的请求压力，这是一个很加分的点。
• 车辆搜索从LIKE改成MySQL全文索引或Elasticsearch。当车辆数据量到达万级时，LIKE ‘%keyword%’无法命中索引，会全表扫描，ES则可以做到毫秒级分词检索。
• 增加模拟支付模块：用户下订单后跳转到一个模拟收银台页面，输入“支付密码”即可完成支付，后台将订单状态从“待支付”改为“已支付”。这个模块业务闭环，代码逻辑不复杂，还能顺便把支付回调、订单超时取消这些面试加分项讲出来。

6.4 答辩与面试时，怎么讲这套系统才显水平

最后聊聊最实际的：怎么把这套系统讲得有水平。

不要上来就念PPT上的功能清单。老师想听的是你的设计思路。我的建议是准备一个五分钟左右的讲述逻辑线：先讲这个系统解决的业务痛点（车源分散、信息不透明、预约没有记录），然后讲你如何把痛点映射成功能模块，再讲数据库表如何支撑这些功能，接着讲你在开发中遇到的难点和解决方案（比如并发预约那一条UPDATE语句），最后讲你对未来的扩展规划。

这里有一个非常关键的话术：不要只说“我实现了什么”，要说“我遇到了什么问题，当时有几种方案，我为什么选择这个方案”。哪怕你选择的不一定是最优方案，这种思维过程本身就证明了你是在做工程，而不是在抄代码。

我在实际帮人调这个项目的时候，见过最可惜的一种情况是：同学把项目功能做得很全，但问他“预约看车这个功能为什么要在Service层加@Transactional”，他愣住了。这个注解本身不难，但它代表你对事务边界有没有概念。所以当你拿到任何一套源码，先别急着看页面多漂亮，静下心来把Service层的每一个核心方法搞懂，把“为什么”标注在旁边。这才是调试文档之外，真正属于你自己的那份知识。

二手车交易平台这个题目，说到底是类目极其典型的Java全栈练手项目。把它吃透，你不仅答辩能顺利，对以后理解市面上各种信息撮合类系统的业务模型，都会比别人多想一步。