★ FEATURED ARTICLE 简介一份基于Java EE的二手图书交易平台课程设计项目面向需要完成期末大作业或课程设计的计算机专业学生也可作为Java Web入门实战参考。项目包含完整源码与配套报告代码注释清晰下载部署后即可运行覆盖图书发布、浏览、交易订单等核心流程前端界面基于Bootstrap构建风格简洁易用。资源共173个文件以Java源码、JSP页面、HTML/CSS/JS前端文件为主另有SQL数据库脚本、XML配置及项目报告文档jpg截图可辅助查看页面效果整体25.68MB结构紧凑便于本地调试。目前已有132人浏览学习适合想直接获取可运行项目并参考高分报告写法的人群。通过该资源能快速理清Java EE分层开发思路掌握二手交易平台的表结构设计与页面交互实现对完成课程设计或应对答辩有实际帮助。1. 二手图书交易平台为什么选 JavaEE 而不是直接套 SSM又到期末很多同学都在为课程设计选题发愁。管理系统做过的人太多商城又偏重真正能把买卖双方 管理员 订单状态讲清楚、又能用 JAVA 语言完整落地的题目基于 javaEE 的二手图书交易平台是一个性价比很高的选择。它没有复杂的支付和物流却保留了交易系统最核心的角色划分、发布流程和状态流转非常契合期末大作业和课程设计的评分点分布。但项目本身有一个反直觉的选型点越基础的 JavaEE 方案反而越容易拿高分。传统 Servlet JSP JDBC 的组合虽然看起来不如 SSM 新潮但每一步都是自己写的答辩时可以讲清楚的地方反而更多。很多同学会陷入一个误区觉得用了框架显得高级加了 Maven 显得专业。但在真实评审场景里评委最关心的是你知不知道每一行代码在干什么。如果引入 SSM 之后自己连 SqlSession 怎么关闭都说不明白那框架反而成了扣分点。这套基于 javaEE 的方案技术栈是 Servlet JSP JDBC MySQL前端用 Bootstrap 搭界面所有代码都有注释部署也简单适合两类人一类是想把课程设计稳扎稳打做完的学生另一类是想快速拿到一套完整可改的期末大作业资源的开发者。这套方案要解决的核心问题是图书从哪里来、谁来审核、买家怎么下单、订单状态怎么流转、卖家怎么确认发货和完成交易。围绕这个主线我会从需求设计、表结构、代码实现到验收答辩完整过一遍。下面直接进入正题。2. 需求分析与系统设计四个角色与六张表的职责划分2.1 业务场景与角色边界二手图书交易去掉所有装饰核心就两件事发布与购买。发布的人要能上传图书信息、管理自己的在售列表购买的人要能浏览、搜索、下单、确认收货平台方则要管审核和用户状态。整个过程涉及四种角色游客、买家、卖家、管理员。游客可以浏览和搜索图书但下单必须注册登录一个注册用户既是买家也是卖家可以发布自己的闲置书管理员负责图书审核和用户禁用不直接参与交易。角色边界一定要在系统设计阶段就划清楚。很多课程设计翻车就是因为把游客和注册用户混在一起导致后续每个功能都要写权限判断越写越乱。我的做法是在表结构设计时直接用user_role字段区分普通用户和管理员用book_status控制图书的上下架审核状态下单的前置校验都统一在一个拦截器里做。这样到写代码时每个 Servlet 只需要关心自己的业务逻辑不需要重复判断这个人能不能干这件事。2.2 功能模块划分与页面流转整个平台按功能拆成五个模块用户模块、图书模块、订单模块、留言模块、后台管理模块。用户模块负责注册登录和个人信息维护图书模块负责发布、列表展示、搜索和详情查看订单模块是整个系统的核心从下单到确认收货有完整状态留言模块解决买卖双方在线沟通后台管理模块是管理员的前置功能集合包括图书审核和用户管理。图书发布是买家变卖家的分界线。未登录用户看到图书详情页上的立即购买按钮点击后跳转登录页而不是直接下单这是一个很关键的交互设计。图书列表按发布时间倒序排列搜索支持书名和作者模糊匹配搜索结果仍然分页展示。每个用户的个人中心都有我发布的图书和我买到的图书两个入口前者管理在售状态后者查看订单流转。2.3 数据库设计订单状态用 int 不用字符串表结构是这套方案里最值得借鉴的部分也是启动项目时第一个要落地的内容。核心表一共六张用户表、图书表、订单表、留言表、图书分类表、管理员操作日志表。下面我把最重要的两张表结构贴出来后面所有代码都围绕它们写。CREATE TABLE book ( id int(11) NOT NULL AUTO_INCREMENT, title varchar(100) NOT NULL COMMENT 书名, author varchar(50) DEFAULT NULL COMMENT 作者, publisher varchar(80) DEFAULT NULL COMMENT 出版社, price decimal(10,2) NOT NULL COMMENT 售价, original_price decimal(10,2) DEFAULT NULL COMMENT 原价, condition_desc varchar(255) DEFAULT NULL COMMENT 成色描述, cover_image varchar(255) DEFAULT NULL COMMENT 封面图片路径, seller_id int(11) NOT NULL COMMENT 发布者ID, category_id int(11) DEFAULT NULL COMMENT 分类ID, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待审核 1在售 2已售 3下架, view_count int(11) DEFAULT 0 COMMENT 浏览次数, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status字段是整个图书模块的状态机。0 是刚发布待管理员审核1 是审核通过正常在售2 是被下单后标记已售3 是卖家主动下架。这里有一个常见的踩坑点很多人用is_sold布尔值表示是否卖出但一旦图书被驳回或被下架这个布尔值就不够用了。用 tinyint 的四种状态后续做我的发布列表时只需要一条 SQL 按状态分组统计不用拼接多个条件。订单表的设计更需要注意因为订单状态直接关系到交易流程能不能闭环。CREATE TABLE orders ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单编号, book_id int(11) NOT NULL, buyer_id int(11) NOT NULL COMMENT 买家ID, seller_id int(11) NOT NULL COMMENT 卖家ID, price decimal(10,2) NOT NULL COMMENT 成交价, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待确认 1待发货 2已发货 3已完成 4已取消, create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime DEFAULT NULL, ship_time datetime DEFAULT NULL, finish_time datetime DEFAULT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单编号用时间戳加随机数的拼接方式生成不用自增 ID 直接对外展示因为订单号会在页面和沟通消息里反复出现纯数字自增会暴露平台订单量。create_time之后的三个时间字段分别在状态变更时写入这样订单详情页可以直接显示完整的流程时间线。买家下单后订单状态是 0卖家点击确认后变成 1标记发货后变成 2买家确认收货后变成 3。取消操作只允许在状态 0 和 1 时执行状态 2 以后卖家已寄出不能再取消。六张表之间的关联关系很清晰用户表通过seller_id关联图书表图书通过book_id关联订单表订单表同时关联买家与卖家。答辩时画一张简版的 ER 图把这种双向关联讲清楚比堆功能列表更能体现系统设计能力。3. 核心模块实现从图书发布到订单状态流转3.1 图书发布文件上传与状态初始化的衔接图书发布是第一个要实现的完整功能。前端表单包含书名、作者、出版社、售价、原价、成色描述和封面图片。这里有一个细节容易被忽略表单是multipart/form-data类型因为要上传图片所以 Servlet 里不能用传统的request.getParameter()获取普通表单字段必须先用Part接口解析文件再通过getParameter获取其他字段。WebServlet(/book/publish) public class BookPublishServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 只允许登录用户发布 User loginUser (User) req.getSession().getAttribute(loginUser); if (loginUser null) { resp.sendRedirect(login.jsp?redirect/book/publish.jsp); return; } // 解析封面图片 Part coverPart req.getPart(coverImage); String coverPath null; if (coverPart ! null coverPart.getSize() 0) { String fileName System.currentTimeMillis() _ coverPart.getSubmittedFileName(); String realPath getServletContext().getRealPath(/uploads); coverPart.write(realPath File.separator fileName); coverPath uploads/ fileName; } // 组装图书对象状态初始化为0待审核 Book book new Book(); book.setTitle(req.getParameter(title)); book.setAuthor(req.getParameter(author)); book.setPublisher(req.getParameter(publisher)); book.setPrice(new BigDecimal(req.getParameter(price))); book.setOriginalPrice(new BigDecimal(req.getParameter(originalPrice))); book.setConditionDesc(req.getParameter(conditionDesc)); book.setCoverImage(coverPath); book.setSellerId(loginUser.getId()); book.setStatus(0); new BookDao().insert(book); resp.sendRedirect(book/myPublish); } }注意图片上传的路径问题。Part.write()方法写入的是相对当前部署路径的相对路径在 IDEA 里用内置 Tomcat 运行时没问题但如果直接部署到独立的 Tomcat 的 webapps 目录就要注意启动时配置docBase。另外文件名我用时间戳前缀拼接原始文件名避免多人上传同名文件互相覆盖。这是一个很实际的问题课程设计答辩时评委经常盯着图片能不能显示路径写错就崩了。3.2 图书列表与搜索SQL 拼接的分页查询图书列表页是系统的门面也是业务量最大的一个接口。这里我统一用一个支持多条件查询的 DAO 方法前台展示只查status 1的在售图书后台管理查全部。搜索条件用动态 SQL 拼接书名和作者用LIKE模糊匹配分类用精确匹配。public ListBook findBooks(String keyword, Integer categoryId, int page, int pageSize) { StringBuilder sql new StringBuilder( SELECT * FROM book WHERE status 1 ); ListObject params new ArrayList(); if (keyword ! null !keyword.isEmpty()) { sql.append(AND (title LIKE ? OR author LIKE ?) ); params.add(% keyword %); params.add(% keyword %); } if (categoryId ! null categoryId 0) { sql.append(AND category_id ? ); params.add(categoryId); } sql.append(ORDER BY create_time DESC LIMIT ?, ?); params.add((page - 1) * pageSize); params.add(pageSize); return queryList(sql.toString(), params); }用StringBuilder拼接 SQL 时每个条件前面都加了空格结尾这是一个很容易被忽略但很影响正确性的细节。如果不加WHERE status 1和AND title LIKE ?拼在一起就会变成语法错误。另外分页的LIMIT两个参数必须跟着 SQL 一起调整很多人只改了LIMIT的第一个值却忘了把页码换算成起始位置。(page - 1) * pageSize是分页查询的标准写法这个公式要能当场推导出来答辩时会被问到。3.3 下单与库存扣减事务的边界要包住两行代码整个系统里只有两个地方必须用事务一是下单时要同时插入订单记录并更新图书状态为已售二是注册时插入用户初始数据。如果这两步不放在同一个事务里就会产生订单创建了但图书变成已售失败的数据不一致。下面是下单 DAO 的核心方法。public boolean createOrder(Order order) throws SQLException { Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 第一步插入订单记录 String insertOrder INSERT INTO orders(order_no, book_id, buyer_id, seller_id, price) VALUES(?,?,?,?,?); PreparedStatement ps1 conn.prepareStatement(insertOrder); ps1.setString(1, order.getOrderNo()); ps1.setInt(2, order.getBookId()); ps1.setInt(3, order.getBuyerId()); ps1.setInt(4, order.getSellerId()); ps1.setBigDecimal(5, order.getPrice()); ps1.executeUpdate(); // 第二步把图书状态改成已售 String updateBook UPDATE book SET status 2 WHERE id ? AND status 1; PreparedStatement ps2 conn.prepareStatement(updateBook); ps2.setInt(1, order.getBookId()); int rows ps2.executeUpdate(); if (rows 0) { conn.rollback(); // 图书已被别人买走回滚订单 return false; } conn.commit(); return true; } catch (SQLException e) { conn.rollback(); throw e; } finally { DBUtil.close(conn); } }UPDATE book SET status 2 WHERE id ? AND status 1这一行很有价值。它利用AND status 1作为乐观锁同一本图书同时被两个人下单时数据库层面只会有一个 Update 语句影响行数为 1另一个影响行数为 0 从而回滚。相比先SELECT判断再UPDATE这种写法把并发控制成本降到最低。课程设计里不会有人测试高并发但能在答辩时讲出我用条件更新防止超卖这个点是一个很加分的亮点。3.4 Bootstrap 页面整合从样式到交互的落地细节资源包里提供的前端是基于 Bootstrap 的整套页面包括bootstrap.css、bootstrap-theme.css、sweetalert.css等样式文件。这套资源的优势在于页面文件是完整的不需要从零布局。我实际整合时发现最需要花时间的不是写页面而是保证 JSP 里的表单提交路径和 Servlet 的WebServlet映射一致。整合时我一般会统一做三件事。第一公共头部和底部抽成header.jsp和footer.jsp用% include %引入这样导航栏的登录状态切换只需要改一个文件。第二所有操作成功或失败都用 SweetAlert 弹窗提示而不是浏览器原生 alert视觉上会专业很多。第三删除图书、确认发货这类高风险操作统一在按钮上绑定confirm事件避免误点直接改数据。这里有一个很典型的踩坑Bootstrap 的模态框依赖 jQuery而 SweetAlert 2 也依赖窗口的弹层机制如果 JSP 里同时引用了多个版本的 jQuery弹窗会出现点击无响应的情况。我的习惯是在页面底部统一只引入一份 jQuery再引 bootstrap.min.js最后引 sweetalert.js顺序错了后面全都不生效。这不是逻辑问题是资源加载顺序问题但排查起来特别费时间建议一开始就约定好固定顺序。4. 常见问题排查部署失败、中文乱码与状态错乱4.1 部署后页面显示源码Tomcat 没有正确映射 JSP现象项目启动后访问首页浏览器直接显示 JSP 的源码而不是渲染后的页面。原因是部署描述文件里welcome-file配的是index.jsp但项目结构里没有把 JSP 放在 webapp 根目录下或者 Tomcat 根本没有加载 Web 应用。排查命令先检查项目输出目录target里有没有index.jsp和WEB-INF/web.xml然后看 IDAE 的 Artifacts 配置中 exploded 路径是否指对目录。通常的做法是项目右键 Open Module Settings在 Artifacts 里把 output directory 指向 Tomcat 的 web apps 目录。这个问题的解决思路要理清楚不是把源码放到磁盘任意位置就能跑Tomcat 只认 webapp 结构WEB-INF下面必须包含classes和lib。4.2 数据库中文全部变成问号现象启动项目后通过页面注册的用户中文名显示为??图书标题也是乱码。原因一般有两个MySQL 连接串没指定字符集或者 JSP 页面本身是 GBK 编码而数据库是 utf8mb4。解决方式分两层。第一层JDBC 连接串后面必须带?useUnicodetruecharacterEncodingutf8这是缺失的话无论在代码里怎么setCharacterEncoding都没用。第二层进入 MySQL 后SHOW CREATE DATABASE确认数据库是 utf8mb4建表语句里已经用了CHARSETutf8mb4则这部分没有问题。如果页面显示乱码但数据库里正常那是 JSP 的pageEncoding问题每个页面头部要统一写contentTypetext/html; charsetUTF-8。乱码问题的排查思路是逐层缩小范围——先看数据库存储正不正常再看请求参数接收正不正常最后看响应输出正不正常不要一上来就改代码。4.3 图书发布后找不到状态对不对要会查现象用户在发布页填完图书信息提交页面跳转后列表里看不到刚才发布的书以为功能写错了。看代码会发现 insert 执行成功页面也跳到了我的发布但列表按status1查刚发布的图书状态是 0自然查不到。这是状态机设计带来的隐性预期差。待审核的图书只能在自己的个人中心看到管理员在后台看到普通浏览用户在首页看不到这是业务规则不是 bug。但在演示时评委很可能当场发布一本书然后去列表页找找不到就会觉得功能不完整。我的建议是发布成功后直接用 SweetAlert 弹窗提示图书已提交等待管理员审核并给一个查看我的发布的跳转链接把用户的注意力引导到正确的位置。这种预期管理在答辩演示里比功能本身更重要。4.4 订单状态错乱重复点击下订单导致数据不一致现象买家在图书详情页连续点击两次立即购买生成两条订单但一本书只能卖一次。原因在于下单接口没有做防重复提交第二次请求进入时图书状态已经在第一次请求里变成 2已售但因为前端按钮没有禁用第二次请求继续执行创建订单的逻辑。解决方案在前面的createOrder里已经体现了更新图书状态时使用AND status 1条件第二次更新影响行数为 0事务回滚。但前端仍然要配合加一层防护在下单按钮点击后立刻禁用按钮并显示处理中同时 JSP 页面用隐藏字段保存一个随机 token提交时校验 token 是否存在。这两层里后端事务是兜底前端禁用是体验缺一不可。排查这类问题时看订单表里有没有同book_id的多条记录是最快的确认方式。4.5 图片上传后刷新丢失文件保存到了临时目录现象本地部署时图片能正常显示重启 Tomcat 后图片全部失效路径还在但文件找不到。原因是Part.write()在某些开发工具集成的 Tomcat 里会把文件写到临时工作目录重启后目录被清理。解决方法是把上传目录配置成固定的外部路径例如在项目根目录下建一个uploads目录在 ServletContextListener 里启动时检查路径存在不存在就创建。更简单粗暴的做法是上传时把图片 Base64 编码存到数据库字段里但这会膨胀数据库体积只适合封面图很小的情况。考虑到课程设计的数据量很小用固定外部目录是更稳妥的做法而且能现场演示重启后图片仍然在。5. 验收与答辩从功能测试到演示路线的走查清单5.1 功能验收按角色走一遍全流程验收阶段我习惯列一张走查表按角色维度把主干流程过完而不是随机点功能。游客视角检查三件事能否打开首页并看到在售图书、能否搜索到目标书、点击购买时是否跳转登录。注册用户视角检查完整闭环发布图书、退出登录、用另一个账号登录、搜索到这本书、下单、模拟卖家确认发货、切换回买家确认收货。管理员视角检查审核流登录后台看到待审核图书、通过审核、回到前台验证图书出现在列表里。这张表里最容易漏的是退出登录后再试试未授权操作。很多系统功能正常但权限控制有漏洞比如未登录直接访问/book/publish的 Servlet 地址应该被拦截器挡回登录页。验收时用浏览器的隐式窗口分别开两个账号模拟买家卖家的完整交易流比一个人来回切换账号更有说服力也能暴露 Session 覆盖的问题。验收项操作步骤预期结果通过分页搜索搜索Java返回分页结果且页码可切换是重复下单防护连点两次购买只生成一条订单第二次提示已售是权限控制未登录访问发布Servlet跳转登录页是中文输入发布含中文书名的图书列表和详情均正常显示是5.2 答辩路线从亮点出发而不是从登录页开始讲答辩演示不能打开系统就从登录页开始评审在 5 分钟内看不了所有功能时间要留给亮点。我建议的演示顺序是先打开图书列表页讲清楚首页展示的信息和搜索逻辑顺手搜一本书名展示搜索结果。然后进入一本书的详情页这个页面要强调status 1的在售过滤条件和浏览次数的更新机制。接着演示下单流程重点讲订单表里status的完整流转和AND status 1的乐观锁设计这里可以顺势提一句数据一致性通过条件更新和事务共同保证。最后切到管理员页面展示审核功能把刚才发布的书从待审核改成在售再回到前台确认可见。答辩中最常被问到的问题有三个Tomcat 和 JSP 的关系、为什么选 JDBC 而不是 MyBatis、事务是怎么控制的。第一个问题可以用一句话回答Tomcat 是 Servlet 容器JSP 会被编译成 Servlet 执行。第二个问题要坦诚JDBC 代码量更大但每一步都透明可控MyBatis 的话 XML 映射反而增加理解成本。第三个问题直接引用createOrder方法讲清楚 setAutoCommit(false)、commit、rollback 三个方法的分工。5.3 讲清楚代码注释的部署细节演示环境建议用 IDEA 自带 Tomcat不要现场配置独立 Tomcat因为环境问题最容易翻车。启动前检查三处数据库是否已导入建表语句和执行初始化数据、DBUtil里的用户名密码是否匹配本地 MySQL、上传目录是否有写权限。如果现场数据库没起来一切都是白搭。正确流程是启动前五分钟把数据库服务打开确认能连上再启动 Tomcat不要等演示时才发现 MySQL 服务没有启动。那之后我每次做这类项目验收都强制自己走一遍停 MySQL、停 Tomcat、重启、看日志的完整流程直到确认环境不会在关键时刻出问题。这套基于 javaEE 的二手图书交易平台方案代码注释齐全从表结构到状态流转都有现成实现希望这份走查清单和演示路线能帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
