SSM二手车交易网站毕业设计：从启动到权限隔离的完整实战解析

简介：基于SSM框架的Java毕业设计项目——二手车交易网站完整源码包，面向计算机专业毕业生和Java Web开发者，可作为毕业设计选题、系统开发参考或项目实训。系统采用JSP+Java+MySQL开发，B/S架构，设计有管理员、用户和前台三大端，覆盖二手车分类管理、信息发布、定金支付、预约到店、汽车评估、评估报价、论坛交流等核心业务，功能较为完整。资源包共1325个文件，约47.56MB，包含127个Java源码、155个JSP页面、354个JavaScript脚本、137个CSS样式表，以及数据库脚本、设计文档与演示视频，目录结构清晰，便于按模块查阅。压缩包内附环境说明，使用JDK1.8、Tomcat7、MySQL5.7即可运行。目前已有164人学习下载，适合需要快速上手毕业设计或学习SSM整合开发的读者。

1. 一套 SSM 二手车交易网站，真正值钱的是那张订单状态图

拿到一个基于ssm的二手车交易网站毕业设计源码包，你大概率会先解压、导入 IDEA、改数据库密码，然后祈祷它能一次跑起来。这个流程我在帮人看项目时走过很多遍，真正决定这套代码能不能放进简历、能不能过答辩的，不是 Spring、SpringMVC、MyBatis 三个框架的机械拼接，而是它业务层里那几张表的设计和状态流转。二手车交易和普通电商最大的不同是“一车一况一价”，车源、订单、线下看车、过户这些环节的建模方式，直接决定这个项目是换个皮的商品管理系统，还是一个能讲清楚交易闭环的毕设作品。

这篇文章不评价某个具体源码包的代码质量，而是以「SSM 二手车交易网站」这个标题为锚点，把这类项目从解压到跑通、从改写到演示的完整路径拆开讲。新手可以照着一步步复现，老手可以重点看第四章的权限隔离和最后一章的数据预热技巧。

2. SSM 三层架构与二手车交易后台的对应关系

2.1 为什么二手车交易网站仍然值得用 SSM

Spring Boot 已经是主流，但毕业设计场景里 SSM 依然大量出现，原因不复杂：教学大纲里 Spring、SpringMVC、MyBatis 是分开讲的，课程设计需要一次性把三个框架都用上，用来证明掌握程度。Spring Boot 的自动配置把这些细节都隐藏了，反而不适合作为 SSM 课程结课作业的载体。

另一个实际原因是二手车交易网站这种管理信息系统，业务逻辑并不复杂，核心就是「车源管理 + 订单流转 + 用户体系」，SSM 的分层结构刚好足够表达，不需要微服务、不需要消息队列。

典型分层对应关系如下表，我一般按这个结构去理解一套陌生的 SSM 代码：

2.2 从压缩包到本地可运行的启动顺序

拿到源码包后不要急于点运行，常见做法是先按下面的顺序做三件事。顺序错了会出现「启动报错找不到 Bean」「数据库连接失败」「页面 404」等连锁问题。

# 1. 确认 JDK 与 Maven 版本 java -version mvn -v # 2. 初始化数据库，导入项目自带的 SQL 脚本 mysql -u root -p < sql/second_hand_car.sql # 3. 修改 jdbc.properties 中的数据源配置 cd src/main/resources vim jdbc.properties

jdbc.properties里必改三个参数，注意密码如果包含特殊字符如&，在 properties 文件里需要转义，否则连接串会被截断：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/second_hand_car?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=your_password

参数说明：characterEncoding=utf8是中文乱码修复的关键，serverTimezone=Asia/Shanghai解决 MySQL 8.x 的时区报错，useSSL=false避免本地连接时频繁输出 SSL 警告。如果项目用的是 MySQL 5.7，serverTimezone可以省略。

Tomcat 配置方面，IDEA 中点Edit Configurations新增 Tomcat Server → Local，Deployment 里添加war exploded，Application context 建议写成/ssm-car。这里有一个很常见的坑：如果 Deployment 里没有 Artifact，说明项目没有成功被 Maven 识别，先执行一次mvn clean compile再刷新。

MyBatis 的 SQL 日志是排查问题的第一条线索。在log4j.properties或logback.xml中把 Mapper 包日志级别调到 DEBUG，然后在浏览器里触发一次车辆列表查询，控制台会打印完整 SQL 和参数：

