Java Web网上购物系统实战：JSP+Servlet+MySQL全流程开发

1. 项目整体设计与技术选型

1.1 这个项目到底在做什么

先说个直接的结论：Java Web网上购物系统，是所有走Java方向的人迟早要碰一遍的东西。不管你是刚学完Servlet/JSP的在校生，还是报了培训机构正在做结业项目的学员，几乎都会遇到类似题目。做它的核心意义在于：把散落的知识点（Servlet生命周期、JSP内置对象、JDBC操作、Session状态管理、MVC分层）全部串起来，变成一条完整的技术链路。很多人学Java基础时觉得什么都懂，一到动手写一个“能跑起来”的系统就卡壳，原因就是缺少这种综合性项目训练。

一个典型的Java Web购物系统，功能上要覆盖前台用户购物的完整闭环，同时还要有后台管理端的支撑。用户端至少包含注册登录、商品浏览、商品搜索、购物车管理、下单结算、订单查询；后台则包括商品管理、分类管理、订单处理、用户管理。如果做的是毕业设计，多数还会加上销量统计、会员等级这类锦上添花的功能。说句实在话，这类项目猛一看功能列表很长，真拆开来看，核心只有两条主线：一条是“商品从列表到购物车再到订单”的交易链路，另一条是“后台管理员对商品和订单的CRUD操作”。只要抓住这两条主线，整个系统就立住了。

标题里那个“11860”，结合我见过的项目编号风格，一般是指课程设计/毕业设计的题目编号或者档案编号，也可能是某个学校实训平台里给项目安排的流水号。这个数字本身没有技术含义，但从实用角度看，它倒是提示了一点：这类项目往往是从一个比较规范的题目库中抽取出来的，对应的评分标准、验收模板都是现成的，所以做的时候更应该追求“功能完整、结构清晰、演示流畅”，而不是追求技术上标新立异。

1.2 技术栈选型：为什么是JSP+Servlet+MySQL

现在Java后端框架已经卷到Spring Boot 3.x时代了，但课程设计和毕业设计里JSP+Servlet依然是绝对主力。原因很简单：框架帮你屏蔽掉的底层原理，恰恰是这类项目要考察的东西。Servlet负责接收请求和处理业务逻辑，JSP负责渲染页面，JavaBean/实体类负责封装数据，JDBC负责和数据库交互——这一套走下来，HTTP协议、请求响应模型、Session机制、SQL语句这些基础能力都会被迫练一遍。用Spring Boot虽然开发快，但很多评分点（比如手工配置web.xml、理解Servlet生命周期）就体现不出来了。

这套技术栈选型有一个容易被低估的好处：它很容易“可视化调试”。出问题时你能明确知道是Servlet映射没配好、还是JSP的EL表达式写错、还是SQL执行出错。而在Spring Boot里，层层封装反而让新手摸不着头脑。我做过的项目里，凡是JSP+Servlet基础扎实的人，后面转Spring Boot基本都是三天上手；反过来，直接上手Spring Boot的人，遇到一次Filter拦截顺序的问题就可能卡一整晚，因为他不理解背后的机制。

数据库用MySQL是标配，版本建议5.7或8.0，字符集统一utf8mb4。为什么强调utf8mb4？因为商品名称、用户收货地址这些字段存中文是常态，万一用户输入了表情符号，默认utf8会直接报错。另外一点，数据库连接池我推荐直接用DBCP或C3P0，尽量别用DriverManager每次都新建连接。如果项目会拿到答辩现场演示，连接池能明显提升页面响应速度，这个细节加分的。

1.3 开发环境与项目结构规划

工具层面的最低配置：JDK 8、Tomcat 8.5或9.0、MySQL 5.7+、IDEA（或Eclipse，更推荐IDEA）、Navicat（或Workbench）。JDK 8和Tomcat 8.5这个组合是最稳的，不会有版本兼容的坑。开发时用IDEA的话，要注意IDEA自带的Tomcat集成方式和Eclipse不同，配置Artifact时一定要选war exploded模式，不然每次改Java代码都要重启整个Tomcat，特别浪费时间。

