每年毕业季后台都收到类似的问题："我选了宠物猫狗商业系统的毕业设计，要求用jsp基于javaweb实现，现在不知道从哪里开始。"这题目确实是JavaWeb方向出勤率最高的选题之一。原因很简单——宠物交易这个业务场景，把电商系统最核心的注册登录、商品展示、购物车、下单、后台管理完整串了一遍，但又不像大型电商那样必须处理分布式、支付网关这些复杂内容。难度恰好卡在"做得完、讲得清、展得出"的位置上。

这几年我前后带过不少选这个题目的学生，也帮人改过好几个类似系统，今天的文章就围绕"jsp基于javaweb的宠物猫狗商业系统"这个题目，把选题评估、技术选型、数据库设计、核心编码、答辩应对完整捋一遍。每一处都会解释"为什么这样做"，既方便你照着落地，也方便答辩时把设计理由讲明白。文章适合正在做毕设的在校生，也适合想快速了解传统JavaWeb项目结构的开发者参考。

1. 选题价值与"商业系统"的复杂度平衡点

1.1 为什么这个题是JavaWeb毕设里的安全牌

判断一个毕设题目好不好，我习惯看三个维度：知识覆盖度、业务完整度和开发工作量。宠物猫狗商业系统在这三项上都表现得很稳。

从知识覆盖度看，它几乎把高校JavaWeb课程的核心考点全部覆盖：JSP页面渲染、Servlet请求处理、JavaBean数据封装、JDBC数据访问、Session会话管理、Filter过滤器、分页查询、文件上传（宠物图片）。评委不管问哪一块，你都有对应的代码可以指出来。

从业务完整度看，"商业"二字决定了系统不是简单的增删改查展示。它需要完成一个完整的交易闭环：

• 前台用户：注册登录→浏览分类（猫/狗）→搜索宠物→查看详情→加入购物车→生成订单→模拟支付→查看订单状态
• 后台管理员：登录→管理宠物分类→管理宠物商品（含图片上传）→处理订单状态→管理用户→发布公告

这套流程跑通后，系统的逻辑完整性、数据表之间的关联性都经得起推敲，不会出现"功能看着多，实际上各模块毫无关系"的硬伤。

从开发工作量看，纯JSP+Servlet+JDBC的项目，核心代码量一般在3000到5000行，单人三周到五周可以完成。不像Spring Cloud那种动辄十几个微服务的架构，做不完也讲不透。

1.2 业务闭环拆解：前台与后台各需要什么功能

动手写代码前，先把功能清单列清楚，这是所有后续开发的地基。我一般建议学生用一张表格梳理功能点，防止做一半发现漏模块。

这里有一个容易被忽略的点：为什么前台的"查看商品详情"和后台的"商品管理"要拆成两个页面？因为前台页面偏展示，强调排版和购买按钮；后台页面偏操作，强调表单和状态切换。很多学生图省事共用页面，结果答辩时被问"前后台页面如何复用和隔离"就答不上来。

2. 技术栈取舍：JSP+Servlet组合的真实理由

2.1 不赶Spring Boot潮流，不等于技术落后

现在很多学生一上来就问："老师，能不能直接用Spring Boot？现在公司都这么用。"我的回答通常是：如果学校开题时明确写了"基于JSP的JavaWeb项目"，那你就老老实实按题目要求做。这背后有几个现实原因。

第一，课程体系决定了知识边界。很多高校的JavaWeb课程大纲就是Servlet+JSP+JDBC，评委老师评审时习惯用这套知识体系去提问。你用了Spring Boot，某些年龄较大的评委反而不知道从哪里问起，结果问题集中到框架原理上，难度反而更大。

第二，传统JavaWeb更适合理解底层机制。Servlet的生命周期、Session的存储位置、请求到响应的完整路径，这些在Spring Boot里被大量封装后你感知不到，但恰恰是答辩高频考点。用纯Servlet做一遍，你对HTTP请求和JavaWeb运行机制的理解深度完全不一样。

