简介：面向 JavaWeb 期末大作业与课程设计的二手闲置物品交易系统完整源码，适合高校计算机相关专业学生作为结课项目参考。项目采用典型的 Spring Boot 分层结构，包含商品发布、用户管理等核心功能模块；从文件预览可见 GoodsController、UserController、GoodsServiceImpl 等业务逻辑类，并配有 DruidConfig 数据库连接池配置，整体工程结构严谨，便于二次开发。资源压缩包共 352 个文件，以 java 源文件、xml 配置文件为核心，同时包含 js/css/html 前端页面、jpg/png 图片素材以及字体图标等静态资源，压缩包大小 45.54MB，目录分类清晰，可直接导入开发工具运行。目前已有 4460 人学习下载，资源实用度较高。通过这份源码，读者可以完整掌握二手交易系统的前后端实现方法，包括商品上架、订单管理等典型流程；同时项目自带基础样式与工具类，能够帮助学员快速理解用户与商品管理、数据持久化等关键环节，并能在期末答辩中从容展示项目功能与设计思路。

1. 期末季拿到这个 zip：先别急着解压，想清楚它是什么

期末交 javaweb 大作业前，很多同学拿到的第一个东西就是这个「二手闲置物品交易系统源码.zip」。这类压缩包背后通常是一套 Servlet + JSP + MySQL 的动态 Web 项目，功能上覆盖注册登录、商品发布、商品浏览、下单成交和站内留言，正好是课程设计最喜欢考的「完整业务闭环」。它解决的问题很直接：让你不用从零写代码，而是把精力放在跑通环境、读懂业务、准备答辩上。适合正在赶大作业的学生，也适合拿它当毕设前期原型的同学。但先泼一盆冷水：这类源码包最大的坑往往不是缺代码，而是代码齐全却跑不起来、演示时当场翻车。后面每一章都围绕「把 zip 变成能演示、能讲清的系统」这件事展开。

2. 本地跑通的环境配对：JDK、Tomcat 与 MySQL 怎么搭才不吵架

拿到 zip 后先别急着解压到桌面就开始敲命令。大多数课程设计源码包在别人机器上能跑，换一台就翻车，一半是环境问题，一半是版本配对问题。下面按「认目录 → 定版本 → 配 IDEA → 导数据库」的顺序走，每一步都别跳。

2.1 解压后先认目录：三种工程形态一眼区分

双击 zip 后，先看根目录的特征文件，这决定后面所有操作。最常见的是非 Maven 的传统动态 Web 工程，目录长这样：

secondhand/ ├── src/ # Java 源码，按包名分层 ├── sql/ # 建表与初始化数据脚本 ├── web/ # Web 根目录，也叫 WebRoot / webapp │ ├── WEB-INF/ │ │ ├── web.xml # Servlet、过滤器的注册中心 │ │ └── lib/ # 所有第三方 jar 都堆在这里 │ ├── css/ │ ├── js/ │ ├── images/ │ └── *.jsp # 页面文件，放在 web 根目录下 └── README.md

识别方法很直接：根目录有pom.xml就是 Maven 工程；有application.properties或application.yml且没有web.xml的是 Spring Boot 工程；只有src加web/WEB-INF/lib、没有特征文件的，就是课程设计里占比最高的传统 JavaWeb 工程。先把这个认清楚再往下走，因为非 Maven 工程对 Tomcat 版本的敏感度高得多，换错版本会直接启动失败。

如果是 Maven 工程，流程会省事很多：IDEA 打开后会自动读取pom.xml并下载依赖，左侧 Maven 面板里点package或直接配置 Tomcat 即可。但要注意依赖下载需要联网，如果仓库里配了镜像源则更快，老项目用 Maven 反而更难调到旧版本依赖。遇到这种情况，我的建议是优先按非 Maven 方式处理，直接把 jar 放进lib目录更可控。

2.2 JDK 与 Tomcat 的版本配对，这一项先确认