项目结构按MVC模式来分：

• src/main/java下建com.shop.servlet（控制层）、com.shop.service（业务层）、com.shop.dao（数据访问层）、com.shop.entity（实体类）、com.shop.util（工具类）。
• web目录下放JSP页面，按功能分子目录：user/、admin/、product/、cart/、order/。
• WEB-INF下放web.xml和lib目录（如果有本地jar包）。

分包的核心原则是：Servlet不写SQL，DAO层不写业务逻辑。这个规定听起来简单，但写起来很容易破功。比如“下单”这个动作，很多新手会把生成订单、扣库存、清购物车全塞在同一个Servlet里，看起来功能能做出来，但代码乱成一锅粥，出了问题压根不知道从哪查。我当时第一次做这类项目也犯过这毛病，后来被老师批了一顿才明白分层的重要性——DAO层方法要单一，比如insertOrder、deleteFromCart、updateStock各管各的，业务层的createOrder方法再依次调用它们，并用一个事务包起来。

2. 数据库设计与核心表结构精讲

2.1 五张核心表的字段设计

购物系统的数据库设计是整个系统的地基，这一块如果用半小时草草建三张表，后面写代码会一直返工。一个正规的Java Web购物系统，最少需要以下核心表：

管理员表（admin）：

• id：主键自增
• username：登录名，唯一索引
• password：密码，必须密文存储
• real_name：管理员姓名

用户表（user）：

• id：主键自增
• username：登录名，唯一约束
• password：密码，建议MD5加盐处理
• phone、email、address：联系方式
• create_time：注册时间

商品分类表（category）：

• id：主键
• name：分类名称
• parent_id：父分类id，方便做二级分类（如果不做二级分类可省略）
• sort_order：排序字段

商品表（product）：

• id：主键
• category_id：关联分类表
• name：商品名称
• price：价格，Decimal(10,2)类型，绝不能用float，否则金额会有精度问题
• stock：库存量
• image：图片URL
• description：商品描述
• status：上下架状态（1上架、0下架）
• create_time：上架时间

购物车表（cart）：

• id：主键
• user_id：关联用户
• product_id：关联商品
• quantity：购买数量
• 用user_id+product_id做唯一约束，保证同一用户同一个商品只有一条记录

订单表（orders）：

• id：主键
• order_no：订单编号，建议用时间戳+随机数生成
• user_id：下单用户
• total_price：订单总价
• status：订单状态，用0/1/2/3表示待支付、已支付待发货、已发货、已完成
• receiver_name、receiver_phone、receiver_address：收货信息冗余字段

订单明细表（order_item）：

• id：主键
• order_id：关联订单表
• product_id：关联商品表
• product_name：商品名称（快照，防止商品信息后来被改）
• price：当时成交价
• quantity：数量

注意一个设计细节：为什么订单明细里要冗余product_name和price？因为用户下单之后，商品可能改名、调价甚至被删除。如果订单明细不存快照，过几天查订单时显示的商品名称和价格可能就和下单时不一致了。这是数据库设计里很典型的“冗余字段时间换正确性”的思路。

2.2 表关系与外键的使用原则

从关系上说，用户和购物车是一对多，用户和订单是一对多，订单和订单明细是一对多，商品和分类是多对一。画ER图的时候，把这些线连好，项目文档的数据库设计部分就有内容可写了。

关于外键，我的建议是：设计阶段画出来，表结构里不强制加物理外键。原因有两个。第一，物理外键会让数据删除变得非常麻烦，后台管理里要删一条商品记录，可能因为订单明细还引用着它而直接被拒绝；第二，开发阶段频繁改数据时，外键约束冲突会浪费大量调试时间。业务逻辑层面的完整性用Java代码来保证，数据库外键只作为文档里的关联说明存在即可。我在联调阶段就吃过这个亏，当时给订单表加了外键，测试时想删一条测试用户的数据，结果连着删除七八张关联表的数据，后来实在受不了把外键全去掉了，代码里通过事务控制一致性，反而清爽得多。

