最近把一套课程设计级别的项目从头到尾整理了一遍是一个基于 Java Servlet 的家乡特产推广平台主题选的是贵州织金的砂锅。项目源码编号 32911整套工程包含完整的前台展示、后台管理、数据库脚本和部署说明。这篇文章把项目的技术选型思路、功能拆解、关键代码实现以及部署运行中容易踩的坑全部梳理出来给正在做 JavaWeb 课设、毕业设计或者想用 Servlet 技术做一个小而全的电商类项目的同学参考。织金砂锅这个选题不是随便拍的。它是贵州省织金县的传统手工艺品以当地特有的粘土手工制作透气性好、保温性强还带着非遗属性。用这样一个有地域特色、有故事可讲的产品作为平台主体天然适合做推广型网站。而 Servlet JSP 这套技术栈虽然相比 Spring Boot 显得老派但对于理解 Web 应用底层运行机制来说是绕不开的必经之路。1. 项目概述与技术选型为什么用 Servlet 做特产推广平台1.1 织金砂锅的行业背景与平台定位先聊一下选题本身的逻辑。织金砂锅在贵州本地很有名传统做法是手工捏制再土窑烧成成品带着自然的砂纹理煮汤炖肉的表现比普通金属锅更贴合老传统。但它的销售渠道长期依赖线下集市和口口相传年轻人了解得少外省消费者想买找不到门路。这就是平台存在的核心价值把家乡特产这个大概念落地到一个具体的商品上通过网站展示、分类浏览、在线下单把手艺人和消费者直接连起来。平台定位不是做大而全的电商系统而是做推广 交易兼备的轻量级特产门户。前台强调展示要有吸引人的首页轮播海报、热门商品、产品分类、产品详情页图片、工艺介绍、价格库存、购物车与结算流程后台侧重管理要有商品上下架、订单处理、用户管理和留言维护。这个定位对功能广度和代码复杂度都提出了要求但又没有脱离 Servlet 时代的典型业务模型——MVC 三大件JSP 负责视图、Servlet 负责控制、DAO 负责数据。1.2 Servlet 技术选型的底层逻辑很多同学纠结同一个问题现在企业都在用 Spring Boot为什么课设还在用 Servlet我在实际整理这套源码时反而觉得 Servlet 是这个项目最合适的选择理由有三层。第一层是学习价值。Servlet 是 JavaWeb 的地基它直接让你面对 HTTP 请求的完整生命周期。你自己要写 doGet/doPost、手动处理请求参数、手动控制转发和重定向、管理 Session 生命周期。用一遍 Spring Boot 可能只学会加注解、调接口但用 Servlet 走完一个项目你能讲清楚浏览器输入网址后Tomcat 怎么把请求交给 ServletServlet 怎么拿数据库数据再如何把结果塞回 JSP 页面渲染成 HTML。这套底层认知后面学任何框架都受益。第二层是项目契合度。这个项目的业务复杂度处在一个很舒服的区间用户、商品、购物车、订单、留言一共五六个核心实体Servlet JSP 完全能驾驭不会像用 Spring Boot 那样为了一个小项目引入一堆依赖和自动配置反而增加理解负担。做一个符合课设要求的项目Servlet 足够。第三层是从就业面试角度的考量。面试官看到你会 Servlet 底层原理不会觉得你技术落后反而会认为你有内功面试官如果只看到你用 Spring Boot 写 CRUD反而容易追问框架原理答不上来。这个项目恰好可以作为展示Web 基础的作品。1.3 平台整体功能地图整个平台分为前台用户端和后台管理端两条线顺着用户操作路径梳理功能如下前台核心流程用户访问首页看到轮播图、热卖推荐和品牌故事按分类浏览砂锅商品如炖锅、炒锅、茶具、礼品装进入商品详情页查看图片、详细介绍、价格和库存注册登录购物前需要登录加入购物车调整数量去结算填写收货信息生成订单后台核心流程管理员登录进入后台商品管理新增、编辑、上下架、维护库存订单管理查看订单明细、修改订单状态待付款/已付款/已发货/已完成用户管理查看注册用户列表留言管理处理用户在平台留下的咨询和反馈这套流程覆盖了一个电商类系统最核心的主干逻辑代码量又不至于大到失控学前端的人看 JSP 页面不晕学后端的人看 Servlet 逻辑不吃力。2. 系统架构与数据库建模项目目录、分层设计与核心数据表2.1 标准 MVC 分层与源码目录解剖拿到源码不要急着跑起来第一步是把目录结构看明白。这套源码遵循标准 Maven Web 工程结构也可以直接用 Eclipse Dynamic Web Project 打开核心分层如下com.shaleguo.entity // 实体类User, Product, Category, Cart, Order, Message com.shaleguo.dao // 数据访问层JDBC SQL每个表对应一个 DAO com.shaleguo.service // 业务逻辑层参数校验、业务规则购物车计算、订单生成 com.shaleguo.servlet // 控制层接收请求、调用 service、跳转 JSP com.shaleguo.util // 工具类DBUtil连接池、分页工具、验证码工具 web/WEB-INF/jsp // 视图前台用户页面index, product, cart, order... web/WEB-INF/jsp/admin // 后台管理页面product_list, order_list, user_list... web/css web/js web/images // 静态资源 web/WEB-INF/web.xml // Servlet 映射与欢迎页配置 sql/shaleguo.sql // 数据库初始化脚本这套分层最重要的价值是请求进来后数据的走向清晰。以用户登录为例完整链路是浏览器 POST 到 LoginServlet → Servlet 用 request 拿用户名密码 → 调用 UserService 的 login 方法 → UserService 调 UserDao → UserDao 里是 JDBC 查询代码 → 返回 User 对象 → Servlet 把 User 放进 Session → 重定向到首页。每一层各司其职哪一层出问题都很容易定位这就是 MVC 分层的最大优势。2.2 核心数据表设计详解数据库表设计是整个项目的基石。我打开 sql/shaleguo.sql 看过一共 7 张表命名清晰字段设置比较克制非常适合作为学习模板。各表核心字段和设计意图如下用户表 userid 主键自增username 唯一索引登录名password 密码MD5 加密存储phone, email, address 联系方式用于订单配送reg_time 注册时间商品表 productid 主键category_id 外键关联分类name 商品名称price 单价stock 库存数量image 商品图片路径description 详细描述支持长文本status 上下架状态0 下架 1 上架分类表 categoryid 主键name 分类名称sort 排序权重购物车表 cartid 主键user_id 关联用户product_id 关联商品quantity 购买数量订单表 ordersid 主键order_no 订单编号时间戳 随机数user_id 下单用户total_price 订单总价receiver_name, receiver_phone, receiver_address 收货信息status 订单状态0 待付款 1 已付款 2 已发货 3 已完成create_time 下单时间订单明细表 order_itemid 主键order_id 关联订单product_id 关联商品product_name, product_price 下单时商品快照防止商品改价影响历史订单quantity 数量留言表 messageid 主键user_id 留言用户content 留言内容reply 管理员回复create_time 留言时间这里有两个设计点要特别拿出来说。订单明细表里的商品快照字段product_name、product_price是真实电商系统里非常常规也非常重要的设计。如果只存 product_id当后台修改了商品名称或价格时历史订单显示的内容就全错乱了。快照字段保证了下单那一刻的订单数据不可变这是正规电商的底线逻辑。密码加密存储使用的是 MD5 加盐设计。密码字段不存明文而是存储加密后的散列值。虽然 MD5 在今天的安全性已经不足以应对高强度破解但作为课设项目学习密码不能明文入库的概念完全够用。2.3 前后台统一认证与权限控制思路这个项目的权限控制不复杂但思路值得借鉴用 Session 判断登录状态。前台用户在登录成功后LoginServlet 会把 User 对象放入 request.getSession()。然后所有需要登录才能访问的页面购物车、结算、个人中心在 JSP 页面顶部通过c:if test${empty sessionScope.user}判断未登录则跳转登录页。退出登录的逻辑更简单LogoutServlet 里调用 session.invalidate() 把整个会话失效。后台管理员则是固定账号在 AdminLoginServlet 里直接比对账号密码比对成功后把 admin 标记放入 Session后台所有页面入口都校验这个标记。这种方式虽然简陋但恰好适合课设场景不需要引入 Shiro 或 Spring Security 这种重量级权限框架。3. 核心功能实现与源码拆解登录注册、商品分页、购物车、订单管理3.1 JavaWeb 老生常谈注册登录与中文乱码处理用户注册登录是每个 Web 项目的第一个接口也是第一个坑点。这套源码的 RegisterServlet 处理逻辑很规矩我直接贴核心代码说明// RegisterServlet 的核心逻辑 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // 解决中文乱码请求参数编码必须放在读取参数之前 request.setCharacterEncoding(UTF-8); response.setContentType(text/html;charsetUTF-8); String username request.getParameter(username); String password request.getParameter(password); // 调用业务层做用户名唯一性校验 UserService userService new UserService(); if (userService.isUsernameExists(username)) { request.setAttribute(msg, 用户名已存在); request.getRequestDispatcher(/register.jsp).forward(request, response); return; } User user new User(); user.setUsername(username); user.setPassword(MD5Util.encrypt(password)); userService.register(user); // 注册成功跳转到登录页 response.sendRedirect(request.getContextPath() /login.jsp); }这里有三个细节我在实际调试中反复遇到过逐个说明。第一request.setCharacterEncoding(UTF-8) 这一行必须放在读取 request.getParameter() 之前。很多新手把编码设置写在代码最后导致从表单提交的中文全部变成问号。原因在于 Tomcat 默认使用 ISO-8859-1 解码请求体必须在解析参数前告诉容器用 UTF-8。第二为什么注册完成后用重定向而不是转发这是 PRG 模式的经典应用如果使用 forward 转发到 success.jsp用户刷新页面会再次提交 POST 请求从而重复注册。sendRedirect 让浏览器发一个新 GET 请求就彻底避免了重复提交问题。第三密码绝不能明文存储。源码里用 MD5Util 工具类对密码做了加密。你可以在此基础上再加一层盐比如把用户名作为盐拼进去再加密安全性更好。3.2 商品列表展示与分页查询的实现思路前台商品列表不能一次性把几十上百条记录全查出来必须做分页。这套源码的分页实现是典型的 Servlet 三层式接收页码 → 查总记录数和当前页数据 → 把分页信息转发给 JSP。核心代码在 ProductServlet 中int pageNo 1; int pageSize 8; String pageNoStr request.getParameter(pageNo); if (pageNoStr ! null !pageNoStr.isEmpty()) { pageNo Integer.parseInt(pageNoStr); } ProductDao productDao new ProductDao(); // 查询总数和当前页数据 int totalCount productDao.getCountByCategory(categoryId); ListProduct productList productDao.findByCategoryPage(categoryId, pageNo, pageSize); int totalPage (totalCount pageSize - 1) / pageSize; // 向上取整求总页数 // 分页数据保存到 request 转发给 JSP request.setAttribute(productList, productList); request.setAttribute(pageNo, pageNo); request.setAttribute(totalPage, totalPage); request.getRequestDispatcher(/WEB-INF/jsp/product_list.jsp).forward(request, response);分页里的 SQL 写法值得专门说明。MySQL 的分页语句是LIMIT offset, size其中 offset (pageNo - 1) * pageSize。这段逻辑写在 DAO 层public ListProduct findByPage(int pageNo, int pageSize) { int offset (pageNo - 1) * pageSize; String sql SELECT * FROM product WHERE status1 ORDER BY id DESC LIMIT ?, ?; // 使用 PreparedStatement 占位符防止 SQL 注入 }总页数计算的公式(totalCount pageSize - 1) / pageSize是个常用的取整技巧如果总数是 18、每页 8 条普通除法结果 2.25强转 int 变成 2 会丢掉最后一页的 2 条数据。加上 pageSize-1 再除就能向上取整得到 3这个写法很多教程不会细讲但面试常问。商品列表页还有一个容易被忽略的性能坑不要在 JSP 里循环访问数据库。比如用c:forEach遍历商品并在循环里通过 category_id 查分类名称会产生 N1 查询问题。正确做法是在 DAO 里用JOIN或一次性查出后映射这套源码把分类信息一并查出来放在 Product 对象的 categoryName 字段里是正确示范。3.3 购物车与订单生成Session 临时存储与事务控制落地购物车这个功能的实现方式有几种这套源码用的是 Session 方案购物车数据不落数据库或只有结算时才落而是放在 Session 中的一个 Map 里key 是商品 IDvalue 是购买数量。// 购物车操作核心逻辑简化示例 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session request.getSession(); int productId Integer.parseInt(request.getParameter(productId)); // 从 Session 取购物车 Map 实例 MapInteger, Integer cart (MapInteger, Integer) session.getAttribute(cart); if (cart null) { cart new HashMap(); } // 如果商品已在购物车数量累加 cart.put(productId, cart.getOrDefault(productId, 0) 1); session.setAttribute(cart, cart); response.sendRedirect(request.getContextPath() /cart.jsp); }这个 Session 购物车方案最大的优点是开发简单不用为购物车单独建表维护临时状态最大的缺点在于数据存 Session 里用户关闭浏览器购物车就没了跨设备也不能同步。放在课设场景完全够用但如果你打算扩展成正式项目建议升级为数据库购物车表方案。订单生成是另一个值得深挖的点因为它涉及数据库事务。下单不是一个 SQL 的事而是一个扣库存 生成订单 生成明细 清空购物车的组合操作。任何一个环节失败都不能让数据出现一半成功一半失败的尴尬状态。源码里 OrderServlet 的下单逻辑把事务处理放到了 DAO 层// 订单生成的简化事务流程 public boolean createOrder(Order order, ListCartItem items) { Connection conn DBUtil.getConnection(); try { conn.setAutoCommit(false); // 开启事务 // 1. 插入订单主表 int orderId orderDao.insert(conn, order); // 2. 批量插入订单明细 orderItemDao.batchInsert(conn, orderId, items); // 3. 扣减库存UPDATE product SET stock stock - ? WHERE id ? AND stock ? productDao.deductStock(conn, items); // 4. 清空购物车 conn.commit(); // 全部成功才提交 } catch (Exception e) { conn.rollback(); // 任何异常回滚保证数据一致 } finally { DBUtil.close(conn); } }扣库存的 SQL 特意写成WHERE stock ?这是一个防止超卖的关键细节。在高并发场景下如果不加这个条件两个线程同时读库存 1、同时扣减最后库存会变成负数。加上库存条件后当实际库存不足时 UPDATE 语句影响行数为 0业务层以此判断下单失败从源头堵住超卖。3.4 后台管理的极简实现复用回填与状态流转后台管理这块在课设项目里普遍做得粗但这套源码的思路上有一个值得借鉴的小而不简单设计编辑回填。商品编辑页面通常需要把已存在的商品数据回显到表单。一般做法是页面藏一个隐藏域保存 ID提交时通过 ID 判断是新增还是更新。这套源码在 ProductEditServlet 里是这样处理的int productId Integer.parseInt(request.getParameter(id)); Product product productService.findById(productId); request.setAttribute(product, product); request.getRequestDispatcher(/admin/product_edit.jsp).forward(request, response);然后在 JSP 表单里用 JSTL 把 product 对象的各个属性回填到 input 的 value 中input typetext namename value${product.name} / input typetext nameprice value${product.price} /这个操作本身不难但它是前后端数据交互的典型场景改什么字段、怎么保证修改的是同一条记录、如何防止用户篡改隐藏域 ID这些理解对后面做更复杂的系统都成立。后台的订单状态流转也体现了同样的思路管理页面通过订单号查询当前状态点击按钮走专门的状态更新 Servlet传递目标状态并刷新页面逻辑非常清晰。4. 部署运行与项目落地环境配置、高频报错排查与扩展方向4.1 从源码到本地运行的完整部署流程很多同学下载源码后卡在第一步项目跑不起来。这里我把这套项目从零跑通的完整步骤整理一遍跟着走基本不会出问题。第一步准备环境。JDK 1.8、Tomcat 8.5、MySQL 5.7。注意 MySQL 8.0 也可以但需要修改 JDBC 驱动为 8.0 版本且 URL 加 serverTimezone 参数否则会出现时区报错。第二步导入数据库。打开 Navicat 或命令行执行 sql/shaleguo.sql 脚本自动建库建表并插入初始管理员账号和演示商品数据。数据库名一般为 shaleguo默认用户名 root密码 root。第三步修改数据库连接配置。在 src 下的 db.properties 中加入jdbc.urljdbc:mysql://localhost:3306/shaleguo?useUnicodetruecharacterEncodingUTF-8 jdbc.usernameroot jdbc.passwordroot注意 URL 里的 characterEncodingUTF-8 参数不能省略它能保证数据库返回的中文不乱码。第四步发布到 Tomcat。IDEA 中配置好 Tomcat直接 RunEclipse 中右键项目 Run As → Run on Server。启动成功后访问 http://localhost:8080/shaleguo/ 即可看到首页。4.2 高频报错实录与排查方法论我把运行这套源码最常见的四类报错整理成表每个都是真实踩过坑后总结的经验。报错现象根本原因解决方案访问页面 404项目没有被正确部署到 Tomcat 的 webapps 目录检查 Tomcat 配置中的 Deployment确认 artifact 已添加访问路径检查是否是 /项目名/控制台报 ClassNotFoundException: com.mysql.jdbc.DriverMySQL 驱动 jar 包没有放到 WEB-INF/lib 目录下载 mysql-connector-java 对应版本放进去IDEA 中注意 Add as Library页面中文全部变成问号Tomcat 默认解码 ISO-8859-1确认 JSP 页面顶部的 pageEncoding 是 UTF-8Servlet 中 setCharacterEncoding 必须在使用参数前调用登录后刷新页面提示数据重复注册或登录后用了 forward 转发到页面改为 sendRedirect 重定向遵循 PRG 模式还有一类非常隐蔽的坑每次启动 Tomcat 时端口被占用。排查方法是在命令行敲 netstat -ano | findstr 8080找到占用进程后杀掉或者直接改 Tomcat 的 server.xml 端口。4.3 从课设到完整的演变路径源码本身是一个标准的课设项目但如果想在这个基础上继续演进有几个扩展方向非常值得投入精力。如果在不换 Servlet 技术栈的前提下可以优先完善三点数据库连接改用连接池Druid 或 C3P0解决每次请求都新建数据库连接的性能浪费前端做响应式适配让手机端也能流畅浏览购物增加文件上传功能把商品图片从固定路径改为管理员动态上传。如果想往企业级方向走可以照葫芦画瓢改造成 Spring BootServlet 对应 Controller、JSP 对应 Thymeleaf、DAO 对应 MyBatis。技术换了但 MVC 的思想、业务模块的划分、数据库表结构基本可以原样保留。换句话说这套 Servlet 源码不仅仅是一份课设代码更是理解整个 JavaWeb 技术体系的活教材。根据我自己前前后后跑过的多套课设源码的经验Servlet 项目的核心价值从来不在代码量而在于它强迫你直面 Web 开发最本质的问题请求怎么进来、怎么处理、怎么响应。把这套织金砂锅项目的 Servlet 流程吃透后面不管是学 SSM 还是 Spring Boot都是顺手的事。尤其是购物车加事务处理那一段代码建议多看几遍它几乎是所有电商类项目后端逻辑的原型。如果你正在找一套既能过课设又能提升底层理解的 JavaWeb 项目从这个织金砂锅平台源码入手通常不会走弯路。