1. 项目先拆明白：这个“尤文图斯网上商城”到底在做什么
1.1 选题背景与需求场景还原
先说结论：jspm尤文图斯足球俱乐部网上商城系统，是一个典型的电商类Java Web毕业设计项目。标题里的“jspm”不是某个高深框架，而是这类老牌毕设题目习惯性的命名方式——本质是JSP + Servlet + MySQL的技术组合，有的学校写成jspm，有的写成jsp+mysql，都指同一条技术路线。
我前前后后带过不少做这类题目的学生，最深的感受是：很多同学拿到题目第一反应是“尤文图斯？是不是要爬意甲数据？是不是要对接俱乐部官网？”完全不用想这么复杂。毕设题目的核心就两个字——商城。尤文图斯只是给商城套了个体育IP的场景。
为什么说这个选题聪明？因为电商系统是毕设界的“常青树”，需求特别标准，但标准归标准，如果做成“通用商城”，答辩老师会觉得没有记忆点。加上“尤文图斯足球俱乐部”这个限定词之后，整个系统的定位就清晰了：一个面向球迷的纪念品与周边装备在线商店。商品可以是球衣、围巾、钥匙扣、纪念册、训练服，顾客是球迷，订单要支持收货地址填写，后台要给管理员一个上下架、发货的入口。业务线非常完整，但是又不需要碰那些复杂的真实电商环节，比如第三方支付对接、直播带货、优惠券算法，范围控制得刚刚好。
把需求还原成一句话：做一个让球迷能注册、浏览商品、加购物车、下单，让管理员能维护商品、处理订单、管理会员的小型网上商城系统。这就是主战场。
1.2 功能需求拆解
前台和后台是两块，建议画功能结构图的时候直接从这两个角色往下拆。
前台（面向普通用户）：
- 用户注册与登录：用户名、密码、手机、邮箱，注册时做基础校验，登录后session记录用户身份。
- 商品浏览与检索：首页展示热销商品，商品列表支持按分类筛选、按名称模糊搜索，还有分页。分页不要偷懒，评委大概率会问页码逻辑。
- 商品详情：展示图片、价格、库存、商品介绍，旁边给出“加入购物车”按钮。
- 购物车：加入商品、修改数量、删除条目、统计总价、批量结算。这里有代表性，评委会追问“购物车放session还是放数据库”。
- 订单流程：确认收货人地址、生成订单、查看订单列表和订单详情，支持取消未处理订单。
- 个人中心：修改个人资料、查看自己订单、修改密码。
后台（面向管理员）：
- 管理员登录：独立账号体系，不跟用户表混在一起。
- 商品管理：添加商品、编辑商品、上架/下架、删除商品。这里的核心是库存与图片处理。
- 订单管理：按状态查看订单、标记发货、取消订单。
- 用户管理：查看注册用户列表，禁用账号。
- 公告管理：发布商城公告，前台首页轮播或公告栏展示。
- 数据统计：简单统计销售总额、订单数量，作为加分项，做一个top5热销商品就足够让评委眼前一亮。
我见过很多同学做这类项目，把重点全压在“前台页面花不花哨”上，结果后台就只有一句“支持增删改查”，导致论文工作量撑不起来。实际上，一个完整的商城系统，后台的深度往往比前台重要，因为在论文里能写“订单状态管理”、“多表关联查询”、“事务控制”这些词，都是靠后台模块撑起来的。
1.3 角色与权限边界
系统里至少有两类角色：管理员和普通用户。管理员不能走用户端注册通道，需要在数据库里预置admin账号，密码建议用MD5加密存储。普通用户注册之后，默认是正常状态，被管理员禁用的用户无法登录。
权限控制在Java Web里最轻量的方案就是Filter。写两个过滤器：一个拦截所有 “/admin/” 路径，检查session里有没有admin对象，没有就跳回管理员登录页；一个拦截用户下单类的操作，比如 “/order/”，检查用户是否已登录，未登录引导到登录页。把权限拦截逻辑集中到Filter里，比在每个Servlet里写一遍if判断好维护得多，也更容易在论文里讲清楚。
2. 技术选型：jspm这套组合为什么能打
2.1 jspm到底是什么：JSP+Servlet+MySQL的经典路线
这个要讲清楚。很多同学看到标题里的“jspm”会发懵，以为是某个冷门框架。其实在毕业设计题目库里，“ssm”、“ssh2”、“jspm”这一类都是缩写的习惯用法。jspm在绝大多数情况下指的是JSP + Servlet + MySQL的组合，有时会额外覆盖JDBC和JSTL。项目代码结构一般就是：JSP页面负责展示，Servlet负责接收请求、调用逻辑、转发或重定向，DAO层用JDBC访问MySQL数据库。
为什么这种组合到现在还有人用在毕设里？因为好讲、好答辩。Spring Boot现在确实主流，但是纯Spring Boot项目里，很多同学连请求到Controller再到Service再到Mapper这条链路都说不明白，更别说底层发生了什么。JSP+Servlet的每个环节都是透明的：浏览器请求Servlet，Servlet里读参数，调DAO，DAO里写SQL，拿到结果放进request，转发到JSP渲染。一套链路短，代码量可控，评委怎么追问都不容易翻车。
2.2 为什么不用Spring Boot
这个问题基本是答辩必问。你如果选了jspm路线的技术栈，一定要准备好答案，核心理由分三层：
第一，毕设考察的是原理理解，不是框架运用。JSP+Servlet能直接体现HTTP请求生命周期、Session管理、JDBC事务这些最基础的东西，这些底层能力到了任何框架里都通用。
第二，项目规模决定技术选型。这个商城系统看起来模块多，但用户量是演示级别的，并发量按个位数算。Spring Boot带来的自动配置、内嵌容器、依赖管理优势在这个体量下发挥不出来，反而会引入“为什么用这个注解”的新问题。
第三，源码可读性。这套系统带了完整源代码，最重要的一定是“能看懂”。结构越简单，二次开发越容易，碰到问题了，自己翻源码就能定位到Tomcat报错对应的那一行。
当然，如果你时间充裕、基本功也到位，用Spring Boot重写同一个系统是加分操作。但如果是毕业设计求稳，经典路线更香。
2.3 环境与版本搭配，照着配就行
这是我的标准配置，稳定跑通过几十个项目：
- JDK 1.8
- Tomcat 8.5 或 9.0
- MySQL 5.7 或 8.0
- Eclipse IDE 或 IntelliJ IDEA
- Navicat 或 MySQL Workbench 做数据库可视化
- JDBC驱动：mysql-connector-java 5.1.49（MySQL 5.7）或 8.0.x（MySQL 8.0）
这里特别提醒：MySQL 8.0以后，JDBC驱动类名从 com.mysql.jdbc.Driver 换成了 com.mysql.cj.jdbc.Driver，连接URL还要加 serverTimezone=Asia/Shanghai。很多同学栽倒的第一个坑就是这个，后面第6部分我会展开说。
Tomcat版本也要注意。如果你用的是Tomcat 10及以上，里面已经换成了Jakarta EE规范，很多老项目里的 javax.servlet 包会直接报ClassNotFoundException。稳妥起见，就用Tomcat 9及以下版本，完全够用。
整体架构图不用折腾画得太复杂，就是三层：表现层(JSP) + 业务控制层(Servlet) + 数据访问层(DAO/MySQL)。画到论文里，评委最认这种清晰简单的分层。
3. “懂球又懂货”：数据库设计是商城的骨骼
3.1 核心表结构设计
一个商城系统的数据库，其实万变不离其宗。我直接给出这个项目的核心表，你可以对着建库：
用户表 user：id（int自增主键）、username（varchar，唯一）、password（varchar，存MD5值）、phone、email、status（1正常/0禁用）、create_time。
商品表 goods：id、name（比如“尤文图斯2024主场球衣”）、category_id（外键指向分类表）、price（decimal(10,2)，价格用decimal，别用float）、stock、image（图片路径）、description、status（1上架/0下架）、sales（累计销量）。
分类表 category：id、name，就这么简单。商品和分类是多对一关系。
购物车表 cart：id、user_id、goods_id、quantity、加购时间。一个用户对同一个商品重复加购时，不要插两条记录，update数量就好。
订单表 orders：id、order_no（订单编号）、user_id、total_price、consignee（收货人）、phone、address、status、create_time。
订单明细表 order_item：id、order_id、goods_id、goods_name（快照）、price（快照）、quantity。为什么要快照？因为下单之后，商品可能改名、改价甚至删除，但订单里必须保留“当时买的是什么、多少钱”。这个细节在答辩时非常加分。
管理员表 admin：id、username、password。
公告表 notice：id、title、content、create_time。
这个表结构不复杂，但每一个字段都有存在的理由。我特别强调两点：一是订单表里订单号和ID要分开，ID是自增主键，order_no用业务规则生成，后面下单模块会讲到；二是订单明细表一定要存商品名称和价格的快照，这不是多余的字段，而是电商系统的行业常识。
3.2 购物车设计的两种方案
购物车是答辩高发问题，你要提前想好。方案一：把购物车数据放在Session里，用户加购、改数量都操作Session里的List。优点是实现简单、不落数据库，缺点是游客刷新或换浏览器就丢数据，而且购物车没法跨设备同步。方案二：把购物车存进数据库表cart，以用户ID关联。优点是用户登录后购物车永久保存，能体现你数据库操作的完整性，缺点是代码量多一些。
做毕设，我强烈推荐方案二。原因不是方案一不行，而是论文需要。数据库版购物车，你在论文里可以写“购物车模块基于用户ID关联查询，实现购物车商品持久化存储”，这句话是有技术含量的；Session版就只能写“购物车数据暂存于会话对象”。评委会怎么打分，高下立判。
3.3 订单状态流转
订单状态不要用语义不明确的字符串，用int存储，在Java里定义常量，或者写一个枚举类。这个项目建议的状态是：
| 状态值 | 含义 | 说明 |
|---|---|---|
| 0 | 待支付 | 刚下单，用户可以取消 |
| 1 | 已支付/待发货 | 模拟点击支付按钮后进入，管理员可发货 |
| 2 | 已发货 | 管理员执行发货操作后进入 |
| 3 | 已完成 | 整个流程走完的最终状态 |
| 4 | 已取消 | 用户或管理员取消订单 |
演示的时候，一个订单至少要走一遍“下单→支付（这里可以简化成点击立即支付按钮模拟）→发货→完成”的完整闭环。在演示视频里这步不能跳，因为这是整个系统最漂亮的业务流。
4. 前台核心链路实操：从商品列表到下单支付
4.1 商品列表的分页与检索
前台首页其实不用花哨，用一张数据表格或卡片网格展示商品就行。分页逻辑是必考点，用SQL的LIMIT来完成：当前页码page传进来，每页显示pageSize条，查询语句就是 SELECT * FROM goods WHERE status=1 LIMIT #{offset}, #{pageSize}，offset = (page - 1) * pageSize。
在JSP页面上，商品列表用一个forEach标签循环输出，下面放“上一页”“下一页”链接，链接里带上当前页码和搜索关键词。这里有个小细节：搜索的时候，keywords参数要在分页链接里一直带下去，不然点第二页搜索条件就丢了。这个问题的解法是生成分页链接时把request参数拼回去，代码很简单，但在演示时非常容易露馅，要提前测。
检索功能的SQL核心是 WHERE name LIKE '%' #{keyword} '%'。如果想让检索再高级一点，可以加上 category_id 条件，形成“分类+关键词”组合筛选，答辩时有东西讲。
4.2 登录态与购物车
登录验证的代码逻辑很简单：登录页面提交表单到LoginServlet，Servlet里拿着username和password去查user表，密码要先MD5加密再比对，不能明文比对。查询成功就把用户对象放进session，键名用 “loginUser”，然后重定向回首页；失败就在request里放错误信息，转发回登录页显示。
这里把核心控制代码写出来，大家感受一下结构：
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String username = request.getParameter("username"); String password = MD5Util.md5(request.getParameter("password")); User user = userDao.findByUsernameAndPassword(username, password); if (user != null) { request.getSession().setAttribute("loginUser", user); response.sendRedirect(request.getContextPath() + "/index"); } else { request.setAttribute("msg", "用户名或密码错误"); request.getRequestDispatcher("/login.jsp").forward(request, response); } }购物车模块依附于登录态。用户加购时，AddCartServlet先从session取loginUser，取不到就提示“请先登录”，取到了就拿user_id去操作cart表。判断同商品是否已存在，用 SELECT id FROM cart WHERE user_id=? AND goods_id=?，有记录就UPDATE数量，没有就INSERT。
这里有一个体验细节：JSP页面上每个商品的“加入购物车”按钮，最好通过URL路径带goodsId传参，比如 cart/add?goodsId=3，而不是用隐藏表单域。URL传参在后期追踪问题的时候，浏览器地址栏一眼就能看到参数对不对，调试效率高很多。
4.3 下单的事务处理
下单是整个系统里技术要求最高的一个操作，它同时涉及多张表：orders、order_item、goods、cart，任何一个步骤失败，都不能留下脏数据，所以必须用事务。
核心流程在OrderServlet里的doPost方法中实现：
- 从session取出当前用户，从request取出收货人、电话、地址。
- 查询购物车列表，算出总金额。
- 生成订单号，插入orders表，拿到订单ID。
- 遍历购物车，逐条插入order_item。
- 扣减对应商品库存，同时更新销量：UPDATE goods SET stock=stock-?, sales=sales+? WHERE id=? AND stock>=?
- 清空当前用户购物车。
- 事务提交。
Java代码里，第一步是 conn.setAutoCommit(false)，所有步骤都在同一个Connection上执行，try里面正常跑完了conn.commit()，catch里conn.rollback()，最后finally里关闭资源。这段代码建议在论文里给一个简化版，配上事务流程图，会很加分。
强调扣减库存的那条UPDATE，WHERE条件里带上了 stock>=?。这是一个细节，也是一个技术亮点：它保证了“库存不够时不扣减”。如果库存不够，受影响行数是0，就可以直接抛异常，触发回滚。这比先SELECT查库存再判断要稳妥得多，不会出现两个人同时下单超卖的问题。
4.4 订单号生成规则
订单号别用int型主键，因为int最大21亿，演示看不出问题，但单号通常是展示给用户看的，直接用自增ID暴露了系统订单总量，不专业。而且自增ID是可预测的，也不安全。
常用的生成规则是：yyyyMMddHHmmss + 用户ID后4位 + 3位随机数，拼成一个String。比如 202605141530211234567，记录到orders表的order_no字段。这样订单号唯一性足够、有可读性，答辩时还能解释“生成规则”，又是一个小亮点。
5. 后台管理模块：工作量担当必须做扎实
5.1 管理员登录与权限校验
管理员登录跟前台用户登录原理一样，只是数据表换成admin表。登录成功后session里放 adminUser 对象。后台所有路径统一放在 /admin/ 下面，然后写一个 AdminLoginFilter 拦下这些路径。代码逻辑很简单：如果 session 里的 adminUser 是 null，就重定向到 /adminLogin.jsp，并且带一个 returnUrl 参数，登录成功后可以跳回原来的页面，体验更好。
这里要说一个很常见的翻车点：管理员不能从前台用户注册入口注册。很多同学图省事，管理员和用户共用一张表，靠一个role字段区分。这种设计不是不能用，但会让“用户管理”和“管理员管理”耦合在一起，答辩老师可能会问“你把管理员的密码修改入口放在哪里”，你自己很容易绕晕。分离表，思路清爽，安全边界也清楚。
5.2 商品管理：图片上传是重灾区
后台的商品管理包括列表、添加、修改、删除、上下架。添加和编辑页面是同一个表单，提交到同一个GoodsServlet，靠一个隐藏字段id判断是新增还是更新。
图片上传用Servlet 3.0自带的Part接口就能搞定，不需要引入第三方上传组件。前端表单要用 enctype="multipart/form-data"，Servlet里通过 request.getPart("image") 拿到文件，然后保存到服务器磁盘。这里有三个坑：
一个是文件保存路径问题。如果保存到Tomcat的webapps目录下，发布时使用war exploded模式的话，重启之后上传的图片还在，但如果重新部署就可能被清掉。更稳妥的做法是把图片存到项目外的固定目录，比如 D:/upload/，然后通过Tomcat配置映射成虚拟路径，让 /upload/** 指向这个目录。
第二个是文件名的问题。用户上传的原始文件名可能是中文，也可能带空格，直接拿来当存储文件名会404或乱码。要用UUID或时间戳重命名，扩展名从原始文件里截取。我常用的代码就这么几行：
Part part = request.getPart("image"); String fileName = extractFileName(part); String ext = fileName.substring(fileName.lastIndexOf(".")); String newName = UUID.randomUUID().toString().replace("-", "") + ext; part.write(newName);第三个是相对路径与绝对路径问题。数据库里存的image字段，存的是 /upload/xxx.jpg 这种相对访问路径，而不是磁盘绝对路径。页面显示的时候，用相对路径拼到域名后边就能访问。如果你把 D:/upload/xxx.jpg 这种绝对路径存进数据库，换个环境就全挂了。
5.3 订单管理与简易统计
订单管理页面把orders表全部查出来，按时间倒序排列，提供按状态筛选的下拉框。管理员对“已支付”状态的订单点“发货”，订单状态从1变成2。对“待支付”状态的订单，管理员也可以做“取消”操作，避免演示时用户端没有操作导致订单卡住。
简易统计是很容易被忽略但性价比极高的模块。在后台首页放三个数字：今日订单数、今日销售额、商品总数量，再加一个热销商品Top5列表。核心SQL是下面这样的，关联goods表取出名称和图片展示：
SELECT goods_id, SUM(quantity) AS total FROM order_item GROUP BY goods_id ORDER BY total DESC LIMIT 5;这几行SQL并不难，但让系统显得完整，论文里可以写“本系统实现了基础的数据统计与可视化辅助功能”，这是加分项。
6. 调试实录：最容易卡人的四个问题
6.1 JDBC驱动版本与驱动类名
这是遇到频率最高的问题。如果你用MySQL 5.7，JDBC驱动用5.1.49，驱动类名是 com.mysql.jdbc.Driver；如果你用MySQL 8.0，驱动类名必须是 com.mysql.cj.jdbc.Driver，而且连接字符串要长这样：
jdbc:mysql://localhost:3306/juventus?useSSL=false&serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8很多同学在MySQL 8.0环境里还在用老驱动类名，控制台直接报 ClassNotFoundException: com.mysql.jdbc.Driver，第一反应是去重新下载驱动，实际上就是类名写错了。另外，useSSL=false 这个参数最好带上，不然老版本MySQL会有一堆SSL警告刷屏。
6.2 中文乱码：三个位置缺一不可
商城系统里到处是中文，商品名是中文、收货地址是中文、公告是中文。乱码问题要从三个位置一起治理：
第一，JSP文件头部统一写 pageEncoding="UTF-8"，文件编码本身也要存成UTF-8格式，这步在IDE右下角可以设置。
第二，Servlet里所有doGet/doPost方法开头写上 request.setCharacterEncoding("UTF-8") 和 response.setCharacterEncoding("UTF-8")。尤其是request，如果不设置，POST提交的中文参数到Servlet里就是问号。
第三，数据库连接URL里加 useUnicode=true&characterEncoding=utf8，同时建库建表时指定 utf8mb4。utf8mb4比utf8更好，因为它支持更全的字符集，而且和utf8完全兼容。字符集三处对齐，中文字符串基本就不会乱了。
还有一个隐性坑：数据库连接池如果用的是c3p0或Druid，连接池里的连接可能用了错误的characterEncoding，需要重启Tomcat才能生效。排查乱码的时候别只改代码，改完配置要重启服务。
6.3 404问题：部署路径与页面链接不一致
用IDEA开发的时候，如果你把Artifact部署在 context path = /jspm_shop 这样的路径下，但页面上所有链接都是 /login、/goods/list这种以/开头的方式，那访问后台菜单就会全部404。最省心的方法是把部署的Application context设为 /，也就是根路径，这样页面里的 /login 就能直接打到项目上，不用在链接里拼项目名。
如果你要保留项目名路径，JSP里的链接就要用EL表达式动态拼接项目名，这种方式更规范，但新手很容易写漏。求稳就全部根路径部署。
6.4 演示过程中最容易翻车的现场
帮学生录演示视频的时候，最怕碰到三类现场事故：一是数据库服务没启动，页面白板一片；二是浏览器用的还是旧缓存，页面样式完全错乱；三是录到一半后台图片裂了。
解决方案很简单：录制前清一次浏览器缓存，或者用无痕窗口；数据库和Tomcat按顺序启动，先数据库后Tomcat；网站做成淡色简洁风格，别用太花哨的前端框架。视频录制工具用OBS或EV录屏都可以，分辨率建议1920x1080，码率别太低，不然答辩老师在大屏上看不清文字。
7. 毕业论文、PPT与演示视频，怎么把这些“周边材料”变成加分项
7.1 毕业论文的写作节奏
这个题目的论文结构一般按七章走：绪论（背景、意义、国内外研究现状）、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。其中最容易写得像流水账的是“相关技术介绍”，很多同学把JSP、MySQL词条解释一遍就结束了，评委会直接跳过。我的建议是每章都图多字少，用图表说话。
需求分析和系统设计部分，要放用例图和E-R图。E-R图不是可选项，是论文工作量评审的重点。画图工具用ProcessOn或者draw.io，画实体、属性和关系，然后把E-R图转成数据库表，论文逻辑就顺了。
系统实现部分不要把所有代码往论文里贴，挑选2到3个有代表性的代码段就行：一个事务处理代码、一个分页查询代码、一个图片上传代码。每个代码段周围一定要配文字说明“为什么这样写”，比如事务代码要写“本系统采用手动事务控制，避免库存扣减后订单插入失败造成数据不一致”。有解释的代码才有价值。
测试部分要写真实的测试用例表格，包括测试项、操作步骤、预期结果、实际结果。别只写“功能正常”，要写具体操作，比如“输入正确用户名密码，点击登录，页面跳转至首页，实际结果与预期一致”。
7.2 PPT的骨架设计
PPT控制在12到16页，别超过20页。顺序大概是：封面、目录、项目背景、需求分析、功能结构图、技术架构图、数据库设计（E-R图）、页面展示（前台）、页面展示（后台）、核心代码、系统测试、总结与展望。
这里我想强调一个很多人忽视的细节：页面展示部分不要放全屏截图，要裁剪，突出重点。同一张页面如果显得过于拥挤，你把商品列表页的图片、价格、加入购物车按钮单独裁出来放大，反而更专业。
答辩PPT绝不是念稿子，每一页PPT都要能对应到一个能现场演示的页面。评委最喜欢的答辩节奏是：你讲到哪个模块，就切到系统里直接演示哪个操作。所以PPT页数和系统演示的先后顺序要对齐，这个技巧叫“PPT和系统联动”，是答辩高分的核心。
7.3 演示视频录制脚本
演示视频要控制在30分钟左右，太长导师看不完。录制脚本我有固定模板，你直接套：
第一部分（约5分钟）：系统启动与前台首页展示。启动数据库，演示商品列表、分类筛选、关键词搜索、分页。
第二部分（约10分钟）：用户完整购物流程。注册新账号、登录、选择商品加入购物车、修改购物车数量、下单、模拟支付、查看订单状态。
第三部分（约10分钟）：后台管理流程。管理员登录、添加新商品（演示图片上传）、上架/下架、查看订单、发货、查看统计。
第四部分（约3分钟）：亮点代码展示。把事务代码和分页代码在IDE里展示一下，口述逻辑。
每一段录制前先写一份文字稿，哪怕不逐字念，也要把“这一步在做什么、为什么这么做”写清楚。视频里鼠标操作不要快，每点一步停顿一秒，让观看者的眼睛跟得上。音画同步很重要，我见过太多视频画面在讲A、嘴里在说B，这种视频答辩放出来基本等于自曝。
我个人在实际操作中的体会是：这类项目做得顺不顺，很大程度上取决于最开始两天。头两天把数据库表建好、把环境跑通，后面就是水到渠成的事；反过来，如果一上来就写代码，表结构改来改去，后面返工成本极高。
最后再分享一个小技巧：整个系统跑通之后，一定要亲手从头到尾走一遍“注册新用户→买一件商品→后台发货→用户确认完成”的完整闭环，不是走马观花，而是每一步都记下操作名称和页面截图。这套记录最后直接变成演示视频脚本和论文测试章节的素材，一举两得。尤文图斯商城这个题目，真正的价值在于它的表结构和业务逻辑具有极强的复用性——你把它改个皮肤就是球衣商城，改个分类就是图书商城，改个对象就是农产品商城。建好表，差不多就做完了一半；录好演示视频，答辩基本稳了。
