基于JSP的服装商城交易管理系统设计与实现

简介：一份围绕基于JSP的服装商城交易管理系统设计与实现的答辩演示文稿，面向计算机相关专业毕业生及需要进行系统类课程设计或毕业答辩的学生。资源从选题意义、课题背景、系统功能目标到技术方案逐步展开，重点覆盖JSP与Servlet在业务逻辑处理、服装商品管理与订单交易流程中的应用，并结合数据库设计和前端交互说明商城系统的整体构建思路。

压缩包内含1个pptx文件，大小约739KB，为答辩专用PPT资料，适合直接用于答辩结构参考、PPT框架对照以及系统实现思路梳理。已有137人学习下载，是针对性较强的毕业设计辅助资源。

该材料能帮助读者快速掌握服装商城系统在前后台模块划分、会员与卖家管理、购物流程实现等方面的设计要点，理解从需求分析到编码实现再到测试维护的系统化开发流程，为独立完成类似Web商城项目或准备答辩展示提供有价值的思路参考。

1. 这个基于jsp的服装商城交易管理系统，答辩前要把技术栈先想明白

基于jsp的服装商城交易管理系统之所以能常年霸榜毕设选题，不是因为JSP技术多新，而是因为它足够旧、足够稳、足够好答辩。这套系统的标准形态是：Servlet控制请求，JSP输出页面，JDBC连MySQL，最后打成一个war包丢进Tomcat跑起来。相比Spring Boot全家桶加Vue前后端分离，这种传统JavaWeb项目不需要回答“你怎么理解微服务”“前端跨域怎么解决”这类问题，技术栈边界清晰，一个本科生在两个月内能完全讲明白。适合的人群很明确：要交JavaWeb方向毕业设计、还没有稳定项目可用的人。它真正解决的三个问题是商品怎么展示、购物车怎么存、订单怎么流转。把这三条线在答辩现场讲清楚，才算没白做。

2. 从需求到数据表：服装的颜色尺码决定了你这套系统要建几张表

很多照着“设计与实现”题纲做的人，上来就画页面，画到购物车一栏发现事情不对：一件衣服同时有黑色和白色、有S到XL四个码，到底是一条商品还是一个商品？这个纠结背后就是服装商城和图书商城最大的差别——图书只有一本和一套的区别，服装有颜色尺码的笛卡尔积。数据库建错，后面所有代码都跟着别扭，所以设计阶段要先定表。

2.1 用管理员、用户、订单三条线拆解功能模块

“交易管理系统”不是“商品展示网站”，所以功能拆分要围绕交易闭环来。常见的分解方式是三条线：

用户线：注册登录、浏览商品列表、按分类筛选、把商品加入购物车、提交订单、模拟支付、查看订单、确认收货、个人信息展示与修改。这里“个人信息展示页面”会放在用户中心里，单独一个JSP就够，别为了它单独做一套权限体系。

管理员线：后台登录校验、商品上下架、新增和编辑商品、维护SKU库存、订单列表、订单发货。注意管理员和普通用户不要混在同一张表里用type字段区分后又在代码里到处if判断，直接分裂成admin_user和user两张表，答辩时好讲，实现也省心。

订单线：购物车结算生成订单、订单状态随时间推进、库存随订单状态回补。订单线是核心，后面第4章会专门展开。

功能模块图上就画这三条线，配合一页PPT说明“登录注册这类功能属于基建，交易闭环才是系统的核心”，评委就知道你不是只会堆功能。

2.2 服装SKU设计：颜色尺码不能直接塞进商品表

把“黑色M码”和“白色L码”当成两个商品各建一条记录，是最常见的翻车设计。看起来能用，但等你做“同款不同色的商品详情页”就只能靠标题匹配，库存统计也会乱套。正确做法是把商品拆成两层。

第一层叫商品（t_goods），描述“这一款衬衫”，包括名称、分类、基准价、封面图。第二层叫SKU（t_sku），描述“这款衬衫的黑色M码”，包括颜色、尺码、独立库存、可覆盖价格。购物车和订单明细都应该挂在SKU上，而不是挂在商品上。这样“黑色断货但白色有货”“S码卖完了M码还能下单”这两个真实场景才表达得出来。