第三，部署演示成本低。一个WAR包丢进Tomcat的webapps目录就能跑，不需要Maven仓库拉一堆依赖，不用处理各种自动配置冲突。对毕设演示和老师验收来说，这种"朴素但可控"的形态反而是优势。

如果学校允许自由选型，那用Spring Boot当然也可以，但你要确认开题报告里的题目名称能不能跟着改。既然题目写了"jsp基于javaweb"，稳妥路线就是JSP+Servlet+JDBC/DBUtils+MySQL，前端页面用JSP内嵌标签加上原生CSS和少量JavaScript。

2.2 MVC分层与项目目录结构规划

哪怕是个几百人用的教学系统，代码也要分层。MVC是JavaWeb的标准套路：JSP负责视图展示，Servlet负责控制器逻辑，JavaBean负责数据模型，DAO类负责数据库操作。很多同学把SQL直接写在Servlet里，项目确实能跑，但答辩时被问到"你用了什么设计模式""职责如何划分"就词穷了。

一个比较标准的目录结构长这样：

src/ ├── com.pet.entity // 实体类：User、Category、Pet、Cart、Order、OrderItem ├── com.pet.dao // 数据访问层：PetDao、UserDao、OrderDao等 ├── com.pet.service // 业务逻辑层：处理下单事务、库存校验 ├── com.pet.servlet // 控制器：LoginServlet、PetServlet、OrderServlet等 ├── com.pet.filter // 过滤器：登录拦截、编码处理 └── com.pet.util // 工具类：DBUtil、MD5Util、PageBean web/ ├── front/ // 前台页面：index.jsp、login.jsp、cart.jsp、order.jsp ├── admin/ // 后台页面：admin_index.jsp、pet_list.jsp等 ├── upload/ // 宠物图片上传目录 └── WEB-INF/ ├── web.xml └── lib/

为什么要单独抽一个service层？因为"下单"这个操作不只是往订单表插一行数据，还涉及库存扣减、购物车清空、订单项生成，这些操作必须在同一个事务里完成，事务控制放在service层最合适。DAO层只负责单表的基础SQL操作，Servlet只负责接收参数和跳转页面，各司其职，评委看到这样的结构会明显加分。

3. 数据库建模：六张表撑起整个宠物买卖闭环

3.1 核心表结构与字段设计

宠物商业系统的数据库不需要很复杂，六张表足够：用户表、宠物分类表、宠物商品表、购物车表、订单表、订单项表。下面把每张表的字段拆开看，并解释字段设计的原因。

用户表（t_user）：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(50), phone VARCHAR(20), email VARCHAR(100), address VARCHAR(255), status INT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

密码字段用VARCHAR(64)是因为MD5加密后的字符串固定是32位，考虑到后期可能升级SHA-256，预留64位长度。status字段用1表示正常，0表示禁用，方便管理员控制用户登录权限。

宠物商品表（t_pet）是核心表，字段设计直接影响页面展示：

CREATE TABLE t_pet ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, name VARCHAR(100) NOT NULL, breed VARCHAR(50), price DECIMAL(10,2) NOT NULL, stock INT DEFAULT 0, image VARCHAR(255), description TEXT, sales INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (category_id) REFERENCES t_category(id) );

这里有一个重要的选择：价格字段绝不能使用FLOAT或DOUBLE。浮点数在二进制环境中无法精确表达，计算总价时会出现0.1+0.2不等于0.3的经典问题。DECIMAL(10,2)是标准的金额类型，10位整数加2位小数，完全够用。

订单和订单项为什么拆两张表？因为一个订单可能包含多只宠物，比如用户同时下单一只英短和一只金毛。如果把宠物信息直接冗余在订单表里，一个订单就得存多行，然后订单头信息和每行商品信息混在一起，状态维护会非常痛苦。正确的做法是订单表存交易头信息（谁买的、总额、状态、收货地址），订单项表存商品明细（买了哪只宠物、单价、数量）。

CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status INT DEFAULT 0, receiver_name VARCHAR(50), receiver_phone VARCHAR(20), receiver_address VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, pet_id INT NOT NULL, pet_name VARCHAR(100), pet_price DECIMAL(10,2), quantity INT DEFAULT 1, FOREIGN KEY (order_id) REFERENCES t_order(id) );