<logger name="com.example.car.mapper" level="DEBUG"/>

这样配置后，页面返回空数据时能立刻分辨是 SQL 查不到、参数没传进去，还是前端 JSP 渲染问题。

3. 核心数据建模：车辆、订单、收藏三类表的 SQL 设计与 Mapper 实现

3.1 车辆表的分表思路与字段取舍

二手车交易网站的主表是车辆信息表，但字段设计上有讲究。车源基本信息、车辆图片、车辆配置参数（排量、变速箱、排放标准）如果全塞在一张表里，会导致表字段过多、查询性能下降。常见做法是拆成car_info和car_image两张表，前者存一车一条的核心数据，后者一对多存图片路径。

下面是一个我复现这类项目时觉得比较合理的建表 SQL 片段，你可以对照手头源码包中的表结构看差异：

CREATE TABLE `car_info` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL COMMENT '车源标题', `brand` VARCHAR(30) NOT NULL COMMENT '品牌', `model` VARCHAR(50) NOT NULL COMMENT '车型', `price` DECIMAL(10,2) NOT NULL COMMENT '售价（万元）', `mileage` DECIMAL(8,2) DEFAULT 0 COMMENT '表显里程（万公里）', `gearbox` TINYINT DEFAULT 1 COMMENT '1手动 2自动', `emission_std` VARCHAR(10) DEFAULT '国V' COMMENT '排放标准', `status` TINYINT DEFAULT 0 COMMENT '0待审核 1在售 2已售 3下架', `seller_id` INT NOT NULL COMMENT '发布者ID', `view_count` INT DEFAULT 0 COMMENT '浏览量', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_brand` (`brand`), KEY `idx_status` (`status`), KEY `idx_price` (`price`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='二手车源信息表';

注意两点：price用DECIMAL而不是FLOAT，避免浮点精度问题，这在二手车这种大额交易场景里属于会被导师质疑的点，回答「用 DECIMAL 存金额是业务开发规范」能加印象分；status字段单独建索引，因为首页和列表页的每一次查询几乎都带WHERE status = 1条件。

3.2 条件检索的 Mapper 动态 SQL 写法

二手车网站最核心的交互是筛选：按品牌找、按价格区间找、按里程找、按排量找。SSM 项目中这个功能要用 MyBatis 的动态 SQL 实现，它也是答辩时几乎必被问的一个点。先看 Mapper 接口：

public interface CarInfoMapper { List<CarInfo> searchCars(@Param("brand") String brand, @Param("minPrice") Double minPrice, @Param("maxPrice") Double maxPrice, @Param("status") Integer status); }

对应 XML 中的核心片段如下：

<select id="searchCars" resultType="com.example.entity.CarInfo"> SELECT * FROM car_info <where> <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> AND status = #{status} </where> ORDER BY create_time DESC </select>

这份 SQL 里有三个值得展开的细节。

<where>标签是第一个关键。它有自动剔除多余AND前缀的能力，比如brand没传时，生成的 SQL 是WHERE price >= 50000 AND status = 1，不会出现语法错误。

>和<是第二个关键。XML 中<会被解析为标签开始，所以小于等于必须写成<=，这是一个排查了很久才会发现的低级报错点。

状态参数status没有包在if里，这是故意的。前台检索永远只看在售车辆，status = #{status}是硬条件，由 Service 层强制传入。如果这里不写死，用户传入status=2就能看到已售车辆，属于越权访问，卖家和买家看到的车源池应该不同，这是项目里的一个重要权限点。

Controller 层的写法上有两种流派。一种直接return "searchResult"返回视图名；另一种在方法上标@ResponseBody返回 JSON，由前端 JS 渲染。对于带多个筛选条件的页面，我推荐后者，因为前端可以做成异步局部刷新，体验明显更好。但要注意一点，@ResponseBody返回 JSON 时，全局返回类型不要写成Map<String, Object>而是统一一个Result<T>包装类，里面的code、msg、data三段结构能减少前后端对接时的沟通成本。

3.3 订单表的状态机设计与事务边界

二手车订单和普通商品订单最大的差异在于线下流程长，状态机更复杂。参考状态枚举如下：

这个状态机的价值在于：每个状态转换都对应一次数据库更新操作，而这些更新必须在一个事务里完成。例如用户点击「确认看车」，后台要同时改订单状态、给卖家发站内信、可能还要记录一条操作日志。三条 SQL 如果不在同一个事务里，会出现订单状态变了但消息没发出去的脏数据。

Service 层代码里我一般这样定义事务边界：

@Override @Transactional(rollbackFor = Exception.class) public void confirmViewing(Integer orderId) { // 1. 校验订单当前状态必须为待看车 Order order = orderMapper.selectById(orderId); if (order == null || order.getStatus() != 1) { throw new BusinessException("非法状态流转"); } // 2. 状态改为意向确认 orderMapper.updateStatus(orderId, 2); // 3. 通知卖家 notificationMapper.insert(orderId, order.getSellerId(), "买家确认看车"); }

需要注意rollbackFor = Exception.class这个属性。Spring 声明式事务默认只回滚RuntimeException，如果你的 Service 方法抛的是自定义BusinessException且它继承自Exception，事务不会回滚。这是一种很隐蔽的 bug，一个异常抛出后数据竟然保存成功，查了半天事务配置才发现问题。

答辩时如果被问「怎么保证订单状态不混乱」，答三样就够：数据库层用状态字段 + 业务层事务控制 + 每个状态流转入口做前置校验。这三层缺一不可，光靠数据库约束兜不住跨表更新的一致性批量问题。

4. 买卖双方隔离与后台管理的权限控制路径

4.1 用户表加角色字段，还是单独建角色表

二手车交易网站一般有三种角色：普通用户（买家）、卖家、管理员。一个用户既可以是买家也可以是卖家——自己发布车源时是卖家，收藏别人的车时是买家。所以我倾向在user表上加两个独立字段：is_seller和role，前者判断是否开通卖家权限，后者区分管理员与普通用户。

CREATE TABLE `user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE, `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后存储', `phone` VARCHAR(20), `is_seller` TINYINT DEFAULT 0 COMMENT '是否开通卖家权限', `role` TINYINT DEFAULT 0 COMMENT '0普通用户 1管理员', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

很多源码包里password字段是明文存的，这是答辩时比较好拿出来说的一个改进点。用 Spring Security 的BCryptPasswordEncoder做加密只需要改注册和登录两个方法，但安全性提升是质的。改法：

BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); // 注册时 String encodedPwd = encoder.encode(rawPassword); // 登录时 boolean matches = encoder.matches(rawPassword, encodedPwd);

注意不要重复加密。我见过直接把encodedPwd再往encoder.encode()里传导致永远登不上的写法，这种错误在评审演示时其实不容易暴露，但被追问到加密逻辑时会比较尴尬。

4.2 SpringMVC 拦截器实现后台管理路径保护

后台管理接口必须做登录拦截。SSM 中最直接的方式是配置一个HandlerInterceptor，在spring-mvc.xml里声明拦截路径。核心代码：

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(request.getContextPath() + "/login"); return false; } return true; } }

配置注册：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/admin/**"/> <mvc:mapping path="/seller/**"/> <mvc:exclude-mapping path="/admin/login"/> <mvc:exclude-mapping path="/css/**"/> <mvc:exclude-mapping path="/js/**"/> </mvc:interceptor> </mvc:interceptors>

这里的一个细节是：静态资源路径css、js必须排除，否则页面加载时会被拦截，出现「页面能打开但完全没样式」的现象。排查这类问题有一个快速思路：打开浏览器开发者工具，看 CSS 请求的响应状态码是否为 302，如果是，就是被拦截器重定向到登录页了，网络面板会显示Request Method: GET和Status Code: 302，很好辨识。

后台管理模块的页面跳转模式一般是：管理员直接使用一个/admin/list请求获取所有待审核车源，使用的就是前文提到的 CarInfoMapper。此时传status值为 0，代表待审核，管理员在详情页审核通过后调用updateStatus(orderId, 1)完成上架。这个过程涉及car_info的 update 语句，需要在前端表单中给定对应carId参数。Controller 获取方式：

@PostMapping("/admin/audit") public String audit(@RequestParam("carId") Integer carId, @RequestParam("approve") Boolean approve) { int targetStatus = approve ? 1 : 3; carInfoMapper.updateStatus(carId, targetStatus); return "redirect:/admin/list"; }

redirect:/admin/list是 PRG 模式的一个体现，防止表单重复提交——如果直接 return 响应视图名，刷新页面时浏览器会提示「确认重新提交表单」，这在演示现场属于上面那条表里列的「页面/交互细节」类问题，影响不大但观感不好。

4.3 卖家与买家看到的数据范围控制

权限隔离不只要做页面前的拦截，更重要的是数据层面的隔离。卖家的「我的车源」列表应该只查seller_id = 当前登录用户id的数据，这个条件必须在 Mapper SQL 层面固定，不能依赖前端传参。如果前端传入一个sellerId参数、Controller 直接拿去查，用户把参数改成别人的 ID 就能看到别人车源的管理入口，这是典型的越权漏洞。

<select id="selectMyCars" resultType="com.example.entity.CarInfo"> SELECT * FROM car_info WHERE seller_id = #{currentUserId} ORDER BY create_time DESC </select>

currentUserId从 Session 里拿，不从前端参数拿。SSM 项目里我经常用一个BaseController提供getCurrentUserId()方法，内部从HttpSession取值，子 Controller 继承即可。这里可以配合 Java 线程安全的知识点，把当前用户放进ThreadLocal，避免每个方法都要从RequestContextHolder里取一次 Session，这个写法刷新了旧思路，也和面试八股文里的「ThreadLocal 线程隔离」知识点做了对映。

5. 让演示有说服力：造数脚本、路径验证与交付物一致性检查

一套源码包如果只跑通空数据库、页面显示 0 条记录，演示说服力会弱很多。我习惯在答辩前做三件事，完全不需要改代码，只是数据准备和路径验证层面的工作。

第一，写一个造数脚本把车源数据撑起来。用手写 INSERT 太慢，常见做法是用存储过程或者直接用 Java 写个临时类：

// 生成 40 条测试车源数据，覆盖不同品牌和价格区间 for (int i = 1; i <= 40; i++) { CarInfo car = new CarInfo(); car.setBrand(brands[i % brands.length]); car.setModel("车型" + i); car.setPrice(i * 0.5 + 5); car.setMileage((i % 15) + 1.0); car.setStatus(1); car.setSellerId(1); car.setCreateTime(new Date()); carInfoMapper.insert(car); }

造数有两个注意点。造数脚本每次运行前先TRUNCATE car_info，然后重跑一次，确保数据可重复；价格和里程要拉开梯度，演示筛选功能时有明显区分度，不要 40 条数据全是同一个价位，否则筛选结果看不出差异。

第二，按演示时间线回跑一遍核心路径。演示视频里最终用户看到的操作链路一般是：注册登录 → 浏览车源列表 → 条件筛选 → 查看详情 → 提交订单 → 卖家后台订单管理 → 管理员审核。你在本地跑的时候重点检查两个最容易出错的地方。

一个是图片。分页列表页的图片地址如果是外链，网络差时会出现图片加载缓慢或裂图，演示现场非常减分。我一般建议把所有车辆图片放到项目webapp/static/images/cars/目录下，Img 标签写相对路径，只要项目不断跑就不会加载不出来。注意图片文件名不要用中文，本地 Tomcat 可能正常，但部署到 Linux 服务器后 URL 编码会有差异。

另一个是录屏系统的时间。不要录一个超过 8 分钟的演示视频，评审时没人有耐心看完，视频内最好 30 秒内能看到第一个功能点，我一般是先展示首页完整效果再点进详情页，让观看者最快建立起「这是个完整系统」的视觉锚点。

第三，核对 PPT 中和源码的一致性问题。常见问题包括：PPT 里写的数据库表结构图和实际 SQL 文件里的表不一致，ER 图少了两条关联线，功能列表提了「车辆收藏」但源码里没有收藏表。这里不需要改代码，只需要把 PPT 中对应页修改为与工程一致。但如果在阅读源码时真的发现问题，例如 PPT 里写了「推荐算法」，但代码里只是按浏览量排序，建议把 PPT 里的描述从「算法」降级为「基于热点数据的车源推荐」，再写一个ORDER BY view_count DESC的查询来支撑这个描述，技术上实现很便宜，挡不住「这个推荐逻辑怎么实现的」这一追问。

最后，关于交付物一致性的整体验证，我习惯做一次「干净环境跑通」演练：换个目录、把 target 目录删掉、清掉数据库重新导入 SQL、重启 Tomcat，按脚本走一遍主流程。这一步能拦截掉「换一台机器就报错」的翻车场景。跑通之后再把 JDBC 密码改回去，确认配置文件状态可以交给答辩环境。

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