一个常见的偷懒替代是“把颜色尺码拼成一个字符串，比如‘黑色-M’，存在商品表的spec字段里”。这种设计写库存更新SQL时极易出错，答辩时被追问“你怎么统计每个尺码的销量”会很被动。宁可多建一张表，也别在字段里拼字符串。

2.3 建表SQL模板与E-R图的画法

下面这组建表语句是我建议的最低配置，五张表：用户表、商品表、SKU表、订单表、订单明细表。地址我建议直接存用户在user表里，或者单独建一张收货地址表，按自己需求取舍，这里先给出最核心的五张。

-- 用户表 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(30) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, -- 答辩演示用MD5即可，别明文 nickname VARCHAR(30), phone VARCHAR(11), address VARCHAR(200), create_time DATETIME DEFAULT NOW() ); -- 商品表：描述“这一款衣服” CREATE TABLE t_goods ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, category VARCHAR(20) NOT NULL, -- 上装/裤装/裙装/配饰 price DECIMAL(10,2) NOT NULL, -- 基准价，详情页展示用 image VARCHAR(255), status TINYINT DEFAULT 1, -- 1在售 0下架 create_time DATETIME DEFAULT NOW() ); -- SKU表：描述“这款衣服的黑色M码” CREATE TABLE t_sku ( id INT PRIMARY KEY AUTO_INCREMENT, goods_id INT NOT NULL, color VARCHAR(20) NOT NULL, size VARCHAR(10) NOT NULL, -- S/M/L/XL stock INT NOT NULL DEFAULT 0, -- 库存必须在SKU这层 price DECIMAL(10,2), -- 可覆盖基准价，为空则用t_goods.price CONSTRAINT uk_sku UNIQUE (goods_id, color, size) ); -- 订单表 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 TINYINT NOT NULL DEFAULT 0, -- 0待付款 1待发货 2待收货 3已完成 4已取消 create_time DATETIME DEFAULT NOW(), pay_time DATETIME NULL, finish_time DATETIME NULL ); -- 订单明细表：冗余一份商品快照 CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, sku_id INT NOT NULL, goods_name VARCHAR(100) NOT NULL, -- 下单时的商品名 color VARCHAR(20), size VARCHAR(10), price DECIMAL(10,2) NOT NULL, -- 下单时的成交价，不能用当前价顶替 quantity INT NOT NULL );

参数说明：金额一律用DECIMAL(10,2)，不要用float，否则累计金额会漂移；状态字段用TINYINT，并约定一个注释写明状态含义，比用字符串稳；t_order_item里冗余goods_name和price是刻意设计——订单发生后商品如果改名调价，历史订单仍然能显示当时购买的信息，这就是快照思想。库存字段stock只出现在t_sku上，除此以外任何表的库存字段都是画蛇添足。

E-R图画法建议：PPT上画核心关系就够了，不用把全部字段画上去。用四个矩形：用户、订单、商品、SKU，用连线标注关系：用户与订单是1对N，订单与订单明细是1对N，商品与SKU是1对N，SKU与订单明细是1对N。别忘了在图上标“购物车不入表，保存在Session”，这一句话能挡住评委关于“购物车表在哪”的追问。画图工具用PowerPoint本身的形状或者draw.io都可以，关键是关系清晰、字体一致。

提示：如果时间紧张，删掉category做成纯字符串字段也能跑，但“按分类筛选”功能就没了。分类要么单独建表，要么用固定字符串枚举，看PPT里你承诺了什么功能，承诺了筛选就必须有支撑。

3. 用Servlet+JSP跑通“加入购物车到下单”：三层架构下的核心链路

“基于jsp”不等于所有页面都是JSP，更不等于逻辑也写在JSP里。常见做法是把项目拆成三层：JSP负责展示和收集参数，Servlet负责接收请求和跳转，Service加Dao负责业务与数据库。这里说的Servlet+JSP就是Controller加View的组合，别让JSP里出现JDBC代码，那种写法答辩时一翻源码就露馅。

3.1 三层架构与项目目录结构

用IDEA新建一个Java Web项目时，别选Spring Initializr，那会引出一堆你不熟悉的依赖。直接新建普通Java工程，再添加Web Application支持；代码最终要打包成war，所以Project Structure里Artifacts要选Web Application Archive。包结构建议固定成这样：