老 JavaWeb 项目对版本的挑剔程度远超预期。常见做法是 JDK 8 配 Tomcat 8.5 或 9，这也是很多课程设计源码默认的开发环境。如果本机装的是新版本 JDK，先确认配对关系：

判断代码用的是哪代 Servlet API，看WEB-INF/lib里的 jar 或源码 import 即可：javax.servlet.*是 Tomcat 9 及以前的写法，jakarta.servlet.*是 Tomcat 10.1 之后的写法。很多老项目在 JDK 17 + Tomcat 10 上跑不起来，根因不是语法错误，而是包名整体迁移，这不是改一个 import 能解决的，所以策略是「源码用哪代 Servlet，就配哪个 Tomcat」。

这里有个细节容易忽略：Tomcat 运行时用的 JDK 和 IDEA 里 Project SDK 不一定是同一个。如果启动 Tomcat 报UnsupportedClassVersionError，说明编译用 JDK 比运行用 JDK 新，先到 Tomcat 启动配置里把 JRE 指到同一个 JDK 8。把版本对齐放在最前面做，后面能省下一半的排查时间。

2.3 IDEA 运行 javaweb 项目的配置步骤

配上 IDEA 的步骤比较固定。打开 Project Structure，确认 Project SDK 选到刚才定好的 JDK 版本；再把WEB-INF/lib下的 jar 全选后 Add as Library——非 Maven 工程手动引入依赖就靠这一步。接着确认 Artifact，IDEA 对动态 Web 工程一般会自动生成 war exploded 格式的 artifact。最后在 Run Configuration 里添加一个 Tomcat Server Local，Deployment 页把该 artifact 加进去，Application context 填项目访问路径。

菜单名称在不同版本 IDEA 里略有出入，但核心顺序不变：先有 SDK，再有 Library，再有 Artifact，最后把 Artifact 挂进 Tomcat。命令行能参与的部分不多，但有一个文件必须先确认，它就是数据库连接配置文件，常见叫db.properties、jdbc.properties或database.properties：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/second_hand?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456

这三行参数是跑通的关键。useUnicode=true&characterEncoding=utf8控制中文不乱码，serverTimezone=Asia/Shanghai解决 MySQL 8 时区报错，driver那行要注意 MySQL 5.x 和 8.x 的驱动类写法不同，后面避坑章会再展开。首次启动时如果 IDEA 右下角报Port 8080 is required，端口被占了，先按第 5 章的方式排查，不要反复点启动键。

第一次点启动后，盯着运行日志看，看到Server startup in [xxx] milliseconds才算真正起成功。很多人习惯先开浏览器访问页面，结果页面打不开才回头看日志，绕了远路。

2.4 数据库导入与连接串参数：先把 MySQL 喂饱

连接配置确认后，导入数据库脚本。先看sql目录下有没有.sql文件，有的话用命令行导入最直接：

mysql -u root -p create database if not exists second_hand default character set utf8mb4; use second_hand; source D:/study/second_hand.sql; show tables;

source后跟绝对路径，Windows 下建议用正斜杠；.sql文件本身得是 UTF-8 编码，如果之前用记事本另存为过 ANSI，导入后中文注释和初始化数据就会变成乱码。导入完成用show tables;能看到至少四五张表，就算成功。用 Navicat 或 DataGrip 导也可以，但注意工具连接默认字符集可能是 latin1，导入前把连接和数据库都切到 utf8mb4。

如果 zip 里没有 sql 文件，也不要慌，翻src下实体类（entity/bean/pojo 包）里的字段名，能反推出表结构。常见做法是实体类字段对应表字段，比如 User 类有userId、userName，那表里就是user_id、username。照实体类补一张建表语句，一样能跑。这一步做完，环境才算闭环：JDK、Tomcat、IDEA、MySQL 四件套版本对齐，数据库里有表有数据。

3. 数据库设计：四张表与订单状态流转，答辩被问得最深的地方

