JSP+Servlet+MySQL超市管理系统：从环境部署到二次开发全流程解析

简介：面向计算机专业本科毕业设计及课程设计场景的JSP超市管理系统完整资料包，围绕“源码+数据库+说明文档”三件套组织，帮助毕业生快速掌握基于JSP、Servlet、MySQL与Tomcat的经典Web开发模式，解决选题后无从下手、系统实现不完整、论文结构不规范等痛点。压缩包约4.13MB，核心内容为Java项目源代码、SQL数据库脚本、论文目录齐全的Word说明文档；论文章节覆盖系统分析、可行性分析、需求分析、数据流图与数据字典、概要设计、软件模块结构设计、数据库E-R图、数据库逻辑设计与实现、程序流程图及软硬件配置方案，并专门介绍了JSP、MySQL、Tomcat、JavaScript等开发工具和系统关联图的绘制方式，从业务建模到编码实现形成完整闭环。读者可将项目导入IDE并配置数据库后直接运行，也可参考各模块划分、数据表结构与论文框架完成二次开发和毕业设计撰写。目前已有161人学习下载，适合需要高质量毕业设计成品，或希望按规范流程系统学习JSP+MySQL开发的中级学习者。

1. JSP 超市管理系统毕设资源：一份能直接跑起来的传统 Java Web 全流程样本

每年毕设季都会有人问到同一类问题：老师要求做一个管理系统，技术栈限制在 JSP + Servlet + MySQL，还不能用 Spring Boot 糊弄过去。这份 JSP 超市管理系统资源恰好是这种项目的完整样本，源码、数据库脚本、说明文档三件套齐全，论文目录从第二章系统分析一直覆盖到第五章详细设计，对应到代码里就是一套标准的三层结构：JSP 做展示层，Servlet 做控制层，DAO 直接操作 MySQL。它不是微服务、不是前后端分离，但正因如此，它才是理解 Java Web 请求流转的最佳教材。适合三类人：需要交毕业设计的本科生、想快速找回传统 JSP 开发手感的从业者，以及想拿现成骨架做二次开发的初学者。这份资源的价值在于论文和技术实现能一一对上，改写和答辩都有的放矢。

2. 先读论文目录再看代码：从系统分析反推模块与数据结构

拿到资源别急着开 IDE，先把论文目录过一遍。这一章的目录信息量很大：第二章系统分析里有可行性分析，第三章需求分析里有业务流程、数据流图和数据字典，第四章概要设计里给出了模块结构和 E-R 图，第五章详细设计则落到数据库逻辑设计和程序流程图。这些章节不是凑字数的，每一节都能映射到代码里的一个具体文件或一张表。按这个顺序反推，你还没跑起来就已经知道系统长什么样了。

2.1 可行性分析决定的三件事

论文里写着「系统分析的含义、目标和任务」，听着虚，实际回答的是三个问题：技术上做不做得出来、成本上划不划算、运行上行不行得通。对应到这份资源，技术可行性就是 JSP + Servlet + MySQL 这套组合在 Tomcat 下能否稳定运行，经济可行性就是这个项目不需要额外购买商业软件，运行可行性则是超市收银员经过简单培训就能操作。

这套论证逻辑在答辩时几乎是必问的。老师不会真问你花了多少钱，而是问「为什么选这个技术栈」。标准答法是：JSP 在服务端动态生成页面，适合中小型管理系统；MySQL 免费且体积小；Tomcat 配置简单，整个项目在一台普通 PC 上就能跑。资源里的论文把这些都写好了，你要做的是在答辩前把这段背熟，并且能指着自己跑通的页面说明「这个可行性结论是在我实际部署之后验证过的」。

2.2 数据流图与数据字典：先圈定核心实体

论文第三章的业务流程分析和数据流图，落到数据库层面就是实体识别。超市管理系统的业务主线非常清晰：采购员向供应商进货，商品进入库存；收银员在前台销售，销售成功后库存减少；管理员维护商品信息和用户账号。围绕这条主线，核心实体就四个：商品、供应商、进货记录、销售记录。用户表单独存在，用来支撑登录和权限。

数据字典部分不用逐句读，做一件事就行——把论文里出现的所有数据项整理成一张核对表，然后打开资源里的数据库脚本，逐个对照字段是否存在。我一般会先在纸上画一个粗略的关系草图：