3.2 表关系与关键字段设计的三个细节

第一，购物车表是用户和商品的"中间关系表"，本质上记录的是"谁选了哪个商品、数量是多少"。最简单的设计只需要三个字段：user_id、pet_id、quantity，再加一个主键id。不需要记录价格快照，因为加入购物车时价格还没锁定，最终价格以下单时为准。

第二，订单项表里保存了pet_name和pet_price两个冗余字段。这是有意的设计决策——商品表里的价格和管理员可能会改，但订单一旦生成，用户看到的应该是购买那一刻的价格。所以下单时必须把商品名称、单价快照复制到订单项表里，之后商品改价不影响历史订单。这个细节在答辩时很容易被问，答上来就是加分项。

第三，image字段保存相对路径而不是URL。很多学生把图片上传后的完整路径写进数据库，一旦项目换电脑部署，路径就失效了。正确的做法是只保存类似"upload/20240516/123.jpg"的相对路径，页面显示时通过basePath拼完整访问地址。这样整个项目可以随意移植，图片目录拷过去就能用。

4. 核心编码落地：登录、商品检索与下单闭环

4.1 登录鉴权：PreparedStatement与过滤器拦截

登录是每个商业系统的入口，也是安全问题最容易翻车的地方。我见过太多学生直接用Statement拼接SQL：

// 错误示例，切勿模仿 String sql = "SELECT * FROM t_user WHERE username='" + username + "' AND password='" + password + "'";

这种写法最大的问题是SQL注入。用户在用户名输入框填' or '1'='1，拼接出来的SQL条件永远成立，直接绕过登录。虽然毕设系统不面对真实攻击，但答辩老师问到安全问题时，这行代码就是硬伤。正确写法是用PreparedStatement预编译：

String sql = "SELECT * FROM t_user WHERE username=? AND password=?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, md5(password)); ResultSet rs = ps.executeQuery();

密码存储也不能用明文。数据库里保存的是MD5加密后的字符串，用户注册时把输入密码MD5加密再入库，登录时同样加密后比对。这里要说明一点：现在生产环境确实已经不用MD5做密码存储了，而是用BCrypt这类加盐算法，但JavaWeb毕设范围内MD5是普遍接受的方案，答辩时可以主动提一句"生产环境会升级为加盐哈希"，反而显得你有工程视野。

登录后把用户对象放进Session：

HttpSession session = request.getSession(); session.setAttribute("user", user);

然后通过Filter拦截受保护页面。前台除了登录页、注册页、商品列表页，其余页面都要求登录后才能访问；后台则要求管理员身份。过滤器逻辑比较简单：