环境跑通只是开始，答辩时老师真正会追问的是数据库设计。二手闲置交易系统和普通电商系统有一个本质区别：发布商品的人不是运营人员，而是普通用户，所以用户表与商品表直接挂钩，订单表里同时存在买家和卖家两个维度。把表结构和状态流转讲透，被问到哪个字段都有话说。

3.1 四张核心表：用户是买家也是卖家，表结构怎么设计

常见做法是把系统拆成用户表、商品表、订单表和留言表四张核心表，外加一个管理员角色字段。各表职责如下：

建表 SQL 大致如下，字段命名可按习惯调整，但逻辑要一致：

CREATE TABLE user_account ( user_id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, phone VARCHAR(20), role TINYINT DEFAULT 0 COMMENT '0 普通用户，1 管理员', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE goods ( goods_id INT PRIMARY KEY AUTO_INCREMENT, seller_id INT NOT NULL, title VARCHAR(100) NOT NULL, price DECIMAL(10,2) NOT NULL, image VARCHAR(255), status TINYINT DEFAULT 0 COMMENT '0 在售，1 已售，2 下架', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_seller FOREIGN KEY (seller_id) REFERENCES user_account(user_id) ); CREATE TABLE trade_order ( order_id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, goods_id INT NOT NULL, buyer_id INT NOT NULL, seller_id INT NOT NULL, status TINYINT DEFAULT 0 COMMENT '0 待付款，1 已完成，2 已取消', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

商品表里seller_id外键指向用户表，这是二手系统与商城系统的分水岭：商品没有「统一库存」概念，每件商品只属于一个卖家，可售数量就是 0 或 1。理解这一点，后面订单表为什么不存商品快照、直接关联 goods_id 就顺理成章了。

DECIMAL(10,2)比FLOAT更适合存价格，避免浮点误差，这是答辩时能主动讲出来的细节，说明不是照抄建表语句。密码字段建议存哈希摘要而不是明文，至少用 MD5，能讲出这点是加分项。留言表结构更简单，核心是goods_id关联商品、sender_id关联用户，展示时一次 JOIN 就能把「谁在什么商品下留了什么言」查出来。

3.2 商品与订单的状态机：用状态位代替物理删除

二手交易里，一件商品的生命周期是「发布 → 在售 → 被下单 → 已售 / 下架」。代码里最忌讳的是成交就把商品记录删掉，正确做法是用status字段做状态流转，因为订单表需要保留商品历史信息，关联查询时不能失联。

订单状态同理，常见状态位设计是：0 待付款，1 已完成，2 已取消。成交动作的 SQL 长这样：

-- 买家下单并支付后 UPDATE goods SET status = 1 WHERE goods_id = ? AND status = 0; UPDATE trade_order SET status = 1, finish_time = NOW() WHERE order_no = ? AND status = 0;

第一行条件里带AND status = 0是乐观锁的写法：同一件商品同时被两个人下单时，只有一个能更新成功，另一个影响行数为 0，代码据此提示「商品已被拍下」。这是很多课程设计源码没有做好的点，也是答辩时老师最容易追问的点——「并发下单怎么办」，用这个 SQL 回答比空谈理论有说服力得多。

商品列表页的核心查询，通常也是一条 JOIN：

SELECT g.title, g.price, u.username AS seller_name FROM goods g JOIN user_account u ON g.seller_id = u.user_id WHERE g.status = 0 ORDER BY g.create_time DESC;

这里能讲出的细节是：只查status = 0的在售商品，已售和下架的不进列表；用JOIN把卖家用户名带出来，前端就不用再发第二次请求。订单表单独建order_no字符串单号而不是直接用自增主键当单号，也是一个能主动说的设计点：自增主键容易暴露真实订单量，单号里带时间戳更像真实业务。

3.3 初始化数据与演示账号：javaweb 项目里 MySQL 数据从哪来

跑通系统后，页面上往往是空的，这时候需要一个初始化数据脚本，插入演示账号和几条商品。这一条直接决定答辩演示是否顺畅。常见初始化脚本是这样一段：

INSERT INTO user_account (username, password, phone, role) VALUES ('admin', MD5('123456'), '13800000000', 1), ('demo_user', MD5('123456'), '13900000000', 0); INSERT INTO goods (seller_id, title, price, image, status) VALUES (2, '九成新机械键盘', 89.00, 'upload/keyboard.jpg', 0), (2, '考研数学复习全书', 25.50, 'upload/math_book.jpg', 2);

注意密码用MD5()函数入库，查询登录时把用户输入的密码做同样 MD5 后比对。如果你拿到的源码是明文存储，建议至少在外层加一层MD5(salt + password)再入库，改动量不大，答辩观感完全不同。演示账号里放一个role=1的管理员，登录后能进后台管理页面，这是演示流程里最不容易出岔子的一条分支，第 6 章的演示脚本会用到。

初始化数据不要贪多，商品三五条足够，最好是「在售、已售、下架」三种状态各至少一条，这样演示订单流转时能直接展示状态变化，不需要现场现造数据。如果发现 sql 文件缺失，可以先把这条 INSERT 语句存成一个init.sql，手动补齐一个 admin 和两条商品，后面所有演示都从这里起步。

4. 源码再厚也不用从头读：沿着登录到下单的主链路走一遍

一个二手交易系统的源码通常有十几个 Servlet 和二十多个 JSP，从头读到尾既不现实也没必要。我一般拿到包会先按一条主链路读：登录 → 商品列表 → 商品详情 → 下单 → 个人中心。这条链路能覆盖 80% 的核心代码，其余模块大多是重复套路。

4.1 主链路：登录 → 商品列表 → 下单 → 个人中心

先在工程里定位每个环节对应哪个 JSP、哪个 Servlet。以传统 Servlet 工程为例，URL 到处理类的映射集中在web.xml里，读它就像读路由表：

grep -n "url-pattern" web/WEB-INF/web.xml

把url-pattern全部列出来，再对照同文件里的<servlet-class>，就能看到每个访问路径落在哪个类上。Spring Boot 工程则直接用@WebServlet("/xxx")注解或@Controller映射，文件位置更好找。

把这张表和 web.xml 对照起来，源码就不再是一堆文件，而是一条可追踪的路径。新手建议从登录开始读，因为会话管理、密码校验都在这一条链路里，读懂了它，后面其他模块都是「读参数 → 调 DAO → 跳页面」的三步结构。搜索功能通常也是一条LIKE查询，注意看是PreparedStatement的?占位，还是字符串直接拼接，后者就是明显的 SQL 注入扣分点，建议答辩前改掉。

4.2 商品发布模块：一段能当模板的 Servlet 代码

商品发布是「写代码」密度最高的模块，也最能看出源码质量。一个典型 Servlet 的写法是这样：

@WebServlet("/goods/add") public class GoodsAddServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setCharacterEncoding("UTF-8"); User user = (User) request.getSession().getAttribute("loginUser"); if (user == null) { response.sendRedirect("login.jsp"); return; } String title = request.getParameter("title"); String priceStr = request.getParameter("price"); String description = request.getParameter("description"); Goods goods = new Goods(); goods.setSellerId(user.getUserId()); goods.setTitle(title); goods.setSellPrice(new BigDecimal(priceStr)); goods.setStatus(0); boolean ok = goodsDao.insert(goods); if (ok) { response.sendRedirect("goods/list"); } else { request.setAttribute("msg", "发布失败，请重试"); request.getRequestDispatcher("publish.jsp").forward(request, response); } } }