• 商品表：商品编号（主键）、商品名称、类别、进价、售价、库存量、供应商编号（外键）
• 供应商表：供应商编号（主键）、名称、联系人、联系电话
• 进货表：进货单号（主键）、商品编号（外键）、进货数量、进货单价、进货日期、操作员
• 销售表：销售单号（主键）、商品编号（外键）、销售数量、销售单价、销售日期、收银员

画完这张草图再去看代码，你会发现 controller 层的每个 Servlet 基本都对应一张表的增删改查，service 层处理多表关联，比如进货时要同时更新商品表里的库存量。论文和代码之间就差这么一张映射图，画完整个项目就通了。

2.3 模块结构与 JSP 页面映射表

论文第四章的「软件模块结构设计」通常是一张树状图，但树状图不好对照代码。我习惯把它转成一张页面映射表，这也是复用这份资源时最实用的一张表：

这张表的来源就是论文里的模块结构图加数据字典。注意一个细节：库存查询大多没有独立表，查的是 goods 表的库存量字段，这正是「数据库逻辑设计」章节里会说清楚的内容。每次有新需求，先往这张表里加一行，看是新增 JSP 还是复用已有页面，这就是基于现成资源做二次开发的起点。

3. 环境准备与部署：JDK、Tomcat、MySQL 的版本配对与启动顺序

传统 JSP 项目最让人头疼的不是代码，而是环境。很多毕设代码本身没问题，翻车都翻在版本不兼容上。这一章直接给版本搭配和部署步骤，照着做能在半小时内把系统跑起来。

3.1 版本搭配别奔着最新版去

老规矩，传统 JSP 项目最忌讳「最新版」。JDK 1.8、Tomcat 8.5、MySQL 5.7 是我在这个场景下反复验证过的稳定组合。三个版本各有一个必须避开的坑：

• Tomcat 10 及以上的包名从javax.servlet改成了jakarta.servlet，老项目编译直接报ClassNotFoundException，资源里如果用的是传统写法，别上 Tomcat 10
• MySQL 8.x 默认认证插件是caching_sha2_password，老项目里的 JDBC 驱动版本太低会连不上，报Unable to load authentication plugin
• JDK 版本太高的话，老代码里用的一些内部 API 可能在新版本被移除，编译期不报错但运行期抛 NoSuchMethod

所以优先按「JDK 1.8 + Tomcat 8.5 + MySQL 5.7」来配。如果只能装 MySQL 8，记得把连接串加useSSL=false&serverTimezone=UTC，驱动换成com.mysql.cj.jdbc.Driver，这个问题在第五章排查里还会细讲。

3.2 把工程跑起来的两种方式

资源里如果带的是完整工程目录（有 src、WebRoot 或 webapp），建议直接用 IDEA 或 Eclipse 导入后部署；如果带的是 war 包，直接丢进 Tomcat 的 webapps 目录最省事。先说 war 包方式：

# 停掉 Tomcat（如果已经在运行） cd /path/to/tomcat/bin sh shutdown.sh # Windows 下用 shutdown.bat # 把 war 包复制到 webapps 目录 cp supermarket.war /path/to/tomcat/webapps/ # 启动 Tomcat，war 会被自动解压 sh startup.sh # Windows 下用 startup.bat

war 包放在 webapps 下，Tomcat 会自动解压生成同名目录，访问路径就是http://localhost:8080/supermarket/。这个 context path 由目录名决定，如果你改了解压后的目录名，访问路径也要跟着改。确认启动成功的方法是看日志：

tail -f /path/to/tomcat/logs/catalina.out # 看到 "Server startup in [xxxx] milliseconds" 就说明启动完成

如果是 IDEA 导入源码工程，注意选择 Web 项目导入而不是普通 Java 项目，Artifact 类型选war exploded，然后配置 Tomcat 运行环境，Deployment 里把 artifact 的 Application context 设为/supermarket。这里最容易踩的坑是忘了添加 Tomcat 依赖库，导致 JSP 文件编译不过，后面排查章节会专门说。

3.3 初始化数据库：导入 supermarket.sql 的命令行操作

源资源里的数据库脚本通常是supermarket.sql，包含建库、建表和初始数据。导入前先确认 MySQL 服务状态，再执行导入：

# 登录 MySQL，root 密码按你自己的环境来 mysql -uroot -p # 在 MySQL 命令行里执行（也可以直接执行 sql 文件） mysql> source /path/to/supermarket.sql; # 验证导入结果 mysql> SHOW TABLES;