建表SQL里所有引擎统一用InnoDB，因为它支持事务。这一点做订单功能时必须要有——下订单时同时要插入订单表和订单明细表、扣减库存、清空购物车，任何一个步骤失败，整笔操作都必须回滚，否则会出现“用户没下单成功但库存少了”的bug。

2.3 分页查询SQL与多表联查的设计

商品列表页和订单列表页都必须要分页，不可能一次性把所有数据查出来。分页的SQL写法很固定，以商品列表为例：

sql复制SELECT * FROM product 
WHERE status = 1 
ORDER BY id DESC 
LIMIT #{offset}, #{pageSize};

offset的计算是(currentPage - 1) * pageSize。比如每页显示12个商品，第3页的offset就是(3-1)*12=24。同时要查总记录数：

sql复制SELECT COUNT(*) FROM product WHERE status = 1;

然后用Math.ceil(total / pageSize)算出总页数。这个分页逻辑在JSP+Servlet里没有现成组件，需要自己封装一个Page类，包含currentPage、pageSize、totalCount、totalPages、list这五个字段，每页渲染时直接用JSTL遍历list。

商品详情页和后台订单管理的列表需要多表联查。商品列表关联分类表拿分类名称：

sql复制SELECT p.*, c.name AS category_name 
FROM product p 
LEFT JOIN category c ON p.category_id = c.id 
WHERE p.status = 1 
ORDER BY p.id DESC;

订单列表关联用户表，方便后台管理员知道是谁下的单：

sql复制SELECT o.*, u.username 
FROM orders o 
LEFT JOIN user u ON o.user_id = u.id 
ORDER BY o.create_time DESC;

LEFT JOIN能够保证即使某条记录在右表没有匹配项（比如商品没有分类）也能查出来，而不是被过滤掉。

3. 核心功能模块的实现细节

3.1 用户注册登录与Session管理

登录注册功能每个系统都有，但购物系统里它有个特殊之处：登录状态决定了后续购物车和订单功能的可用性。所以这一步不光是校验用户名密码，还要把用户信息存进Session，并在页面端根据Session判断显示“登录/注册”还是“用户名/退出”。

注册模块的核心考量在密码存储上。用MD5加盐的方式做一个工具类：

java复制public class MD5Util {
    // 加盐固定字符串，实际开发中可使用随机盐存入数据库
    private static final String SALT = "shop2024";
    
    public static String md5(String input) {
        String result = input + SALT;
        try {
            MessageDigest md = MessageDigest.getInstance("MD5");
            byte[] bytes = md.digest(result.getBytes("utf-8"));
            StringBuilder sb = new StringBuilder();
            for (byte b : bytes) {
                String hex = Integer.toHexString(b & 0xff);
                if (hex.length() == 1) sb.append("0");
                sb.append(hex);
            }
            return sb.toString();
        } catch (Exception e) {
            e.printStackTrace();
            return null;
        }
    }
}

有人会问为什么不用明文存储，省事又直观。原因是只要项目要拿去答辩或展示，评审老师基本都会问到密码安全问题，明文密码在真实业务里是绝对不允许的。加了MD5加密之后再展示给老师看，至少说明你考虑过安全性。更进一步，还可以用SHA-256加随机盐，但MD5对课程设计这个级别已经足够。

登录逻辑的细节处理：用户登录成功之后，要执行request.getSession().setAttribute("user", user)，同时最好把上一次登录时间更新到数据库。页面端在JSP顶部用这么一段做登录判断：

jsp复制<c:if test="${empty sessionScope.user}">
    <a href="${pageContext.request.contextPath}/login.jsp">登录</a>
    <a href="${pageContext.request.contextPath}/register.jsp">注册</a>
</c:if>
<c:if test="${not empty sessionScope.user}">
    欢迎您：${sessionScope.user.username}
    <a href="${pageContext.request.contextPath}/logoutServlet">退出</a>