这段代码有几处值得照抄的逻辑：第一，业务方法里先做登录校验，拿不到会话对象直接跳登录页，这是所有写操作接口的统一前置条件；第二，商品状态在服务端强制置 0，而不是信任前端传参；第三，价格用BigDecimal接收字符串，避免浮点误差；第四，失败时用forward回原页面并在请求域里放提示语，而不是重定向把错误信息丢掉。

如果源码里的 DAO 用Statement拼接 SQL，改成PreparedStatement的?占位，这就是你在答辩前可以主动修掉的一个明显扣分点。改法很简单：把"SELECT * FROM goods WHERE title = '" + title + "'"改成"SELECT * FROM goods WHERE title = ?"，再用setString(1, title)填参，代码安全性立刻上一个台阶。

4.3 图片上传的实现判断：两代方案，两种排查方式

二手交易系统的商品配图是刚需，而图片上传恰恰是课程设计源码里烂代码的高发区。先判断它用的是哪代技术方案：

以老工程常见的 commons-fileupload 为例，上传后的图片通常被保存到某个磁盘目录，再把相对路径写进goods.image字段。页面显示时用<img src="${goods.image}">拼路径。如果发现图片上传成功但列表页裂图，问题 90% 不在上传代码，而在路径解析，具体排查见第 5 章第 4 条。