如果 sql 文件里有CREATE DATABASE语句，直接source就行；如果没有，需要手动先建库再导入：

mysql -uroot -p -e "CREATE DATABASE supermarket DEFAULT CHARACTER SET utf8;" mysql -uroot -p supermarket < /path/to/supermarket.sql

这里有个关键参数：建库时一定要指定字符集utf8。很多老脚本默认是 latin1，导入后中文全变问号。后面排查章节会具体讲，但建库这一步先养成习惯，统一加上DEFAULT CHARACTER SET utf8。

3.4 验证部署结果：从日志到页面三步走

部署完别急着点页面，按顺序做三个验证。第一步看 Tomcat 日志有没有报错，重点搜Exception和SEVERE；第二步访问http://localhost:8080/supermarket/，看能不能出登录页；第三步随便输入一个错误密码，看系统是否给出预期的错误提示。第三步很关键，如果页面能开但登录没反应，问题多半在数据库连接上。

数据库连接信息一般在src下的db.properties或jdbc.properties里，也可能是 DAO 类里硬编码的。检查三个值：URL、用户名、密码。这组配置要和你在 3.3 里设置的 MySQL 账号完全对应，端口默认 3306 一般不用改。

4. 读数据库脚本和核心代码：从建表到进货销售的事务链

环境和部署都跑通了，接下来就该拆代码了。这一章的核心任务是把数据库脚本和核心业务逻辑过一遍，搞清楚每张表为什么这样设计，以及进货、销售这两条主链路在代码里是怎么串起来的。这一章读透，答辩时老师问什么都能接住。

4.1 建表脚本拆解：字段命名、主外键和字符集

打开 supermarket.sql，找到商品表的建表语句，这段代码是整个数据库设计的骨架：