</c:if>

这里面的一个关键点：${empty sessionScope.user}的写法，比Java代码里session.getAttribute("user") == null要简洁，而且JSTL的empty判断对null和空集合都有效，不太会踩坑。退出登录就是session.invalidate()然后重定向回首页。

3.2 商品展示与购物车的两种实现方案

商品展示相对简单，就是查询数据库商品表渲染到页面上，加上一个关键词搜索功能：

sql复制SELECT * FROM product 
WHERE status = 1 AND name LIKE CONCAT('%', #{keyword}, '%') 
ORDER BY id DESC;

LIKE加%实现模糊匹配，CONCAT函数拼接字符串，这个写法比直接在Java里拼接再塞进去更安全，有效规避了SQL注入问题。

购物车是购物系统里最有技术含量的功能之一，因为它本质上是一个"跨请求状态的临时数据容器"。实现方案有两种主流选择：Session存储和数据库存储。Session方案的原理是把购物车对象直接存到Session里，用一个Map或List装着商品id和数量。好处是代码简单、不碰数据库、性能极快；坏处是换浏览器或清缓存购物车就没了。数据库方案则是把购物车数据持久化到cart表，用户每次登录都能看到之前的购物车内容。两类项目对这两个方案的接受度不同，课程设计用Session方案足够，毕业设计建议用数据库方案，因为能多展示“数据库表设计”这个加分项。

我用过最顺手的Session购物车方案是把购物车封装成一个Map<Integer, Integer>，key是商品id，value是数量。每次加购物车时，JS把商品id和数量POST到CartServlet，Servlet里从Session取出Map，做累加操作：

java复制Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart");
if (cart == null) {
    cart = new HashMap<Integer, Integer>();
}
int productId = Integer.parseInt(request.getParameter("productId"));
int quantity = cart.containsKey(productId) ? cart.get(productId) + 1 : 1;
cart.put(productId, quantity);
session.setAttribute("cart", cart);

购物车中删除一条记录、修改数量、清空购物车这些操作本质上都是对Map的操作，逻辑不复杂。真正要花心思的是购物车页面的渲染——循环遍历Map，根据key去数据库查商品详情。这里一个常见的坑是：Map遍历时用${cart.keySet()}在JSTL里写起来比较别扭，更好的做法是在Servlet里先把Map转成List，做成一个包含product对象和quantity的封装类。这样页面上的循环逻辑会非常干净，页面上也能直接展示商品名、单价和金额小计。

3.3 订单生成与库存扣减的事务处理

订单模块是整个系统最容易出bug的地方，也是答辩时老师最爱追问的地方。要理解事务的重要性，先看下单流程涉及哪些操作：生成订单记录、生成订单明细、扣减库存、清空购物车。这四个操作必须同时成功或者同时失败。

我的做法是利用JDBC的Connection手动控制事务：

java复制Connection conn = null;
try {
    conn = DBUtil.getConnection();
    conn.setAutoCommit(false); // 关闭自动提交
    
    // 1. 插入订单表
    // 2. 插入订单明细表
    // 3. 扣减商品库存
    // 4. 清空购物车
    
    conn.commit(); // 全部成功才提交
} catch (Exception e) {
    if (conn != null) {
        conn.rollback(); // 任何异常回滚
    }
    e.printStackTrace();
} finally {
    if (conn != null) {
        conn.setAutoCommit(true);
        conn.close();
    }
}

这个模式请务必刻进脑子里。而且注意，获取连接和关闭连接都要用同一个Connection对象，不能是每次调用DAO都重新拿连接，那样事务就失效了。正确做法是把Connection作为参数传给各个DAO方法，或者在Service层管理连接、DAO层统一使用传入的连接。我当时在这里坑了很久，因为每个DAO方法都自己调DBUtil.getConnection()，结果发现rollback根本不起作用，就是因为各查各的连接，根本不是同一个事务。

为了防止下单时库存被扣成负数，要在SQL层面加限制。如果直接用UPDATE product SET stock = stock - 1 WHERE id = ?，并发情况下可能把库存扣成负数。稳妥的写法是：

sql复制UPDATE product SET stock = stock - #{quantity} 
WHERE id = #{productId} AND stock >= #{quantity};

这个方法返回受影响行数，如果返回0，说明库存不足，代码里可以抛出异常回滚事务。这个语句天然是原子的，能扛住一定并发场景，比“先查库存再更新库存”那种先检查后执行的方案安全得多。

订单编号一般用时间戳加随机数，格式像这样：String orderNo = "ORD" + System.currentTimeMillis() + new Random().nextInt(1000);。不推荐用数据库自增id当订单号，因为很容易被猜到订单量，且多表合并数据时可能重复。

4. 前端交互与JSP页面开发的心得

4.1 JSP页面的动态渲染与JSTL/EL表达式

JSP页面写得好不好，直接影响整个项目的美观度和答辩体验。我见过太多同学把一个JSP页面写成“满屏Java代码小脚本”的风格，一打开页面就是一两百行<% %>夹杂着HTML。这种写法虽然能跑，但绝对不推荐。原因有两个：第一，JSP容器每次渲染时都要把Java代码编译一遍，性能差；第二，代码可读性极差，稍微改个页面布局就要在几百行里找小脚本，定位困难。

正确做法是把JSP里的Java小脚本控制在最低限度，能用EL表达式和JSTL标签解决的，一律不写Java代码。商品列表页的循环应该长这样：

jsp复制<c:forEach items="${productList}" var="p">
    <div class="product-item">
        <img src="${p.image}" alt="${p.name}" />
        <h3>${p.name}</h3>
        <p class="price">￥${p.price}</p>
        <a href="${pageContext.request.contextPath}/productDetailServlet?id=${p.id}">查看详情</a>
        <button onclick="addToCart(${p.id})">加入购物车</button>
    </div>
</c:forEach>

代码中没有Java代码，所有变量都是Servlet在转发请求前通过request.setAttribute("productList", list)塞进来的。这样JSP页面结构清晰，前端同学也能直接上手调样式，后端同学只需要保证数据正确即可。

静态资源管理也是JSP开发中一个典型的坑。JSP页面里的CSS、JS、图片路径直接用相对路径，部署到Tomcat时经常出现资源找不到的问题，因为当前页面的URL层级变了，相对路径就失效了。统一解决办法是：所有页面在<head>里先定义<base>标签：

jsp复制<%
    String basePath = request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort() + request.getContextPath() + "/";
%>
<base href="<%=basePath%>">

那之后页面上所有的CSS、JS、图片引用都写成${pageContext.request.contextPath}/static/css/style.css这种绝对路径格式，基本上就不会再出现静态资源丢失的问题。这小技巧是实战经验，教科书里几乎不会教。

4.2 用jQuery+Ajax实现异步交互的实战思路

有些功能如果每次操作都让整个页面刷新，体验会非常差。比如点击“加入购物车”、修改购物车数量、结算时切换收货地址，这些动作用传统表单提交会导致页面跳转再返回，滚动条位置全丢了，用户会觉得自己在一个非常卡顿的网站里。所以购物系统的前端至少要引入jQuery和少量Ajax，让这些高频交互相当于“无声”地在后台完成。

以“加入购物车”为例，前端代码是这样的：

html复制<script src="${pageContext.request.contextPath}/static/js/jquery-3.6.0.min.js"></script>
<script>
function addToCart(productId) {
    $.ajax({
        url: '${pageContext.request.contextPath}/cartServlet',
        type: 'POST',
        data: {'action': 'add', 'productId': productId, 'quantity': 1},
        dataType: 'json',
        success: function(res) {
            if (res.code === 200) {
                alert('已加入购物车，当前购物车共 ' + res.totalCount + ' 件商品');
            } else if (res.code === 401) {
                if (confirm('您还未登录，是否前往登录？')) {
                    window.location.href = '${pageContext.request.contextPath}/login.jsp';
                }
            } else {
                alert(res.message);
            }
        },
        error: function() {
            alert('网络异常，请稍后重试');
        }
    });
}
</script>

Servlet端对应的处理，要设置响应格式为JSON：

java复制resp.setContentType("application/json;charset=utf-8");
PrintWriter out = resp.getWriter();
Map<String, Object> result = new HashMap<String, Object>();
if (session.getAttribute("user") == null) {
    result.put("code", 401);
    result.put("message", "未登录");
} else {
    // 加入购物车逻辑
    result.put("code", 200);
    result.put("totalCount", totalCount);
}
out.write(new Gson().toJson(result));

可以看到这里用了Gson把Map转成JSON字符串，这就需要在pom或lib里引入Gson或Fastjson依赖。这个Ajax交互的好处是：不用写任何JSON解析的代码，前端$.ajax的dataType:'json'会自动帮我们解析好。

关于jQuery在前端申请流程相关场景中的应用，有一个通用规律：凡是那种“点击按钮→后端处理→局部状态更新”的操作，逻辑都和加入购物车是一致的。比如后台管理员审核订单，点击“审核通过”按钮时，用Ajax把订单id和一个状态值发给后端，后端更新数据库后返回最新的订单状态，前端再把按钮文案改成“已通过”并禁用。这种交互模式在各类管理后端里反复出现，掌握了这一个套路，就等于掌握了审批流、审核流、状态流这一类前端交互的底层思路。我见过不少同学遇到这种需求总觉得无从下手，其实核心就是这个：把状态变更动作做成异步接口，用jQuery的$.ajax去调用，局部更新DOM，就这么简单。

4.3 前端表单校验与页面细节优化

表单校验分前端和后端两层。前端校验用jQuery Validate插件或手写正则，主要拦截常见错误（空字段、邮箱格式、两次密码不一致等），目的是提升用户体验、减少无效请求。后端Servlet必须做二次校验，因为这才是真正的安全防线——前端校验可以被绕过，恶意用户直接构造HTTP请求就能打穿。

一个典型的例子是注册页面的密码强度与确认密码。前端手写一段：

javascript复制function validateRegisterForm() {
    var username = $('#username').val().trim();
    var password = $('#password').val();
    var confirmPwd = $('#confirmPwd').val();
    if (username.length < 3) {
        alert('用户名至少3个字符');
        return false;
    }
    if (password.length < 6) {
        alert('密码至少6位');
        return false;
    }
    if (password !== confirmPwd) {
        alert('两次输入的密码不一致');
        return false;
    }
    return true;
}

后端再校验一遍：检查用户名是否已存在（唯一索引兜底）、密码长度是否满足要求。两层校验缺一不可，这是我在真实开发中养成的习惯，课程设计里同样要保留。

页面细节上值得注意的还有：商品列表价格显示要用新标签页打开详情页；购物车数量输入框要限制只能输数字；订单提交成功要跳到一个独立成功页面，告诉用户“订单支付成功”而不是让用户自己猜。这些细节每个都不难，但加起来会让你的项目看起来明显比其他同学的“高一个档次”。我当评委的时候见过太多功能齐全但用户体验一塌糊涂的项目，所有按钮弹的都是alert，页面跳转全靠浏览器自带返回，感觉完全没站在使用者角度想过。

5. 部署上线与常见问题排查实录

5.1 Tomcat部署与数据库初始化的标准流程

项目开发完一定要在干净的Tomcat环境里完整走一遍部署流程，因为开发和部署环境往往有差异，新环境容易暴露出各种奇奇怪怪的问题。标准流程是这样的：

第一步，MySQL里新建数据库：create database shop default charset utf8mb4;，然后导入准备好的建表SQL，再手动插入几条测试数据，至少要有两个分类、十个商品、一个管理员账号和一个测试用户账号。这里有一个加分细节：提供一个init.sql文件，把建表和初始化数据的SQL全部放在里面，同时在项目文档里写清楚执行步骤。答辩时老师问“这个数据库怎么初始化”，你直接说“执行init.sql即可”，老师觉得你做事有交付意识。

第二步，在IDEA里配置Tomcat，Artifact用war exploded模式。确认所有依赖（Gson、JSTL、MySQL驱动）都已经打包进了WEB-INF/lib。IDEA里用Maven管理依赖的话，检查pom.xml里scope为provided的jar不会被打进去（否则运行时会报ClassNotFoundException或NoSuchMethodError）。

第三步，启动Tomcat，访问http://localhost:8080/shop/看看首页是否正常展示。如果首页商品能加载，注册一个测试账号，走一遍“加购物车→去结算→生成订单→后台改订单状态”的完整流程。每一步都记录下对应的数据库变化，比如下单后orders表多了记录、product表的stock字段减了对应数量、cart表清空了，全链路没问题，这才算部署通过。

5.2 我踩过的典型报错与处理方案

这里整理几个我实际项目中反复踩过、而且几乎每个用JSP+Servlet做购物系统的人都可能遇到的报错，按出现频率从高到低排列：

中文乱码这一条重点讲一下。Java Web的中文乱码有“三板斧”，第一板斧是JSP页面头部加：

jsp复制<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>

第二板斧是Servlet在处理POST请求时，第一行执行：

java复制request.setCharacterEncoding("utf-8");

第三板斧是JDBC连接URL加useUnicode=true&characterEncoding=utf8。三个地方全对了，中文基本就不会乱码。GET请求的中文参数（如搜索框关键词）还要在Tomcat的server.xml里给Connector加URIEncoding="UTF-8"，但这属于环境配置，部署时注意一下就行。

5.3 项目演示和答辩的实用建议

项目写完之后，演示也是要专门练习的。我见过太多同学代码写得好，演示时却因为操作顺序不对，暴露了一大堆本来不是bug的问题。推荐的演示流程走这一条主线：先演示前台首页，说清楚有几个商品分类；然后注册一个新用户，用真实账号密码登录；搜索一个商品，演示搜索功能；把一个商品加入购物车，购物车里改数量再下单；下单后立刻切到后台，用管理员账号登录，把订单状态改一下；最后回到前台，刷新订单列表，确认状态更新了。

这个流程串起来的核心逻辑是“前台用户购物，后台管理员处理订单”，评审老师听一遍就能理解你的系统是完整的。

答辩时老师最喜欢问的技术问题，提前准备好答案：

• “你的事务是怎么控制的？”可以回答：我在Service层获取Connection并关闭自动提交，传给DAO层，全部成功commit，异常rollback。
• “Session和Cookie有什么区别？”购物系统的登录态存Session，Session基于Cookie中的JSESSIONID。
• “你的密码安全怎么处理的？”用MD5加盐加密存储。
• “分页是怎么实现的？”用LIMIT加offset，Page类封装参数。
• “为什么购物车用Map结构？”Map天然适配“商品id和数量一一对应”的需求，查询和修改都很快。

每道题都不需要答得多么深入，但至少逻辑要稳。如果你能把事务那一段讲得明明白白，老师基本就满意了。我给很多学生模拟过答辩，能说清楚事务的不到一半，懂并发场景下库存扣减SQL写法的更是寥寥无几，所以这块内容吃透了绝对是对你的加分项。

按我个人经验，做这类课程设计最忌讳的就是“代码先跑通，再回头补文档”。正确做法是边做边截图，比如数据库刚建好，就截个ER图；商品模块刚写完，就截个列表页面；订单流程刚调通，就录一段屏幕视频。这些素材到最后写项目报告、做PPT、写演示讲稿时全都有用。不然等项目做完再回头翻，很多当时的思路已经忘了，截图也补不回来，那才是最亏的。如果一次运行失败，不要怕，把控制台红字复制下来去查，很多时候答案就在第一条异常里，往下翻反而越看越糊涂。项目做完之后，再顺便把init.sql和读我文档整理一下，打包成一个zip，以后自己复习或者给别人展示时，一解压就能跑起来，这份劳动成果才算真正完整。