src/main/java ├── com.shop.entity -- User, Goods, Sku, Order, OrderItem 纯POJO ├── com.shop.dao -- 每个实体一个Dao，JDBC访问 ├── com.shop.service -- 购物车、下单、库存这类业务逻辑 ├── com.shop.servlet -- 所有HttpServlet子类，按功能分 ├── com.shop.filter -- 编码过滤器、登录检查过滤器 └── com.shop.util -- DBUtil、分页工具、订单号生成器 src/main/webapp ├── css / js / images -- 静态资源 ├── jsp │ ├── goods -- 商品列表页、详情页 │ ├── cart -- 购物车页面 │ ├── order -- 订单确认、订单列表、支付模拟 │ └── user -- 登录、注册、个人信息展示页面 └── WEB-INF/web.xml

这个结构的好处是答辩时好讲“分层”：Servlet永远不直接写SQL，Dao永远不处理页面跳转，Service层承担事务边界。用Tomcat本地调试时，直接把war扔进webapps目录，访问路径记得要带上下文名，比如http://localhost:8080/shop/jsp/goods/list.jsp。

3.2 加入购物车的Servlet：用Session当购物车，别急着建表

购物车最大的争议点在于要不要落地到数据库。我的建议是不要。购物车是“用户还没有确认的购买意图”，用户完全可能关掉浏览器就不回来了，为它建表、做增删改查会浪费大量时间；用HttpSession存购物车，代码简单且体现了“会话级状态”这个概念，答辩时能自圆其说。购物车的数据结构选择HashMap，key是skuId，value是数量。