新工程建议直接用@MultipartConfig加request.getPart("file")，这是 Servlet 3.0 自带的能力，省掉两个依赖 jar，代码也更短。只要 Tomcat 8 以上就支持。读了图片上传，整条商品发布链路的代码就算读完了，剩下的搜索、分页、留言基本都是同构模板。

5. 常见问题与避坑：本机跑通前的五条血泪经验

课程设计 zip 里的源码本身不一定有问题，跑不起来大多是环境与版本问题。以下五条按出现频率总结，每一条都按「现象 → 原因 → 解决」记录，照着排查即可。

5.1 端口被占：Tomcat 起不来时的第一反应

现象：IDEA 启动 Tomcat 时报Port 8080 is required或Server port 8080 is already in use。原因：本机已有程序占用 8080，常见是之前没关干净的 Tomcat、微信开发者工具或某个本地服务。解决：先查占用进程，Windows 下用命令：

netstat -ano | findstr 8080

把最后一列的 PID 记下来，到任务管理器里结束该进程；如果不确定是什么程序，不要乱杀，直接在conf/server.xml里改端口也行，把<Connector port="8080"改成 8081，同时把 IDEA 里的访问地址同步改掉。macOS 或 Linux 下用lsof -i :8080查看占用。

改端口只是绕路，如果之后还要跑其他课程设计，还是建议把占用 8080 的程序找出来，一次性解决。

注意：改完 server.xml 端口后，IDEA 里 Tomcat 配置的 HTTP port 和浏览器访问地址也要同步改，否则会一直访问旧端口。

5.2 数据源连不上：驱动类与连接串同名不同命

现象：启动后访问页面报Access denied for user 'root'@'localhost'，或者ClassNotFoundException: com.mysql.jdbc.Driver。原因分两类：一是db.properties里的数据库密码与本机 MySQL root 密码不一致；二是 MySQL 驱动和数据库版本不匹配，MySQL 8 之后驱动类从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，老代码里那行驱动类直接失效。

解决：先把 properties 里的用户名密码改成自己的本地账号。改完仍报驱动类找不到，就去WEB-INF/lib里检查mysql-connector-java的版本，5.x 的 jar 配com.mysql.jdbc.Driver，8.x 的 jar 配com.mysql.cj.jdbc.Driver，二者不可以互换。另外 MySQL 8 在连接串缺少serverTimezone参数时会报时区错误，在 URL 末尾追加serverTimezone=Asia/Shanghai即可。

5.3 乱码三兄弟：页面、请求、数据库的三处编码要拉齐

现象：JSP 页面中文显示成★，表单提交到数据库后变成问号，控制台打印中文是乱码。原因：三类编码各自独立，缺一不可——JSP 文件保存编码、HTTP 请求与响应编码、数据库连接编码。