CREATE TABLE goods ( goods_id INT NOT NULL AUTO_INCREMENT COMMENT '商品编号，主键', goods_name VARCHAR(50) NOT NULL COMMENT '商品名称', category VARCHAR(20) DEFAULT NULL COMMENT '商品类别', purchase_price DECIMAL(10,2) DEFAULT NULL COMMENT '进价', sale_price DECIMAL(10,2) DEFAULT NULL COMMENT '售价', stock INT DEFAULT 0 COMMENT '库存量', supplier_id INT DEFAULT NULL COMMENT '供应商编号，外键', PRIMARY KEY (goods_id), KEY idx_supplier (supplier_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='商品信息表';

注意四个设计细节。第一个是主键用AUTO_INCREMENT自增，这是简单管理系统的常规选择，不需要业务意义，就是行号。第二个是DECIMAL(10,2)存金额，不是 float，因为二进制浮点数在加减时会有精度丢失，记账类数据绝对不能用 float。第三个是ENGINE=InnoDB，只有 InnoDB 支持事务和外键约束，MyISAM 不支持。第四个是字符集统一utf8，字段级别如果有单独指定也要检查一遍，避免出现表是 utf8、字段是 latin1 的混乱局面。

有外键关联的两张表，设计时要注意删除策略。比如进货表 purchase 里引用 goods_id，如果商品被删了，历史进货记录就成了孤儿数据。常见的解法是在外键上设置ON DELETE RESTRICT，禁止删除被引用的商品；或者逻辑删除，加一个is_deleted字段。老毕设项目里多数是硬删除加 RESTRICT，知道这一点，答辩时就能回答「为什么不直接 DELETE FROM goods」。

4.2 登录链路：从 JSP 表单到 DAO 查询的完整路径

看代码时不要从第一行看到最后一行，要追一条具体请求。最典型的是登录功能：用户在 login.jsp 输入用户名密码，点提交后发生了什么。打开 UserServlet 的 doPost 方法，代码脉络一般是这样的：

// UserServlet.java 的关键流程 protected void doPost(HttpServletRequest request, HttpServletResponse response) { String username = request.getParameter("username"); String password = request.getParameter("password"); UserDao dao = new UserDao(); User user = dao.findByUsernameAndPassword(username, password); if (user != null) { // 登录成功，把用户对象放进 Session request.getSession().setAttribute("currentUser", user); response.sendRedirect("index.jsp"); } else { // 登录失败，回到登录页并带出错误信息 request.setAttribute("errorMsg", "用户名或密码错误"); request.getRequestDispatcher("login.jsp").forward(request, response); } }

这条链路的三个关键点分别是：参数从request.getParameter拿，没有用框架封装；密码校验是直接 SQL 查库而不是先查出来再比对；登录状态靠Session维持，后续页面通过session.getAttribute("currentUser")判断是否登录。这三个点对应的就是 JSP/Servlet 技术栈的标准模式，也是 JSP 毕设最常被问到的问题——「怎么实现登录后才能访问」。很多老项目连过滤器都不用，每个页面顶部手动检查 Session，这样做的问题后面会说。

4.3 进货与销售：事务边界和库存扣减的顺序

超市系统最核心的黄金链路是进货和销售，两条链路都涉及多表操作。进货的逻辑是：插入一条采购记录，同时把商品表的库存量增加。销售逻辑对称：插入一条销售记录，同时把库存量减少。关键在于这两个操作必须在一个事务里完成，否则会出现「流水记了但库存没变」的数据不一致。

// PurchaseServlet 中进货事务的核心片段 Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 关闭自动提交，开启事务 // 第一步：插入进货记录 String insertSql = "INSERT INTO purchase (goods_id, quantity, price, purchase_date, operator) VALUES (?, ?, ?, NOW(), ?)"; PreparedStatement ps1 = conn.prepareStatement(insertSql); ps1.setInt(1, goodsId); ps1.setInt(2, quantity); ps1.setBigDecimal(3, price); ps1.setString(4, operator); ps1.executeUpdate(); ps1.close(); // 第二步：更新商品库存 String updateSql = "UPDATE goods SET stock = stock + ? WHERE goods_id = ?"; PreparedStatement ps2 = conn.prepareStatement(updateSql); ps2.setInt(1, quantity); ps2.setInt(2, goodsId); ps2.executeUpdate(); ps2.close(); conn.commit(); // 两步都成功才提交 } catch (Exception e) { conn.rollback(); // 任何一步失败，整体回滚 e.printStackTrace(); } finally { // 恢复自动提交并关闭连接 conn.setAutoCommit(true); DBUtil.close(conn); }

这段代码就是论文里「程序流程图」对应「进货流程」的真实实现。阅读时抓住三个要点：setAutoCommit(false)之后的每一步都在同一个数据库事务里；commit()之前任何异常都会走rollback()撤销全部操作；finally里恢复setAutoCommit(true)是因为数据库连接通常被连接池复用，不恢复会把状态污染给下一次请求。

销售逻辑一样，只是把stock = stock + ?改成stock = stock - ?，并且在扣减前要加一个判断：WHERE goods_id = ? AND stock >= ?，防止库存扣成负数。这个细节很多老项目会漏掉，如果你发现资源里的代码没有这个判断，这恰恰是你做二次开发时可以改进的点，答辩时主动提出来会加分。

5. 常见问题排查：部署与运行期最常踩的五个坑

JSP 老项目的运行问题高度相似。这一章整理五条高频踩坑记录，每一条我都按「现象 → 原因 → 解决」的顺序写清楚，遇到问题时直接对号入座。

5.1 页面中文全部变成问号或乱码

现象：登录页能打开，但所有中文标签都显示成???或问号方块。

原因有三个层面：JSP 文件本身的编码不是 UTF-8；Tomcat 接收请求时用了默认的 ISO-8859-1；数据库连接串没有指定字符集。这三个只要有一个没设对，中文就挂。

解决：从上到下依次检查。JSP 页面头部的pageEncoding改成UTF-8；项目的 web.xml 里加编码过滤器；JDBC 连接串加上?useUnicode=true&characterEncoding=utf8。改完重启 Tomcat，通常乱码问题就消失了。

5.2 部署后访问返回 404 或 ClassNotFoundException

现象：Tomcat 启动没报错，但访问http://localhost:8080/supermarket/出现 404，或者访问某个页面时报ClassNotFoundException: com.mysql.jdbc.Driver。

原因要分开看。404 多半是 context path 不对，war 解压出来的目录名和访问路径不一致。ClassNotFoundException 则是缺 MySQL 驱动 jar 包，这个 jar 应该放在WEB-INF/lib下，而不是只放在 Tomcat 的 lib 下。

解决：404 就先ls webapps/看看实际目录名；缺驱动就把mysql-connector-java-xxxx.jar复制到webapps/supermarket/WEB-INF/lib/下，重启 Tomcat。如果用的是 IDEA 部署，还要检查 Artifact 的 Output Layout 里有没有这个 jar。

5.3 登录时提示数据库连接失败

现象：页面能打开，输入账号密码后整个界面卡住，或直接报Cannot create connection to database server。

原因很大概率在连接串上。老资源里的驱动名是com.mysql.jdbc.Driver，MySQL 5.7 能用，但 MySQL 8 必须改成com.mysql.cj.jdbc.Driver。另一个常见原因是数据库服务没启动，或密码和 db.properties 里不一致。

解决：先mysql -uroot -p确认数据库能连上；再检查 db.properties 里的 URL、用户名、密码三项；最后确认驱动 jar 包版本和 MySQL 版本匹配。mysql-connector 5.1.x 配 MySQL 5.7 没问题，配 MySQL 8 就可能报插件错误，换 8.0.x 版本的驱动即可。

5.4 启动 Tomcat 提示端口被占用

现象：startup.sh执行完，日志里报Port 8080 required by Tomcat v8.5 Server at localhost is already in use。

原因很简单，8080 端口被别的进程占了，可能是另一个 Tomcat 实例，也可能是其他开发工具。

解决：找到占用端口的 PID 再决定是否结束它。

# Linux / macOS lsof -i:8080 kill -9 <PID> # Windows netstat -ano | findstr 8080 taskkill /F /PID <PID>

如果确定是之前启动的 Tomcat 实例没关干净，也可以直接执行shutdown.sh优雅关闭。要是多个项目并行开发，更推荐把某个 Tomcat 的端口改掉，改server.xml里<Connector port="8080"这一行的值。

5.5 页面报 500 错误但控制台没有堆栈信息

现象：访问某个 JSP 页面直接 500，Tomcat 控制台却只打了一行Exception头部信息，没有具体堆栈。

原因：JSP 页面在首次请求时才编译，编译错误发生在 Tomcat 的 work 目录，控制台往往只输出一部分。还有一个隐蔽情况是 JSP 页面里的 Java 代码抛了异常，被页面缓冲机制吞掉了。

解决：先打开logs/catalina.out和localhost.2025-xx-xx.log看完整堆栈，再去看work/Catalina/localhost/supermarket/org/apache/jsp/目录下对应的_jsp.java文件，那个文件是 Tomcat 把 JSP 转译成的 Servlet 源码，行号能直接定位到问题。如果 JSP 里用了 Java 代码片段<% %>，重点检查变量作用域和 import 引入。稳一点的做法是给 web.xml 加一个全局错误页：

<error-page> <error-code>500</error-code> <location>/error.jsp</location> </error-page>

这样至少用户看到的是一个友好页面，而不是白屏加一堆异常。但这只是兜底，排查还得靠日志。

6. 二次开发与验证技巧：把样本资源变成你自己的毕设

系统跑通只是第一步，想拿到好成绩，必须做差异化改造。这一章给一套验证方法和三个低成本改造方向，全部基于资源现有代码，不需要推倒重来。

先过一遍功能验证清单，确认系统是完整可用的，也是答辩演示时的操作脚本：

验证的时候建议把浏览器开发者工具打开，切到 Network 面板，观察每次操作的请求 URL 和参数名。这样做有两个好处：一是你能在答辩时清楚说出「我提交的这个表单数据被发送到了哪个 Servlet」，二是改造时知道该改哪个页面。

三个低成本改造点。第一个是把 JDBC 原生连接换成连接池。资源里如果用的是DriverManager.getConnection，改成 DBCP 或 C3P0，改造量不大但技术上是个亮点，答辩时可以说「优化了数据库连接的创建和释放开销」。第二个是给权限控制加过滤器。老项目通常是每个页面手动session.getAttribute判断，写一个LoginFilter统一拦截，未登录请求一律踢回 login.jsp，这个改进在安全性上非常加分。第三个是把 JSP 里的 Java 代码片段抽成 JSTL/EL。传统 JSP 页面到处都是<% %>，用 JSTL 标签替换，代码看上去立刻上一个档次。

拿这份资源做毕设，最值钱的其实是论文和代码的对应关系。系统分析对应技术选型理由，数据字典对应数据库表结构，程序流程图对应事务处理代码。答辩准备时逐章对照，把「论文里说的」和「代码里做的」连成一条线。我从那以后每次拿到老项目，都强制自己先画一张「页面 → Servlet → DAO → 数据表」的四层映射图再动手改代码，改完再跑一遍上面的验证清单，能省下大量排错时间，希望帮到你。

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