public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); String uri = request.getRequestURI(); if (session == null || session.getAttribute("user") == null) { if (uri.contains("login") || uri.contains("register") || uri.contains("index") || uri.contains("pet")) { chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/front/login.jsp"); } } else { chain.doFilter(req, resp); } } }

注意判断条件是白名单思路，即"允许匿名访问的页面列表"，而不是黑名单。白名单更安全，后续新增页面时默认是受保护的，不容易遗漏。

4.2 商品分页检索的实现思路

宠物商品的展示是整个前台的门面。首页按分类展示猫咪和狗狗，点击分类进入列表页，支持按品种名称搜索。数据量少的时候全表查询没问题，但一旦商品上百条，分页就是必修课。

分页的核心参数是四个：当前页currentPage、每页条数pageSize、总记录数totalCount、总页数totalPage。计算逻辑：

int pageSize = 8; int totalCount = petDao.count(categoryId, keyword); int totalPage = (int) Math.ceil(totalCount * 1.0 / pageSize); int currentPage = (request.getParameter("page") == null) ? 1 : Integer.parseInt(request.getParameter("page")); if (currentPage > totalPage) currentPage = totalPage; int offset = (currentPage - 1) * pageSize;

SQL层面对应的分页查询：

String sql = "SELECT * FROM t_pet WHERE 1=1"; if (categoryId != null) { sql += " AND category_id=?"; } if (keyword != null && !keyword.isEmpty()) { sql += " AND name LIKE ?"; } sql += " ORDER BY create_time DESC LIMIT ?,?";

SQL里拼条件时先写WHERE 1=1是为了方便后续动态追加AND条件，虽然性能上不影响这种小数据量场景，但代码可读性和扩展性更好。参数占位符同样使用PreparedStatement传参，避免注入。

页面底部分页导航需要展示上一页、下一页和页码数字。页码数字过多时只显示当前页附近的页码，比如总共20页，只显示1、2、...、当前页附近几页、...、20，这个逻辑可以封装成PageBean工具类，前后台都能复用。

4.3 购物车与订单生成：事务是底线

购物车的实现有两条路线。一条是纯Session购物车，把购物车对象放在Session里，实现简单，但刷新页面、换浏览器数据就丢失，且无法实现"把购物车保存到数据库"的完整商业语义。另一条是把购物车落库，每次添加、修改、删除都操作t_cart表。毕设系统我建议选第二种，因为答辩时"购物车数据会丢失"这种问题一旦被问穿，很被动。

加入购物车的Servlet逻辑：

int petId = Integer.parseInt(request.getParameter("petId")); int userId = ((User) session.getAttribute("user")).getId(); // 先查购物车是否已存在该商品 Cart cartItem = cartDao.findByUserIdAndPetId(userId, petId); if (cartItem == null) { cartDao.add(new Cart(userId, petId, 1)); } else { cartItem.setQuantity(cartItem.getQuantity() + 1); cartDao.update(cartItem); }

下单是整个系统最复杂的逻辑，因为它涉及多个表的写入，任何一步失败都可能导致数据不一致。来看核心代码骨架：

Connection conn = DBUtil.getConnection(); conn.setAutoCommit(false); try { // 1. 插入订单头，获取订单ID String orderNo = "PO" + System.currentTimeMillis() + userId; int orderId = orderDao.insert(conn, orderNo, userId, totalAmount, address); // 2. 遍历购物车，逐项插入订单项表 List<Cart> cartList = cartDao.findByUserId(userId); for (Cart cart : cartList) { Pet pet = petDao.findById(cart.getPetId()); // 3. 库存校验 if (pet.getStock() < cart.getQuantity()) { throw new RuntimeException("商品[" + pet.getName() + "]库存不足"); } orderItemDao.insert(conn, orderId, pet.getId(), pet.getName(), pet.getPrice(), cart.getQuantity()); // 4. 扣减库存 petDao.deductStock(conn, pet.getId(), cart.getQuantity()); } // 5. 清空购物车 cartDao.clearByUserId(conn, userId); conn.commit(); } catch (Exception e) { conn.rollback(); throw e; } finally { DBUtil.close(conn); }

为什么要手动管理事务？因为想要的效果是"要么全部成功，要么全部失败"。如果第3步插入订单项成功但第4步库存扣减失败，数据库就处于一个矛盾状态：订单有了，库存没扣。JDBC默认是自动提交模式，每条SQL单独成事务，必须通过setAutoCommit(false)关闭自动提交，最后统一commit。

关于库存超卖的问题，我会建议学生在代码层面做一次校验：查库存、比对数量、然后扣减。虽然这套逻辑在并发场景下仍然可能超卖（两个用户同时看到库存2然后各买2只），但对于毕设系统，单用户演示场景下已经足够。想在答辩时加分，可以主动说"更严谨的方案是用数据库乐观锁UPDATE ... WHERE stock>=quantity，受影响行数为0则说明库存不足"，这一句就能让评委看出你思考过并发问题。

模拟支付环节不需要对接支付宝或微信。用户下单后点击"去支付"按钮，实质就是把订单status从0改成1，前端文案显示"待发货"。这样的做法完全符合毕设要求，也避免了证书、回调URL等一堆接入问题。

5. 从开发到答辩：常见坑位与高频追问

5.1 开发期最容易翻车的四类问题

第一，中文乱码。JSP页面顶部没有设置<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8"%>，Servlet读取request参数前没有执行request.setCharacterEncoding("UTF-8")，数据库连接URL没加characterEncoding=utf8，三处中任何一处遗漏都会导致中文变问号。建议从源头统一：项目默认编码设为UTF-8，同时配置一个CharacterEncodingFilter统一设置请求编码，数据库URL补齐参数。

第二，图片上传后访问不到。Tomcat默认只映射Web应用目录内的资源，如果你把图片传到了项目外的物理路径，浏览器显示不出来。简单做法：图片统一存到项目的upload目录，并在web.xml或Tomcat配置中声明路径映射。演示拷贝项目时记得把upload目录一起拷贝。

第三，Servlet路径冲突。用注解@WebServlet("/pet")配了Servlet，又想在web.xml里配同样的url-pattern，启动时直接报错。建议统一用一种方式：新项目用注解，老工程用web.xml，不要混用。

第四，JSTL标签库页面里没反应。JSP页面用了<c:forEach>循环，但WEB-INF/lib里没放jstl.jar和standard.jar，运行时会报错TLE找不到。排查这类问题先看控制台完整报错信息，再检查lib目录，比到处猜快得多。

对了，还有一个小坑：下载的JDBC驱动jar包版本和Tomcat版本有兼容性问题时，启动不报错但首次查询会报ClassNotFoundException。建议直接用mysql-connector-java 5.1.49配MySQL 5.7，这对大部分毕设环境是稳定组合。

5.2 答辩演示顺序与提问应答框架

演示环节我给学生的建议是"先快后慢"。开场快速走完整个商业闭环：用户注册→登录→浏览猫咪列表→搜索"英短"→看详情→加购物车→下单→支付→管理员后台看到新订单→发货→用户端看到发货状态。这一套流程两分钟内走完，让评委先对整个系统形成完整认知。

然后再回头演示细节模块：后台商品管理（新增一只宠物，上传图片）、用户管理（禁用某个账号）、统计功能（商品销售量排行）。细节演示时配上讲解，比如"新增商品时库存默认为0，管理员可以手动调整"，展示你对业务细节的考虑。

评委高频问题我整理了几个，你提前打个腹稿：

• 为什么用JSP+Servlet而不用Spring Boot？强调课程要求、底层机制清晰、部署简单，以及踩过Spring Boot配置坑的对比体验，切忌说"因为我只会这个"。
• 密码是明文存储的吗？回答：MD5加密存储，并主动补充生产环境应使用加盐哈希算法。
• 订单状态是如何管理的？回答：用int类型状态码0待付款、1待发货、2已发货、3已完成、4已取消，比字符串状态更节省空间也便于扩展。
• 如果同一时间很多人同时购买同一只宠物，怎么处理库存？按前面说的乐观锁方案回答。
• 你的系统有哪些安全性考虑？登录防SQL注入（PreparedStatement）、访问控制（Filter）、密码加密存储、XSS方面限制用户输入长度和过滤特殊字符。

5.3 论文与设计文档的匹配度

最后一类问题出在论文和系统不一致上。有些学生的系统增加了说明书里没写的表，或者论文里画了数据库ER图，实际数据库里根本没有那张表。答辩前务必逐项核对：论文里的功能清单、ER图、核心代码片段、测试用例，必须和系统实际表现完全一致。这是很多答辩被挂的直接原因，不是技术做不出来，而是"文不对题"。

我个人带项目的习惯是，让学生在论文的实验与测试部分，用表格记录每个功能模块的测试用例和测试结果。比如"添加购物车：输入用户A、宠物ID=5、数量1，预期结果为购物车新增一条记录，实际结果一致"。这种表格写到五到八条，评审看着省心，你答辩时也能迅速找到对应系统页面做复现。

这里再分享一个实战技巧：正式答辩前一天，把部署好的项目完整跑一遍，然后重启Tomcat再跑一遍。为什么？因为很多学生在部署演示时遇到的"明明本地能跑为什么演示时挂了"，都是因为数据库连接串用了localhost而非127.0.0.1、或者Tomcat和IDE绑定的项目路径不同这类环境问题。提前把重启后的完整流程验证一遍，可以过滤掉绝大多数这类尴尬。