@WebServlet("/cart/add") public class AddCartServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { // 参数校验：skuId和数量必须是合法数字 int skuId = Integer.parseInt(req.getParameter("skuId")); int num = Integer.parseInt(req.getParameter("num")); if (num <= 0) num = 1; // 购物车是会话级数据，不是数据库数据 HttpSession session = req.getSession(); Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart"); if (cart == null) { cart = new HashMap<>(); session.setAttribute("cart", cart); } // 同一SKU再次加入时累加数量，而不是覆盖 cart.put(skuId, cart.getOrDefault(skuId, 0) + num); // 重定向到商品列表，避免刷新后重复提交 resp.sendRedirect(req.getContextPath() + "/goods/list"); } }

逻辑说明：第一步读参数并做数字校验，Integer.parseInt如果碰上非法输入会抛异常，真正项目里要包一层try-catch返回错误提示；第二步从Session里取购物车Map，取不到就初始化；第三步用getOrDefault做数量累加，解决了“重复点击加入”会覆盖数量的问题；第四步用重定向而不是转发，因为转发时浏览器地址栏不变，用户一按F5，同一个POST请求又发了一遍，购物车数量翻倍，这是典型的“重复提交”翻车。

参数说明：skuId必须对应t_sku表主键，不是t_goods表主键。前端商品详情页的“加入购物车”按钮应该把当前选中的颜色尺码组合对应的skuId传给这个Servlet，如果页面只传了商品id，那“黑色M码加2件、白色L码加1件”就全揉在一起了。

读取购物车的时候，页面不能只显示一个“skuId:数量”的Map，那太丑了。常见做法是先拿到所有skuId，去查t_sku联t_goods，把商品名、颜色、尺码、单价和数量拼成一个可展示的对象。这一层查询可以放在CartService里，Servlet拿到组装好的List再转发到购物车JSP。

3.3 JSP页面传参：request、session、URL三条路怎么选

新手最容易搞混的就是JSP之间怎么传值。我见过有人在登录页面把用户名拼在URL里带到下一个页面，结果中文全部变乱码，这就是没分清楚三种传参的适用场景。

request传参，配合forward转发使用，生命周期只有一次请求。典型场景：Servlet查完商品详情，用request.setAttribute("goods", goods)转发给goodsDetail.jsp，页面用EL表达式${goods.name}显示。页面刷新后数据丢，这是预期行为，因为是“单次请求内的临时数据”。

session传参，生命周期是整段会话，适合放登录用户、购物车、下单前需要跨页面保存的信息。个人中心这类“个人信息展示页面”从session里取登录用户，也是这个套路。session别什么都塞，放十几个key以后排查问题非常痛苦。

URL传参适合分页页码、商品分类ID这类轻量参数。中文参数放URL里需要URLEncoder编码，否则Tomcat会按ISO-8859-1解码导致乱码。能用表单POST传递的数据，就不要走URL。

购物车页面用JSTL遍历的代码长这样：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <c:forEach var="item" items="${cartItems}"> <tr> <td>${item.goodsName}</td> <td>${item.color} / ${item.size}</td> <td>${item.price}</td> <td>${item.quantity}</td> <td><a href="${pageContext.request.contextPath}/cart/remove?skuId=${item.skuId}">删除</a></td> </tr> </c:forEach>

注意两点：第一，${pageContext.request.contextPath}必须挂在所有链接前面，它等于部署后的上下文路径“/shop”，少了它删除链接会变成/cart/remove，直接404；第二，cartItems需要Servlet提前setAttribute，JSP里只用EL表达式读取，不要在JSP里写Java代码段拿数据库，否则项目分层就崩了。

提示：JSP页面顶部务必写pageEncoding="UTF-8"，连同后面要讲的编码过滤器一起做，可以挡住大半乱码问题。

4. 订单状态机与库存扣减：交易系统在答辩现场最容易翻车的三个追问

订单管理和库存扣减是“交易管理系统”里最像真实业务的部分，也是评委提问概率最高的地方。很多人的系统能演示，但被问到“如果用户下单不付款怎么办”“两个人同时买最后一件怎么处理”就答不出具体机制了。这一章把这两件事讲透。

4.1 订单状态怎么流转：先定状态机，再写代码

订单状态用TINYINT字段表示，含义固定，别用字符串“已支付”这种中文值，省得比较时大小写不一致。状态流转关系如下。

代码里推荐用常量类或者枚举定义这套状态，比如OrderStatus.PAID = 1。更新状态的SQL很简单，但要注意加条件：UPDATE t_order SET status = 2, finish_time = NOW() WHERE id = ? AND status = 1。这个WHERE status = 1是防止管理员对已经取消的订单重复发货，属于幂等保护。答辩时主动说出“状态迁移都带前置状态条件”会让评委觉得你考虑过并发。

4.2 扣库存的时机：下单即扣还是支付后扣

这个决定直接影响库存一致性。常见做法有两套：

方案一是下单即扣。用户在订单确认页点击提交，系统检查库存、扣减库存、生成订单。之后用户如果不付款，需要超时任务或手动取消来回补库存。优点是流程线性，下单瞬间就能确定库存归属，不会超卖；缺点是未支付的订单会占着库存。

方案二是支付后扣。先创建订单不扣库存，支付成功回调里再扣。优点是库存不会被无效订单占用，缺点是支付成功那一刻可能库存已经没了，你得处理“支付成功但没货”的补偿逻辑，对毕设来说复杂了。

毕设建议选方案一，答辩口径是“下单即锁定库存，取消订单时回补，保证不会出现超卖；未支付订单占用的库存通过订单超时取消来释放”。这个口径完整且有取舍说明。注意实现细节：取消订单要回补库存，最简单的做法是在“取消订单”的Service方法里，把该订单的明细表查出来，逐条执行UPDATE t_sku SET stock = stock + quantity WHERE id = ?，同事务提交。

4.3 防超卖：一条带条件的UPDATE，别上来就搞Redis

两个用户同时买最后一件库存为1的商品，如果用“先select查库存，大于0就update”，两个请求都可能查到1，然后各自都扣，库存变-1。这不是什么高深并发问题，而是检查与扣减之间差了原子性。数据库层面的解法非常简单：让扣库存UPDATE自带条件。

public boolean deductStock(Connection conn, int skuId, int num) throws SQLException { // 注意两个关键点：stock = stock - ? 的赋值式自减；WHERE里带 stock >= ? String sql = "UPDATE t_sku SET stock = stock - ? WHERE id = ? AND stock >= ?"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, num); ps.setInt(2, skuId); ps.setInt(3, num); int rows = ps.executeUpdate(); return rows > 0; // 0行说明库存不足，扣减失败 } }

逻辑说明：UPDATE语句在InnoDB下会对命中行加行锁，两个并发事务先后执行同一条SQL时，后面那个等锁释放后再执行，此时stock已经扣过了，WHERE stock >= ?不满足，受影响行数为0，事务回滚，就永远不会扣成负数。这比“先查后改”安全得多，也比在Java代码里加synchronized靠谱，因为synchronized只在一个Tomcat实例内有效，而数据库锁是跨实例的。

调用这段代码时，必须和订单插入放在一个事务里。JDBC原生写法：conn.setAutoCommit(false)，执行扣库存和插入订单，全部成功再commit，任何一步抛异常都rollback。如果你用了MyBatis或者Spring的@Transactional，由框架管理事务边界；但很多传统JSP项目直接用的JDBC，那就必须自己控制conn，千万别在Dao里每次单独拿一个连接，那样订单写成功了库存却扣失败，数据就彻底对不上。

再补一个“够用”的并发量说明：这套机制在单机MySQL下支撑几百并发没问题，答辩时如果被问“为什么不加分布式锁”，可以回答“系统是单体应用，并发压力集中在数据库层，当前设计在数据库内部完成原子扣减；引入Redis加锁会增加缓存与DB一致性的维护成本，与系统规模不匹配”。这是一个主动划清边界的口径，不是认怂。

注意：订单取消回补库存要复用同一套事务逻辑，不能直接在页面里UPDATE。常见错误是管理员取消订单时只改状态，不回补库存，演示几天后库存悄悄变成0。

5. 答辩演示与部署排查：常见问题清单与现场避坑

系统跑通只是第一步，答辩现场能稳定演示才是终局。下面五条全是这类项目里反复出现的故障，每一条都按“现象、原因、解决”写清楚，演示前照着排查一遍。

5.1 页面中文乱码这种“玄学”

现象：商品列表里中文显示成问号，用户注册提交的用户名存进去就是乱码，有时候本地正常、换到答辩机器上就乱。

原因：编码问题不是一个点，而是一条链。JSP页面本身的编码、Servlet接收POST参数的编码、JDBC连接MySQL时的编码、Tomcat接收GET请求参数的编码，任何一环不一致，结果就是乱码。为什么本地正常？因为IDEA里默认统一了编译器编码，而打包后部署在别的Tomcat上，环境变了。

解决：从上到下统一UTF-8。JSP头部写pageEncoding="UTF-8"；写一个EncodingFilter拦截所有请求，在doFilter里调用request.setCharacterEncoding("UTF-8")；JDBC的URL加上?useUnicode=true&characterEncoding=UTF-8；再不行就改Tomcat的conf/server.xml，给Connector加上URIEncoding="UTF-8"。一个过滤器就能解决POST，GET乱码要靠最后一条。不要在一堆页面里反复写setCharacterEncoding，那不是治本，是碰运气。

5.2 部署war后CSS和图片全部404

现象：在IDEA里启动Tomcat页面样式正常，打包成war放到webapps下再访问，页面变成了纯HTML没有样式，控制台一堆css文件404。

原因：静态资源路径写成了相对路径，比如href="css/style.css"，而项目部署后带上下文路径，浏览器实际请求的是/css/style.css，而文件在/shop/css/style.css。IDE里的debug运行有时会自动处理上下文路径，所以本地看不出来。

解决：把所有静态资源、表单action、跳转链接全部改成${pageContext.request.contextPath}开头的绝对路径，也就是${pageContext.request.contextPath}/css/style.css。搜一遍所有jsp文件里的href、src、action，看到没有contextPath前缀的一律改掉。演示前单独用“打包war部署”的方式跑一遍全流程，不要只在IDEA里点运行，因为答辩现场用的就是war部署。

5.3 答辩现场“数据库连不上”

现象：点击登录一直转圈，控制台或Tomcat日志报Communications link failure、Connection refused，过一会页面白屏。

原因：MySQL服务没启动。最常见的是演示机器重启过，MySQL没有设为开机自启；其次是3306端口被别的进程占用，或者防火墙拦截了连接。还有一个隐蔽原因：JDBC URL写死了某个IP，而现场机器换了一台，IP对不上。

解决：演示前检查MySQL服务并设为自动启动，Windows系统在services.msc里把MySQL服务的启动类型改成“自动”，这样开机就有。JDBC连接串里的host直接写localhost，别写本机IP。关掉MySQL机器上的防火墙或者放行3306端口。答辩前一天的检查动作务必包含“重启一次电脑，从开机状态启动Tomcat和MySQL，完整跑一遍下单流程”，这一项执行到位，80%的现场事故都能避免。

5.4 演示过程中购物车突然空了

现象：前一步还看到购物车里有三件衣服，点了结算再回到购物车页面，一条记录都没有，好像被清空过。

原因：购物车存在Session里，Session失效就会丢。Session失效的触发条件有三个：超过超时时间，Tomcat重启，浏览器关闭Session Cookie失效。答辩现场最容易触发的是前两个——你翻PPT太久没操作系统，Session到期；或者演示中Tomcat因为内存溢出自动重启了。

解决：在web.xml里把Session超时调大，默认30分钟对演示不够宽裕。写法是：

<session-config> <session-timeout>60</session-timeout> </session-config>

同时把Tomcat的JVM内存调大，在Tomcat/bin目录下的catalina.bat里设置CATALINA_OPTS=-Xmx512m。演示时的操作习惯也要改：不要在翻PPT时干等着，把“商品已经加好购物车”这件事放在上台之前最后一步做，加完购物车就切到演示页，减少Session静默过期的时间窗口。

5.5 评委问“你的系统跟淘宝差在哪”答不上来

现象：服装商城几乎是必被问这类问题，很多人支支吾吾说“功能上还差很多”，然后被追问“具体差在哪”，场面很被动。

原因：不是功能真的差太多，而是你没把系统的技术边界讲清楚，显得不懂取舍。

解决：提前准备三段固定口径。支付：系统采用模拟支付流程，真实对接支付宝/微信需要商户资质与回调接口，核心的订单状态流转已经实现；并发：单体应用，通过数据库条件更新与事务保证库存不超卖，引入Redis分布式锁会带来新的数据一致性问题，与当前系统规模不匹配；安全：密码存储做了MD5加盐，生产级系统会用BCrypt，短信验证码、实名认证等功能属于业务范围内可裁剪项。说完这些再主动补充一句“选题时做了裁剪，把核心交易闭环做完整”——这比被追问一句答一句强得多。

6. 把设计与实现的闭环讲清楚：答辩PPT的结构与最后一页

PPT页数控制在12到15页，别做三十页的说明书，评委没耐心。我建议的结构是：标题页一页，讲清楚题目和项目定位；选题背景与技术选型一页，解释为什么用JSP而不是Spring Boot，口径是“聚焦Servlet/JSP原生技术，便于展示JavaWeb底层原理”；功能模块一页，放三线图；数据库设计两页，一页ER图，一页核心表清单；核心流程两页，第一页画“加入购物车到提交订单”的时序图，第二页讲订单状态机；系统截图三到四页，每张截图配一句标注，比如“库存由SKU表管理，黑色M码与白色L码互不影响”；核心代码一页，就贴条件更新防超卖那六行；测试结论一页，列功能测试用例表；最后一页是总结与展望。

最后一页别只放“谢谢聆听，请各位老师指正”，那页应该放一张闭环图：左边是t_goods和t_sku两张表，中间是购物车Session和t_order、t_order_item，右边是订单状态机，图上三条箭头串起“商品从数据库到页面、购物车从Session到订单落库、订单状态随时间迁移”。这张图一放，答辩时你只需要顺着箭头把系统讲一遍，评委就能看到你同时理解了设计端的数据模型和实现端的运行流程，这比任何一句“我做了完整的设计与实现”都有说服力。

我的个人教训是：答辩演示前一定要做一次“断网、清空Tomcat、手动启动MySQL”的完整演练，我当年把心思都花在美化PPT上，结果现场第一次点登录就撞上数据库服务没启动，那三十秒的等待比任何一页PPT都让人印象深刻。检查清单就三行——MySQL开着吗，Tomcat起来了吗，页面能不能加到购物车并下单成功。把这三行确认完再上讲台，希望帮到你。

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