解决：JSP 页面顶部确认有pageEncoding="UTF-8"；Servlet 处理写操作前加一行request.setCharacterEncoding("UTF-8")；数据库连接串保持第 2 章给的useUnicode=true&characterEncoding=utf8；MySQL 表字符集用 utf8mb4。四处置齐后基本不会再有中文问题。

排查时先分清是「显示端乱码」还是「存储端乱码」：直接连 MySQL 查表，如果表里中文正常，是页面渲染或请求编码问题；如果表里已经是问号，是入库前就错了。很多同学在控制台看到乱码就开始改代码，其实只是 IDEA 控制台编码没设成 UTF-8，属于玄学问题，改输出编码就解决。

5.4 图片裂图：上传成功不等于显示成功

现象：商品图片上传成功，文件在磁盘目录里也存在，但页面上<img>裂图。原因：上传路径与访问路径不一致。老项目常把图片保存到D:/upload这样的工程外目录，而 JSP 里<img src="/upload/xxx.jpg">访问的是 Tomcat 部署目录下的 upload 路径，自然找不到。

解决有两类。一类是把上传目录直接改到 webapp 下，简单粗暴但重启后文件容易丢；另一类是给 Tomcat 配虚拟路径，将外部目录映射到/upload：

<Context docBase="D:/upload" path="/upload" reloadable="false"/>

这段配置放在conf/server.xml的<Host>节点内，docBase是真实保存目录，path是浏览器访问路径。配置后需要重启 Tomcat 才能生效。判断源码用的是哪种方案，看上传代码里是File直接写到某个绝对路径，还是把路径拼在项目根目录下。改之前先确认图片到底被写到了哪里，否则配好虚拟路径也照样裂图。

5.5 版本错位：ClassCastException 与 UnsupportedClassVersionError

现象：启动报java.lang.ClassCastException: org.apache.catalina.core.ApplicationHttpRequest cannot be cast to javax.servlet.http.HttpServletRequestWrapper，或直接UnsupportedClassVersionError。原因：前者是 Tomcat lib 下出现了多个 servlet-api 版本，工程WEB-INF/lib里也带了一份，两个类加载器同时加载同名类就对不上；后者是编译 JDK 高于运行 JDK。

解决：删掉工程 lib 里多余的servlet-api.jar和jsp-api.jar，Tomcat 自带的就够了，这是老项目最常见的一种 jar 冲突。找重复 jar 的办法是先ls一下WEB-INF/lib，看有没有两个 servlet 相关 jar，删掉其中一份再重启。版本错位则按第 2 章第 2 节的表格把编译与运行统一。改完记得把 IDEA 里 Project SDK 与 Tomcat 配置的 JRE 指向同一路径，两个设置分开调没用，必须一致。

6. 答辩前夜：把「能跑」变成「能讲」

把「能跑」变成「能讲」，靠的不是临时加功能，而是一条可信的演示链路，加上临场答追问的底气。

6.1 演示链路与数据准备

先把演示数据准备齐：管理员账号、普通用户账号、在售 / 已售 / 下架三种状态的商品各一两条、一笔待支付订单。演示顺序建议固定为：管理员登录 → 后台看用户列表 → 普通用户注册 → 发布一件新商品 → 列表页搜索到它 → 点开详情 → 模拟下单 → 订单状态变为已完成。每一步都对应一个数据表的变化，讲的时候顺手把 SQL 状态流转说出来，老师会明显感觉到你是真读过代码的。

6.2 追问应对与改造方向

老师爱问的三个问题提前想好答案：为什么用状态位、并发下单怎么办、密码怎么存的。分别对应第 3 章的状态机、乐观锁更新和 MD5 摘要。如果还有余力，把项目往毕设方向改，最省力的三处是：商品列表加分页LIMIT、上传改 Servlet 3.0、登录密码加盐。我的教训是：当年交课程设计前没重新导数据库，答辩现场首页直接报连接失败，后来每场演示前我都先跑一遍初始化脚本并走通主链路，多花五分钟，少丢一次人。这条习惯也送给你，希望帮到你。

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