简介：面向计算机相关专业毕业设计学生和 Java 学习者的超市会员管理系统完整项目，已获高分通过，可直接作为毕业设计、课程设计或期末大作业使用。系统基于 JSP、Servlet、JDBC 技术栈，配合 MySQL 数据库，覆盖会员信息、消费记录、积分累计、商品管理等核心业务，前端采用 Bootstrap、jQuery UI 等组件构建，界面清晰美观，经过严格调试后开箱即用。压缩包内共有 742 个文件，总大小约 15.72MB，包含 76 个 Java 后端源码、87 个 JavaScript 脚本、53 个 CSS 样式表、1 个 SQL 数据库脚本，以及大量 jpg、png、gif 页面截图和操作演示图片，便于对照界面理解代码逻辑；同时还包含 xml、properties、yml 等配置文件和字体文件，完整支撑项目运行。配套提供软件工具和项目说明，帮助读者快速搭建 JDK、Eclipse、Tomcat 环境。目前已有 668 人学习，适合需要完整参考方案和实战练习的 Java 初学者。
1. 拿到“基于Javaweb的超市会员管理系统源码+数据库”后，第一件事不是打开IDE
绝大多数人下载这类毕业设计源码后，都会犯同一个错误：急着用 IDEA 打开，结果满屏报错、tomcat 起不来、数据库连不上，半小时后心态就崩了。这个基于 Javaweb 的超市会员管理系统，典型的 SSM 或 JSP+Servlet 三层结构，配 MySQL 数据库，功能无非是会员开卡、积分累计、等级升降、商品折扣、充值消费这些教务级业务。它不是什么高并发微服务，更不是分布式架构，但它是一套完整的 Javaweb 项目，意味着你必须按一套固定流程把它跑起来——先部署环境，再导入数据库，然后改配置文件，最后启动项目。顺序错了，后面每一步都在给你挖坑。
这套系统解决的是应届生或转行者最实际的诉求：一个能写在简历上的完整 Javaweb 项目，一个能跑通演示给老师看的毕业设计。但它能不能给你加分，取决于两个能力：你能不能让它在三十分钟内跑起来，以及你能不能讲清楚每个模块的实现逻辑。这篇文章就按我多年带毕设的真实路径来讲：从哪里开始拆包，怎么搭环境，数据库怎么导，登录注册和会员积分怎么调通，以及最容易让你翻车的七个坑。新手照着做能跑通，熟手可以重点看第四、五章的参数调优和避坑记录。
2. 从 zip 包到项目启动：环境配置与 IDEA 部署的完整落地路径
2.1 先看压缩包里都有什么：源码目录结构决定了你的部署路径
拿到压缩包后，第一步不是解压运行，而是先看目录结构。常见的超市会员管理系统源码包，内部一般有两块内容：源码（含 src、web、pom.xml 或 .project/.classpath）和数据库.sql文件（文件名通常叫supermarket.sql、member.sql或db_supermarket.sql）。有些作者会附带README.txt或环境配置说明.docx，不要跳过这些文件，它们经常写着数据库账号密码、Tomcat 版本要求、JDK 版本这些关键信息。
我习惯先把解压后的目录结构完整列一遍，确认是 Maven 项目还是普通 Web 项目。如果根目录有pom.xml，说明是 Maven 工程，依赖由 Maven 统一拉取；如果没有，只有.classpath和.project，那是传统 Eclipse 工程，需要手动添加 jar 包，用 IDEA 导入时选“Eclipse”模式，或者干脆新建一个空项目然后把 src 和 web 目录拷进去。判断错误会导致后面依赖永远不完整，这是最常见的第一类卡壳点。
# 解压后先看目录结构 unzip 超市会员管理系统.zip -d supermarket cd supermarket && find . -maxdepth 3 -type f | head -50逻辑说明：这条命令把压缩包解压到supermarket目录，然后列出前三层所有文件名。重点看三处：是否存在pom.xml（决定是不是 Maven 项目）、是否存在.sql文件（决定数据库脚本位置）、是否存在src/main/java（标准 Maven 结构）还是src/com.xxx（传统动态 Web 项目结构）。
2.2 JDK 与 Tomcat 版本选择：别用太新的版本折磨自己
超市会员管理系统这类毕业设计，绝大多数基于 JDK 8 编写，少数基于 JDK 11。Tomcat 版本对应也有讲究：JDK 8 配 Tomcat 8.5 或 9.0 是最稳的组合，JDK 11 可以配 Tomcat 9。如果你电脑上装的是 JDK 17 或更高版本，大概率会因为javax.servlet包缺失或者 JSP 编译报错而卡住。这种项目用的是 javax 命名空间，而 JDK 9 之后模块化把很多东西移走了，严格要求使用 JDK 8 是省事的第一原则。
IDEA 版本方面，热词里搜“idea2026 创建javaweb项目”的同学很多，说明大家在乎的是新版本 IDEA 能不能跑老项目。答案是可以，但你要注意：新版 IDEA（2022 之后）默认不自动下载 Tomcat 插件，需要在插件市场手动安装“Smart Tomcat”或直接在 Run Configuration 里配置本地 Tomcat。老项目导入时，IDEA 会提示“Unlinked Maven Project”，点右侧 Maven 面板刷新即可。
# 查看当前 Java 版本，确认是否满足要求 java -version # 若版本不是 1.8，去 oracle 官网下载 jdk8 并安装，然后在 IDEA 中切换 Project SDK逻辑说明：java -version是最直接的版本检查。如果系统有多个 JDK，在 IDEA 里通过File -> Project Structure -> Project -> SDK指定为 JDK 8，并在Settings -> Build Tools -> Maven -> Runner -> JRE处也切到 JDK 8，两处必须一致，否则 Maven 编译用一个版本、运行用另一个版本，会出现“程序包不存在”或“不支持发行版本 xx”的报错。参数说明：这种项目不要指望用最新 JDK，JDK 8 是这条路线上最稳的基石。
2.3 MySQL 数据库导入：字符集与账密统一是关键
数据库是这套系统的核心。导入.sql脚本前，先在本地 MySQL 里创建一个专用数据库用户，或者直接用 root。需要提醒的是，很多源码里的数据库配置写在jdbc.properties或db.properties里，默认账号root、密码123456。如果你的 MySQL 密码不是这个，要么去改配置文件，要么新建一个用户凑齐“root/123456”这个预案。我通常的做法是前者。
用命令行或 Navicat 导入都可以，但字符集必须为utf8mb4。超市会员管理系统中包含会员姓名、手机号，大概率有中文，如果字符集选错了，所有中文都会变成问号，这几乎是每一届学生都会遇到的场景。
-- 先建库，再指定字符集 CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE supermarket; -- 然后执行 source 导入脚本 source D:/supermarket/db_supermarket.sql;逻辑说明：先创建一个名为supermarket的库，库的默认字符集强制为utf8mb4，然后通过source命令把压缩包里的 SQL 脚本导进去。脚本内部如果写了CREATE DATABASE语句，需要先打开脚本看一眼，如果存在同名建库语句，要先确认它用的是不是utf8或latin1，如果有，改成utf8mb4再执行。参数说明：utf8mb4_general_ci是通用不区分大小写校验集，对做查询统计非常友好，MySQL 5.7 及以上都支持。
导入完成后，检查关键表是否存在：一般会有member（会员表）、goods（商品表）、level（会员等级表）、record（消费/积分记录表）、admin（管理员表）。有这些表说明数据库脚本完整。
2.4 修改 JDBC 连接配置与 Tomcat 启动：让项目跟数据库对上话
数据库导入后，进入代码层面最关键的环节：改 JDBC 配置。打开项目的src/main/resources/jdbc.properties或db.properties，会看到类似这样的内容：
jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/supermarket?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf-8 jdbc.username=root jdbc.password=123456逻辑说明：jdbc.url里的localhost:3306/supermarket指向刚才本地建好的数据库；serverTimezone=Asia/Shanghai必须加，因为新版本 MySQL 驱动默认时区跟中国差了八小时，不加会报Server time zone异常；characterEncoding=utf-8保证中文写入和读取一致，这一步错了后面乱码排查十个小时也未必找得到。参数说明：useSSL=false是本地连接建议，不关闭 SSL 有时候会报证书警告甚至连接被拒。
改完配置后启动 Tomcat，IDEA 中的部署方式一般是：Run -> Edit Configurations -> + -> Tomcat Server -> Local，在Deployment标签页里添加Artifact，选war exploded，Application context 可以设成/supermarket。
# 启动后看日志的关键行（IDEA 控制台或 Tomcat logs 目录） INFO: Server startup in [1523] milliseconds # 看到这个才算启动成功逻辑说明：Tomcat 日志出现Server startup in XXXX milliseconds表示容器启动成功。这时打开浏览器访问http://localhost:8080/supermarket/，能看到登录页，说明整个 Javaweb 项目的骨架已经活了。如果 404，先看 application context 是否配置正确；如果 500，去logs/catalina.out里看异常类型，一般是数据库连接失败或者 jar 包冲突。
3. 从管理员登录到会员积分：梳理“Javaweb + 数据库”主流程里的每个功能闭环
3.1 管理员登录与会话管理：为什么登录状态不能只靠 URL 跳转
超市会员管理系统的入口是管理员登录。后台处理逻辑一般是一个AdminLoginServlet或AdminController，接收表单提交的username和password，去数据库admin表里查记录，比对成功后把admin对象放进 Session，然后跳转到index.jsp主页面。很多新手误以为登录成功后就完事了，其实判断一个 Javaweb 项目合不合格，核心在于两点：是否用 Session 校验了未登录访问？是否在退出登录时主动让 Session 失效？
我给学生的建议是，代码拿到手后先找到拦截器或过滤器。如果是 SSM 项目，会有一个LoginInterceptor实现HandlerInterceptor，里面重写preHandle方法，从 Session 里取管理员，取不到就response.sendRedirect("login.jsp")。如果是 Servlet 项目，可能是每个 Servlet 第一行都写着if(session.getAttribute("admin")==null) { response.sendRedirect(...); }。这部分是答辩时老师最爱问的——“你的系统安全控制做得怎样”，所以你不能只跑通，还得讲清楚这个逻辑。
// 典型登录校验逻辑（Servlet/Controller 内） public String login(String username, String password, HttpSession session) { Admin admin = adminService.findByUsernameAndPassword(username, password); if (admin != null) { session.setAttribute("admin", admin); return "redirect:/admin/index"; // 登录成功跳转主页面 } return "redirect:/login.jsp?error=1"; // 失败回登录页并带错误码 }逻辑说明：adminService.findByUsernameAndPassword是数据访问层的方法，对应 SQL 是select * from admin where username=? and password=?。这里注意，如果是明文密码，系统安全级别很低，但毕业设计通常也就这个水平，你可以在答辩时说这是简化处理，生产环境必须用 MD5 加盐。参数说明：session的有效期默认 30 分钟，在web.xml里可以用<session-config><session-timeout>30</session-timeout></session-config>调整，答辩时能主动说出这个参数，会加分。
3.2 会员开卡与信息维护：前端表单校验和后端防重是一件事的两面
会员模块是这个系统的牌面。前端表单包括姓名、手机号、身份证号（有些系统不要求）、生日、地址，开卡时后台要自动生成会员编号，并设置初始积分（一般是 0 或激活送的 100 分）。积分策略由等级表level决定，例如 0-1000 分为普通会员、1000-5000 为银卡、5000 以上为金卡，消费时不同等级对应折扣率，折扣率存储在level.discount字段中。
前端提交后，后端至少要做三件事：手机号格式校验（正则）、根据手机号判断该会员是否已存在（防重复开卡）、写入member表并把初始等级 ID 关联进去。我见过太多毕设系统，开卡录入两个同手机号的人，后面做消费统计时积分全串了，这就是没做防重的后果。你可以检查源码里是否有这一段逻辑。
// 开卡页面前端校验示例（检查手机号与身份证格式） function validateForm() { var phone = document.getElementById("phone").value; var idCard = document.getElementById("idCard").value; var phoneReg = /^1[3-9]\d{9}$/; if (!phoneReg.test(phone)) { alert("手机号格式不正确"); return false; } if (idCard.length !== 18) { alert("身份证号长度必须为18位"); return false; } return true; }逻辑说明：这是最基础的前端表单拦截，能挡住大部分无效提交，但后端还得做一遍。因为用户可以绕开前端直接构造 HTTP 请求，后端如果只信任前端校验，那这个系统的数据迟早出问题。参数说明：手机号正则^1[3-9]\d{9}$是目前的主流写作，屏蔽掉 12、13 开头的旧号码段（其实 13 还保留着），如果你维护的代码里写的是^1[3|5|7|8]，那是早期写法，建议升级成这个。
后端防重的 SQL 逻辑，可以写成select count(*) from member where phone = ?，大于 0 就直接返回“该手机号已注册”。这一步零成本但是极其重要。
3.3 消费结算与积分累计：事务是积分不丢的最后防线
消费结算是超市会员系统的核心场景。管理员选择会员、输入商品金额（或扫描商品条码把商品加入购物车），系统按会员等级折扣算出实收金额，同时计算本次获得的积分，更新会员总积分。实现上，一个消费动作要更新三张表：record（新增一条消费记录）、member（更新累计积分和累计消费额）、goods（如果使用库存，则要扣减库存）。这三步必须在一个事务里。
SSM 项目里，这个逻辑通常写在MemberServiceImpl或RecordServiceImpl的方法上，标注@Transactional。如果源码没写事务注解，那就是经典的“积分丢了但钱扣了”翻车现场。答辩时老师如果问“并发场景下两个人同时消费怎么办”，你只要回答“在方法上加事务，并用数据库的行级锁保证同一会员的积分更新串行化”，这个回答基本可以终结追问。
@Transactional(rollbackFor = Exception.class) public void consume(String memberId, BigDecimal amount) { // 1. 查询会员信息得到等级折扣 Member member = memberMapper.selectById(memberId); BigDecimal discount = levelMapper.selectById(member.getLevelId()).getDiscount(); // 2. 计算实付金额 BigDecimal realPay = amount.multiply(discount); // 3. 计算本次积分（如每消费1元积1分） int points = realPay.intValue(); // 4. 插入消费记录 recordMapper.insert(new Record(memberId, amount, realPay, points)); // 5. 更新会员积分和累计消费 memberMapper.addPoints(memberId, points); memberMapper.addTotalConsume(memberId, realPay); }逻辑说明：@Transactional(rollbackFor = Exception.class)保证方法中任何一步抛出异常，前面已经执行的数据库操作全部回滚，不会出现“记录表多了一条但积分没涨”的不一致状态。参数说明：rollbackFor一定要写成Exception.class，因为 Spring 默认只对 RuntimeException 回滚，如果你只写@Transactional不指定参数，SQL 异常（继承自 Exception 而非 RuntimeException）不会触发回滚，这是初级开发最容易犯的错。
3.4 商品折扣与等级联动：一张等级表如何影响多个业务模块
很多毕业设计把商品折扣写死在代码里，比如金卡打 8 折，直接在 service 层写if (levelId == 3) rate = 0.8。这种做法跑起来没问题，但答辩时如果被问到“你们如何支持未来调整折扣策略”，回答得好不好就分水岭了。正规的做法是把折扣率放到level表里，等级变更只需要改库，不需要改代码。
level表的结构一般是：id、level_name（如普通会员、银卡会员、金卡会员）、min_points（达到该等级所需最小积分）、discount（折扣率，0.8 代表 8 折）。开卡时默认level_id = 1，消费积分数累计后，进入结算逻辑之前先调用一个updateLevel(memberId)方法，判断当前积分达到哪个等级门槛，自动升降级。这个逻辑如果没见过完整源码，建议自己动手模拟写一遍，它是超市会员系统里仅次于账单计算的第二个核心点。
-- 根据积分自动升降级（MySQL case 写法） UPDATE member m SET m.level_id = ( SELECT l.id FROM `level` l WHERE m.points >= l.min_points ORDER BY l.min_points DESC LIMIT 1 ) WHERE m.id = #{memberId};逻辑说明：这个子查询找到该会员积分能匹配到的最高等级。比如积分为 3000，等级表里普通会员min_points=0、银卡min_points=1000、金卡min_points=5000，那么WHERE m.points >= l.min_points会筛出普通和银卡两行，ORDER BY l.min_points DESC后银卡排第一，LIMIT 1取到的就是银卡。参数说明：注意m.points >= l.min_points这个方向，积分越高等级越高，这里是积分越高min_points越大，所以才需要倒序取第一条。
4. 数据库设计拆解与多表联查实操：超市会员系统里的每张表怎么用
4.1 表结构与关系：从 4 张核心表到权限扩展表
这个系统兜底的数据库文件通常包含这几张表，你把表结构过一遍就大概知道功能边界了。member会员表，字段最少要有：id、member_no（会员编号）、name（姓名）、phone（手机号）、points（积分）、level_id（等级外键）、balance（余额，若有充值场景）、create_time。level等级表，字段为id、level_name、min_points、discount。goods商品表，字段为id、goods_name、price、stock、category_id。record消费记录表，字段为id、member_id、goods_id（如果单条记录对应单商品）或order_id（如果先建订单再关联）、amount（原价总额）、real_pay（实付金额）、points_gained（本次获得积分）、create_time。
表关系不复杂：member多对一关联level，record多对一关联member。如果系统支持多商品结算，中间还需要一张order_goods关联表。检查源码的优先级：先看这几张表是否都在数据库脚本里，再看主外键有没有建索引，你没看错，很多毕设源码的表结构根本就没建索引，而member.phone这种高频查询字段加不加索引，数据量上万后查询速度差距高达几十倍。
-- 会员表建表语句的核心片段（注意索引和默认值） CREATE TABLE `member` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键', `member_no` varchar(20) NOT NULL COMMENT '会员编号', `name` varchar(50) NOT NULL, `phone` varchar(11) NOT NULL, `points` int(11) DEFAULT '0', `level_id` int(11) DEFAULT '1', `balance` decimal(10,2) DEFAULT '0.00', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_member_no` (`member_no`), KEY `idx_phone` (`phone`), KEY `idx_level_id` (`level_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：member_no设唯一索引是因为开卡编号绝不能重复；phone设普通索引是因为登录和开卡防重都要按手机号查；level_id设普通索引是因为按等级做分组统计时避免全表扫描。参数说明：DEFAULT CURRENT_TIMESTAMP让create_time在插入时自动填充，减少代码层一笔额外的new Date()传参，这个细节答辩时可以提。
4.2 用 SQL 完成会员消费统计：把每张表的价值榨出来
数据库设计得合理，统计查询就是顺手的事。超市会员管理系统最常见的统计需求有三个：查询某会员的全部消费记录（后台流水）、统计每个等级的会员人数（运营分析）、按时间范围统计每日营业收入（报表）。
以下三条 SQL 基本覆盖了这三种需求，源码里的 DAO 层 XML 文件（Mapper.xml）中几乎必然有类似查询。如果拿到了源码但里面没有，我建议你补上，因为这是体现你“看懂”项目的最快方式。
-- 1. 查询某会员最近10条消费流水（关联显示等级名） SELECT r.id, r.amount, r.real_pay, r.points_gained, r.create_time, l.level_name FROM record r LEFT JOIN member m ON r.member_id = m.id LEFT JOIN `level` l ON m.level_id = l.id WHERE r.member_id = #{memberId} ORDER BY r.create_time DESC LIMIT 10; -- 2. 统计每个等级的会员人数 SELECT l.level_name, COUNT(m.id) AS member_count FROM `level` l LEFT JOIN member m ON l.id = m.level_id GROUP BY l.id, l.level_name ORDER BY member_count DESC; -- 3. 按日统计营业收入（实付金额之和） SELECT DATE(create_time) AS day, SUM(real_pay) AS total_income FROM record GROUP BY DATE(create_time) ORDER BY day DESC;逻辑说明：第一条 SQL 用两次 LEFT JOIN 把流水表关联到会员表和等级表，让页面可以直接展示等级名称而不用在 Java 代码里再做一次查询。第二条 SQL 用 LEFT JOIN 保证即使某个等级下暂时没人，也会显示 0 而不是被过滤。第三条 SQL 用DATE(create_time)把带时分秒的日期截断成天，配合GROUP BY做到按日聚合。参数说明：LIMIT 10是页码上限，生产环境应该配合分页组件如 PageHelper，写成LIMIT #{offset}, #{pageSize}。
4.3 MyBatis 与 JDBCTemplate 的差异：这个系统的数据访问层是怎么写的
拿到源码后，先看数据访问层用的是 MyBatis 还是 JDBCTemplate 或原生 JDBC——这决定了你后续改代码的方式。当前主流毕设使用 SSM（Spring + SpringMVC + MyBatis）架构的比例高一些，Mapper 层以接口加 XML 的形式存在，SQL 写在 XML 文件里；也有相当一部分用 JSP + Servlet + JDBC，SQL 拼在 Java 类里。
如果是 MyBatis，配置集中在mybatis-config.xml里，注意 mapper 扫描路径是否与你的包结构一致。如果启动时提示Invalid bound statement (not found)，八成是Mapper.xml的 namespace 写错，或者 XML 文件没有放在resources目录与接口包路径对应的位置。如果是 JDBCTemplate，那么applicationContext.xml里会配置一个jdbcTemplateBean。
这里有一个容易被忽略的点：MyBatis 的 XML 文件里，SQL 语句结尾不要加分号。MySQL 客户端里写分号没问题，但在 MyBatis 的动态代理执行里，分号可能造成解析异常，这是一个非常经典的踩坑点。另一个高频问题是#{}和${}的区别——#{}是预编译占位符，会生成?参数占位，能防 SQL 注入；${}是直接字符串拼接，只在表名、排序字段等动态场景才用，绝对不要用在WHERE子句的值上。
<!-- 会员等级折扣查询 Mapper 片段 --> <select id="selectLevelDiscount" resultType="java.math.BigDecimal"> SELECT discount FROM `level` WHERE id = #{levelId} </select>逻辑说明：resultType直接映射成BigDecimal，比先查整行对象再取字段省一次转换，适合只需要一个值的方法。参数说明：#{levelId}对应方法入参里的Integer levelId，MyBatis 会自动完成类型映射和预编译，这一写法兼顾易读性和安全性。
5. 避坑记录：上手超市会员管理系统必踩的七个坑与排查路径
5.1 启动时报ClassNotFoundException: com.mysql.jdbc.Driver，是版本不匹配
现象：Tomcat 启动后访问页面直接 500，看异常信息是找不到 MySQL 驱动类。
原因：现在 MySQL 8.x 驱动类名已经改成com.mysql.cj.jdbc.Driver，如果 jar 包是mysql-connector-java-5.x，类名才是旧的com.mysql.jdbc.Driver。源码里写的是旧类名，但你的 jar 包是 8.x；或者 Maven 项目依赖里根本没引入 mysql-connector-java 依赖。
解决：打开pom.xml检查依赖版本，如果是 Maven 项目，建议使用 5.1.49 或 8.0.x 的最新旧版本命名，然后检查jdbc.properties里的 driver 类名与 jar 包对应。如果不是 Maven 项目，去 Tomcat 的lib目录或项目的WEB-INF/lib里查看 jar 包。最快的解决路径是写进pom.xml：
<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.30</version> </dependency>同时把jdbc.driver=com.mysql.jdbc.Driver改成jdbc.driver=com.mysql.cj.jdbc.Driver。这个坑的概率在 80% 项目里都会遇到，原因就是当初做毕设的人用的电脑版本跟你不一致。
5.2 数据库导入成功但页面全是中文问号，是字符集链路断了
现象：数据从后台页面录入是正常中文，刷新后变成问号；或者数据库表里直接就是问号。
原因：整条链路必须有四个环节统一为 utf8：数据库表字符集、JDBC URL 里的characterEncoding、Tomcat 接收 POST 请求的解码、JSP 页面的pageEncoding。任何一个环节是 ISO-8859-1 或 GBK，中文就废了。
解决：先查表字符集，再查 jdbc.properties，最后在web.xml里配置 Spring 的字符集过滤器（如果是 SSM 项目）：
<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>这个过滤器是 Shiro 之外的必配 Filter，<url-pattern>/*</url-pattern>保证所有请求都经过它，POST 参数在进入 Controller 之前已经被正确解码。如果项目没有 Spring，原作者可能是在doPost里手写request.setCharacterEncoding("UTF-8")，检查一遍即可。
5.3 IDEA 里Artifact部署配置错误导致 404
现象：Tomcat 启动日志没有异常，但访问http://localhost:8080/index.jsp是 404，或者访问项目路径http://localhost:8080/supermarket/也是 404。
原因：IDEA 的 Tomcat 部署里Deployment标签页没有正确添加 Artifact，或 Application context 设置成了根路径/，而你的源码欢迎页在webapp/supermarket子路径下。
解决：打开Run -> Edit Configurations -> Deployment，点击+选择Artifact，选带war exploded的那个，Application context 填/supermarket。然后回到Server标签页，看URL是否正确，默认应为http://localhost:8080/supermarket/。注意这里war exploded和压缩后的 war 区别很大，开发调试阶段用 exploded 可以热部署修改 JSP 而不需要重启，生产效率高很多。
5.4 页面 CSS 和图片全部丢失，是前端资源路径问题
现象：登录页能显示但样式全无，控制台里一堆 404，报的是.css、.js、.jpg找不到。
原因：JSP 页面里如果写死<link href="css/style.css">这种相对路径，在部署路径是/supermarket/时会解析成http://localhost:8080/css/style.css，当然找不到。
解决：把所有静态资源引用改成绝对项目路径。JSP 推荐用${pageContext.request.contextPath}前缀拼接：
<link rel="stylesheet" href="${pageContext.request.contextPath}/css/style.css">或者在页面顶部用base标签统一指定。这个坑属于老毕设最常见的路径问题，本质原因是作者打包时用的是根路径部署，换成带项目名的 context 就裂了。
5.5 《Tomcat 端口被占用》——Javaweb 项目第一大玄学报错
现象：启动 Tomcat 时弹窗显示Port 8080 is already in use，有时还会把浏览器指向其他程序。
原因：系统中另一个 Java 进程或别的 web 服务占用了 8080 端口，常见的是之前没有正确停掉的 Tomcat 实例，或者安装了其他软件（如 Oracle 自带的 HTTP 服务占用了 8080）。
解决：查占用进程再决定是杀掉还是换端口。Windows 下命令是：
netstat -ano | findstr 8080 taskkill /PID <进程号> /FLinux / macOS 下是lsof -i:8080。如果你不想动已有服务，直接改 Tomcat 端口：conf/server.xml中将<Connector port="8080"改成8081，再改 IDEA 配置里 Tomcat 的 HTTP port 保持一致即可。这个方法治标也治本——不同项目用不同端口测试，互相不干扰。
5.6 报错Access denied for user 'root'@'localhost'，是密码不一致
现象：数据库连接池启动失败，异常信息是拒绝访问，用户名密码被发现对不上。
原因：源码配置文件里的数据库账号密码与本地 MySQL 不一致。很多人只改了jdbc.properties里的密码，但数据源 Bean 里如果硬编码了连接信息，或者用了多个配置文件（dev/prod），改漏了。
解决：全局搜索关键字password和jdbc:mysql，把项目中所有数据库相关配置全部找出来，逐个核对。Spring 项目里有多个配置源时，可以临时在jdbc.properties里的数据库密码处写当前密码，然后看日志中实际生效的是哪个配置。以及，如果不止一套配置，用注释法逐一排除是高效率的做法。
5.7 登录后页面能访问但刷新后掉登录，是 Session 持久化缺失
现象：登录成功跳转首页，按 F5 刷新就跳回登录页，有些还伴随“会话已过期”的提示。
原因：项目设置了<session-timeout>过短（如 1 分钟），或者web.xml里配置了过期的安全策略；另一种可能是登录成功后的Redirect写成了forward，导致浏览器地址栏是旧的 URL，刷新时重新提交了一个不含 Session 标识的请求。
解决：把web.xml里的<session-timeout>调整为 30 或 60。检查登录代码里session.setAttribute是否真的写入了值；如果用了 Spring Security 或 Shiro，检查 RememberMe 配置。老式 Servlet 项目通常就是 session-timeout 的问题，改完重启即可。
6. 把超市会员系统变成答辩加分项：改造方向与验证方法
这个项目跑通只是起点，你还要让它变成你的作品。我的建议是四个改造方向，按工作量从少到多排列：第一个是给密码加盐哈希加密，源码里如果是明文密码，你用MD5或BCrypt重写登录校验，这一步大约 20 行代码，但亮点极大——答辩时你能说“我关注到数据安全问题，所以升级了密码存储方案”。第二个是加一个简单的数据图表页，用 ECharts 展示每日营业额折线图或会员等级占比饼图，后端写一个聚合查询返回 JSON，前端 Ajax 拉取渲染。第三个是加一个导出功能，把会员消费流水导出成 Excel 或 CSV，用Apache POI或直接拼 CSV 文件流下载。第四个是引入 Redis 缓存会员等级配置，减少数据库查询压力——这个对毕设来说偏重，但如果老师在项目上追问性能，你可以作为“未来优化方向”提出来。
验证方法上，我习惯带学生按流程走一遍：新开一张会员卡，录入手机号、姓名，确认数据库member表新增记录，积分初始为 0；消费 120 元，确认record表新增一条记录，member表积分增加，余额扣减；连续消费多笔，确认积分累计到等级升级线后，等级自动从普通变为银卡，折扣从 1.0 变为 0.9；再用同一手机号重复开卡，确认系统拦截“该手机号已注册”。每一步都做好截图，答辩时放出来，比任何口头描述都有说服力。
关于代码规范和重构，我强烈建议你把 controller 层的命名统一成 RESTful 风格：/member/add、/member/list、/record/consume，而不是原项目中可能出现的/addMember.do这类老写法。这一步不改逻辑，但让代码“看起来”像一个现代 Java 工程。DAO 层的 SQL 也顺手做一遍格式化，缩进和大小写统一。不要小看这些表面功夫，毕业设计答辩时老师翻开代码，第一印象就是这里的整洁度。
我在带这个项目时有一个习惯：每改完一个模块，就用一个独立 Git 分支提交一次，比如feature/password-encrypt、feature/echarts-dashboard。这样哪怕改坏了也能随时回退，相当于给自己留后悔药。你也可以借鉴，养成版本管理习惯在后续工作中同样受益。最后提醒一句：不要因为运行成功就松懈，把以上流程完整走一遍，确保任何一步都能向老师讲清楚“为什么这样做”，这个项目才是真正属于你的。希望帮到你，祝你答辩顺利。
本文还有配套的精品资源，点击获取
