JavaWeb酒水商城实战：Servlet+JSP+MySQL搭建完整电商闭环

刚把这份酒水商城管理系统从头到尾又跑了一遍。老实说，它不是什么高深项目——技术栈清一色是 JavaWeb 的经典老组合：JSP、Servlet、Bootstrap、MySQL，没有 Spring Boot 全家桶，也没有前后端分离那套时髦东西。但恰恰因为是这种“裸奔”状态，整个电商闭环的每一条细节都暴露在你面前：注册登录的会话管理、酒水商品的前台展示与后台维护、购物车增减、订单生成与库存扣减，全部自己一行行写出来。对我这种带过不少实习生、也改过不少毕业设计的人来讲，这类项目反而是最能帮人把 JavaWeb 底子打牢的素材。

这篇文章适合三类人：刚学完 Servlet 和 JSP 基础、想找一个能跑到完整流程的实战项目的新手；正在准备毕业设计、想从“管理系统”里跳出来做“商城类”项目的同学；还有想把老项目改成前后端分离、但需要先搞懂后端原来是怎么组织的人。我会按自己实际开发的顺序来讲：先聊为什么这么选型，再拆功能模块和数据库表结构，第三部分把核心代码和踩坑细节亮出来，第四部分讲购物车与订单这条最关键的闭环，最后落到部署环境和问题排查。代码片段你们直接抄去改问题不大，反正我能踩的坑基本都写出来了。

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

1.1 为什么是 JSP + Servlet，而不是 Spring Boot

这大概是很多人拿到题目后的第一反应：现在谁还手写 Servlet？先用 Spring Boot 搭个接口，前端再用 Vue 包一层，不香吗？香，但那是另一个学习阶段的事。这个选题的核心诉求，我理解是“用最少的封装看清楚 JavaWeb 的运行本质”。

Servlet 作为 HTTP 请求的入口，能让你搞清楚一件最基础的事：一个请求从浏览器发出来，Tomcat 容器到底是怎么找到对应的 Java 代码，Java 代码又是怎么把数据装进 Request、转发到页面再渲染出来的。换成 Spring Boot 后，@RequestMapping 一个注解就把这个过程藏起来了，新手反而更容易陷入“对是能对上，原理完全不清楚”的状态。

JSP 这边也一样。它本质上就是一个会被容器编译成 Servlet 的模板文件，内置对象如 request、session、application 都是现成的。用 JSP 渲染商品列表，你能直接看到 c:forEach 标签遍历集合、${product.price} 这种 EL 表达式取值，逻辑非常透明。而用前后端分离，前端要处理跨域，后端要写 JSON 接口、写 DTO，至少得同时掌握两套体系才能跑通。

所以说，这个选型不是技术落后，而是教学价值最高。要么不管用 Spring、怎么给框架兜底；要么就干脆不用框架，把 Servlet、JSP、JDBC 这几条主线全部走通。我实际做下来，项目代码量大概 3000 到 4000 行，正好在一个普通人花两三周能完全啃掉、又不至于简单到没东西可学的范围。

1.2 酒水商城的业务场景拆解

“酒水商城”这四个字，比“XX管理系统”要复杂一截。管理系统的核心往往就是增删改查，而商城要处理的是带状态的业务流：用户要先注册登录，再浏览商品、加购物车、下单，下单之后库存要扣掉，后台还能维护商品上下架。

我把整个系统拆成了前台和后台两条线。前台面向普通用户，包括注册登录、首页酒水推荐、商品分类浏览、商品详情、购物车管理和订单结算；后台面向管理员，包括商品管理、库存管理、订单状态更细。这样设计的好处是前后台共用同一套 Servlet 技术栈，但通过不同的 Servlet 类和路径区分开，代码结构特别清楚。

在设计功能清单时，我给自己定了三条原则。第一，每个模块都要落地到一张数据库表或一张关系表上，不允许有“功能放在内存里假装实现”的情况，比如购物车我会单独设计表结构；第二，每个关键操作都要有反馈，添加购物车成功要有提示，库存不足要有拦截；第三，权限要能控制住，普通用户不能直接访问后台管理页面，后台操作要做登录校验。

这个业务场景设计直接决定了后面的工作量。现在随便搜一个“电商系统”的源码，动不动就是十几个表、几十个接口，看起来很唬人，但很多表其实是冗余的。我最后收敛成五张核心表：用户表、商品分类表、商品表、订单表、订单明细表。购物车我用会话缓存加数据库同步的方式处理，后面会详细说。

1.3 技术栈分工：Bootstrap、Servlet、MySQL 各管什么

这套系统里每个技术点都有明确分工，也说一下我为什么把 Bootstrap 拉进来。

Servlet 是后端控制层，负责接收请求、调用业务逻辑、跳转页面。它不会直接写 HTML，而是把数据塞进 request 域，再 forward 到 JSP 去渲染。这个职责边界一开始就得划清楚，不然很容易把业务逻辑写进 Servlet 里，变得又臭又长。

JSP 是视图层，负责用 HTML 和 JSTL 标签把数据展示出来。商品列表页、详情页、购物车页面、后台管理页面，全部通过 JSP 渲染。JSP 里只写展示逻辑，不访问数据库，最多用 EL 表达式判断一下 empty 或者用 c:if 做个条件分支。

MySQL 是数据层，负责持久化。用户信息、商品数据、订单记录，全往 MySQL 里存。早期我为了省事用过 DriverManager 直连，每操作一次数据库就开一次连接，后来改成连接池，效果非常明显。

Bootstrap 是纯前端 UI 框架，负责把页面做得像样。它解决的是“无 CSS 丑得没法看”的问题。Bootstrap 的栅格系统能让我快速把商品卡片排成一行四个的响应式布局，Bootstrap 自带的按钮、表单、警告框样式也让页面在没请设计师的情况下，不至于太磕碜。毕竟商城类项目，页面是否整洁直接影响观感。

这里要提一个经验：JSP 页面里不要内联大段 CSS 和 JS，Bootstrap 的 CDN 引用放在每个页面的 <head> 里，同时抽出公共头部和底部，用 <%@ include file="common/header.jsp" %> 来引入，能省掉很多重复代码。

2. 功能模块拆分与数据库表设计

2.1 前后台功能清单与页面流转

我先列一下会话流程，这是很多人做项目时最容易乱的环节。

一个用户打开商城首页，看到酒水分类和推荐商品。点击商品进入详情页，看到价格、库存和详细介绍。想要购买，点击“加入购物车”，系统判断用户是否登录：没登录跳转到登录页，登录了把商品写进购物车。购物车页面可以调整数量、删除商品、看到合计金额。点击“去结算”生成订单，订单生成后库存同步扣减，购物车清空。后台管理页里，管理员登录后可以新增商品、编辑商品信息、上下架、调整库存、查看订单列表。

页面流转背后要匹配清晰的 Servlet 路由。我用的方法是每个模块一个 Servlet，模块内用 action 参数区分动作，例如 product?action=list、product?action=detail&id=3、cart?action=add&id=3、order?action=create。这种设计比“一个功能一个 Servlet”要省很多类，也比“只有一个总 Servlet 用 if 判断所有动作”要规范。

2.2 核心表结构设计（附建表 SQL）

数据库我命名为 liquor_shop，字符集统一用 utf8mb4。这里多说一句，很多新手建库时随便选个字符集，等到插入中文变成 ??? 或者乱码时，才想起来字符集的问题，那会儿再去改库的字符集，可能数据已经脏了，很麻烦。所以建库这一步别偷懒，直接写清楚。

sql复制CREATE DATABASE IF NOT EXISTS liquor_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
USE liquor_shop;

CREATE TABLE tb_user (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL UNIQUE,
  password VARCHAR(100) NOT NULL COMMENT '建议存MD5或加盐后的密文',
  nickname VARCHAR(50),
  phone VARCHAR(20),
  role TINYINT DEFAULT 1 COMMENT '1普通用户 2管理员',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE tb_category (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  sort INT DEFAULT 0
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE tb_product (
  id INT PRIMARY KEY AUTO_INCREMENT,
  category_id INT,
  name VARCHAR(100) NOT NULL,
  price DECIMAL(10,2) NOT NULL,
  stock INT NOT NULL DEFAULT 0,
  image VARCHAR(255),
  description TEXT,
  status TINYINT DEFAULT 1 COMMENT '1上架 0下架',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  KEY idx_category (category_id),
  KEY idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE tb_order (
  id INT PRIMARY KEY AUTO_INCREMENT,
  order_no VARCHAR(32) NOT NULL UNIQUE,
  user_id INT NOT NULL,
  total_price DECIMAL(10,2) NOT NULL,
  status TINYINT DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  KEY idx_user (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE tb_order_item (
  id INT PRIMARY KEY AUTO_INCREMENT,
  order_id INT NOT NULL,
  product_id INT NOT NULL,
  product_name VARCHAR(100) NOT NULL,
  price DECIMAL(10,2) NOT NULL,
  count INT NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

表结构设计的核心思想是：订单表要独立于订单明细表。因为一张订单可能包含多种酒水，如果只在订单表里放一个商品字段，那订单就做成“一单一物”了，完全不符合真实购物车场景。订单明细表把商品名称、单价、数量都冗余了一份进去。这里冗余是故意的，因为商品表里的价格和名称可能日后会调整，订单作为交易凭证，必须保留购买那一刻的快照数据。

2.3 经典坑：表名沿用关键字、库存设计太随意

建表时我第一个版本把用户表直接叫做 user，跑起来没任何问题，直到某次写一个复杂查询时才发现 user 在 MySQL 里是保留字。虽然 MySQL 通常允许你用它，但一旦涉及某些不转义的 SQL 拼接场景，立马报错。稳妥做法就是加上前缀，tb_user、tb_product，既避免关键字冲突，也让表结构在 SQL 工具里一眼能看出是业务表。

库存字段的设计也踩过坑。最开始我就设置一个普通 INT 库存字段，下单时先 SELECT 库存，判断大于购买数量再 UPDATE 扣减。但高并发下这种“先查再改”的模式存在超卖风险：两个请求同时读到库存为 1，两个人都判断能买，都去扣减，结果库存变成负数。解决方式是用条件更新的原子 SQL：

sql复制UPDATE tb_product
SET stock = stock - 5
WHERE id = 1 AND stock >= 5;

这条 SQL 会返回受影响行数，如果返回 0，说明库存不足，下单就失败。这个做法在小型项目里是最可靠、也最容易理解的并发控制方案。如果以后做到分布式高并发的商城，那就要上 Redis 和消息队列了，但那是另一个量级的事，这里不展开。

3. 核心代码实现与关键环节解读

3.1 BaseServlet 统一分发：用反射处理 action

我一直觉得 Servlet 一个功能写一个类太重复。商品有增删改查，订单也有各种状态变更，每加一个功能就要新建一个类，然后在 web.xml 或者注解里配路由，低效且散乱。所以我写了一个 BaseServlet，把“按 action 参数反射调用方法”这套逻辑统一拉出来。

java复制public abstract class BaseServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {

        String action = req.getParameter("action");
        if (action == null || "".equals(action)) {
            action = "list";
        }

        try {
            Method method = this.getClass().getMethod(action,
                    HttpServletRequest.class, HttpServletResponse.class);
            String view = (String) method.invoke(this, req, resp);

            if (view != null && !"".equals(view)) {
                if (view.startsWith("redirect:")) {
                    resp.sendRedirect(view.substring("redirect:".length()));
                } else {
                    req.getRequestDispatcher("/" + view).forward(req, resp);
                }
            }
        } catch (Exception e) {
            throw new ServletException("action分发失败: " + action, e);
        }
    }
}

然后每个业务 Servlet 继承它，例如 ProductServlet extends BaseServlet，里面定义一个 list 方法：

java复制public String list(HttpServletRequest req, HttpServletResponse resp) {
    List<Product> list = productService.queryOnSale();
    req.setAttribute("productList", list);
    return "index.jsp";
}

这种方法约定带来一个好处：每一个 public 方法签名固定是 String 方法名(HttpServletRequest, HttpServletResponse)，返回的字符串就是视图地址。要重定向就写 redirect:cart?action=list，要转发就直接写 JSP 路径。整个项目的代码量锐减，而且新人照着这个模式加功能非常快。

这个设计其实是 MVC 里前端控制器思想的简化版，也是很多老项目里 DispatchServlet 的原型。我建议对反射不太熟的朋友，趁这个机会把 Method、invoke、getParameter 这几个 API 彻底吃透，后面看 Spring MVC 的源码会顺很多。

3.2 JSP + Bootstrap 页面：EL 表达式、c:forEach 与响应式布局

商品列表页是整个项目里最有面子的页面。用 Bootstrap 的栅格，一行放四个商品卡片，每个卡片有图片、名称、价格、库存和两个按钮。数据从 request 域取，循环交给 JSTL 标签。

jsp复制<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>酒水商城</title>
    <link rel="stylesheet" href="https://cdn.bootcdn.net/ajax/libs/twitter-bootstrap/3.4.1/css/bootstrap.min.css">
</head>
<body>
<div class="container">
    <h2 class="text-center text-primary">酒水商城</h2>
    <div class="row">
        <c:forEach items="${productList}" var="p">
            <div class="col-md-3 col-sm-6">
                <div class="thumbnail">
                    <img src="${p.image}" class="img-responsive" alt="${p.name}">
                    <div class="caption">
                        <h4>${p.name}</h4>
                        <p class="text-danger">￥${p.price}</p>
                        <p>库存：${p.stock}件</p>
                        <a href="product?action=detail&id=${p.id}" class="btn btn-primary btn-sm">查看详情</a>
                        <a href="cart?action=add&id=${p.id}" class="btn btn-warning btn-sm">加入购物车</a>
                    </div>
                </div>
            </div>
        </c:forEach>
    </div>
</div>
</body>
</html>

这里三个细节值得注意。第一，c:forEach 遍历的一定是集合，千万别把 List<Product> 直接塞进 <c:forEach> 里然后取 p.name，变量名是 var 定义的 p，别名别跟 product 混淆。第二，Bootstrap 版本我用 3.x，不要引 5.x 的文档然后到处找 well、thumbnail 类名，版本对应不上会怀疑人生。第三，商品价格用了 DECIMAL(10,2) 存，页面上直接 ${p.price} 输出没问题；如果你自己用 double 或 float 做金额，后面迟早要吃浮点精度亏，数据库字段必须用定点数。

商品详情页我额外做了“如果库存为 0，不可加入购物车”的判断，这个逻辑如果想在 JSP 里做，就用 c:if 判断 p.stock > 0，否则把“加入购物车”按钮替换成“暂时缺货”的灰色按钮。用户体验好很多，也少了很多后端拦截后弹警告的情况。

3.3 JDBC 连接 MySQL：驱动加载、连接池和 URL 参数

整个项目最会作妖的部分，不是业务逻辑，而是数据库连接。很多新手本地跑 ClassNotFoundException: com.mysql.jdbc.Driver 或连接超时，十有八九是驱动版本和连接 URL 参数搞错。我这里给一个能直接跑的配置。

MySQL 8.x 要用 com.mysql.cj.jdbc.Driver，而不是老版本 5.x 的 com.mysql.jdbc.Driver。连接串建议写成：

properties复制jdbc.driver=com.mysql.cj.jdbc.Driver
jdbc.url=jdbc:mysql://localhost:3306/liquor_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
jdbc.username=root
jdbc.password=你的密码

serverTimezone=Asia/Shanghai 这个参数特别容易漏。MySQL 8.0 以后如果时区信息不对，连接时会报 The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized 的时区异常。useSSL=false 关掉 SSL 警告，本地开发没必要启用。characterEncoding=utf8 保证中文参数不乱码。

连接池我推荐先用 HikariCP。在 WEB-INF/lib 下放 mysql-connector-java-8.0.33.jar 和 HikariCP-5.0.1.jar，再写一个 DBUtil 工具类：

java复制public class DBUtil {
    private static final HikariDataSource DATA_SOURCE;

    static {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/liquor_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai");
        config.setUsername("root");
        config.setPassword("123456");
        config.setDriverClassName("com.mysql.cj.jdbc.Driver");
        config.setMaximumPoolSize(10);
        DATA_SOURCE = new HikariDataSource(config);
    }

    public static Connection getConnection() throws SQLException {
        return DATA_SOURCE.getConnection();
    }
}

这套工具类看着简单，但它帮你把连接生命周期管住了。每次请求从池子里拿一个连接，用完关闭，池子自动回收，不会出现“用一次开一次数据库连接，把数据库连接数打满”的事故。我在做这个项目时，最初用 DriverManager 直连，压测的时候连接数瞬间飙到 50 多，换成 HikariCP 后稳定在个位数。

3.4 图片上传与商品图片定位

商品图片这块是我个人觉得最容易被低估的模块。很多教学项目都在数据库里存一个图片 URL 地址，页面直接引用外链。但真正的本地项目，图片要上传、要维护、要能访问，这里有个经典闭环要讲清楚。

我的方案是：上传请求为 UploadServlet，接收 Part 形式的文件，保存到本地磁盘的指定目录，比如 D:/upload/liquor/，文件名用时间戳加随机后缀，防止重名。然后把最终访问 URL 写入数据库。但问题来了：用户如果访问 localhost:8080/D:/upload/liquor/xx.png，浏览器根本找不到，因为 Tomcat 默认的静态资源映射只覆盖项目内的 webapp 目录。

解决方式是配置虚拟目录映射。在 Tomcat 的 conf/server.xml 的 <Host> 节点里加一行：

xml复制<Context path="/liquor_images" docBase="D:/upload/liquor" reloadable="true" />

或者更优雅的做法是写一个 ImageServlet，通过读取本地文件流，把字节返回给前端。后一种方式在部署到 Linux 服务器时不用改 Tomcat 配置，更加通用。

java复制@WebServlet("/images/*")
public class ImageServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        String path = req.getPathInfo(); // 例如 /8e2f3c.png
        File file = new File(UPLOAD_DIR, path);
        if (!file.exists()) {
            resp.sendError(404);
            return;
        }
        resp.setContentType("image/png");
        FileInputStream in = new FileInputStream(file);
        OutputStream out = resp.getOutputStream();
        byte[] buffer = new byte[8192];
        int len;
        while ((len = in.read(buffer)) != -1) {
            out.write(buffer, 0, len);
        }
        in.close();
    }
}

至于页面图片“坐标定位”或者“图片位置不对”的问题，本质上是布局问题。我的处理经验是：不要在 JSP 里强行用 CSS position: absolute 去定位商品图片，交给 Bootstrap 的响应式栅格。图片容器统一高度，商品图用 img-responsive 居中，必要时给图片外层加一个固定高度的 div，再配合 overflow: hidden 裁剪，保证同一行卡片高度一致。这样商品图不管原始尺寸多大，都能在页面里整齐排列。

4. 购物车与订单的完整闭环实现

4.1 购物车设计：用 Session 还是查数据库

购物车是商城项目的灵魂，设计方式也最能体现一个开发者对状态管理的理解。我见过两种做法：一种是把购物车数据全存 Session，简单粗暴；另一种是每次显示购物车都查数据库重算，更接近真实电商。

我最后采用了一种中庸方案：购物车在会话里维护一份，同时把它对应的数据结构设计成独立的 Java 类，不散落在 Servlet 方法里。

java复制public class Cart {
    private Map<Integer, CartItem> items = new HashMap<>();
    private double totalPrice;

    public void add(Product product, int count) {
        CartItem item = items.get(product.getId());
        if (item == null) {
            item = new CartItem();
            item.setProduct(product);
            item.setCount(count);
            items.put(product.getId(), item);
        } else {
            item.setCount(item.getCount() + count);
        }
        recalcTotal();
    }

    public void remove(int productId) {
        items.remove(productId);
        recalcTotal();
    }

    public void update(int productId, int count) {
        CartItem item = items.get(productId);
        if (item != null) {
            item.setCount(count);
            if (count <= 0) {
                items.remove(productId);
            }
        }
        recalcTotal();
    }

    private void recalcTotal() {
        totalPrice = items.values().stream()
                .mapToDouble(i -> i.getProduct().getPrice() * i.getCount())
                .sum();
    }
}

对应的 CartServlet 里，加入购物车的逻辑是：从 Session 取 Cart 对象，没有就 new 一个放进 Session。因为每次 HTTP 请求都是无状态的，Session 就是我们在用户浏览期间替他保管一块内存数据的容器。

用 Session 存购物车的好处是不用和数据库频繁交互，响应快，代码也直观。它的问题是用户换浏览器、清 Cookie 或者会话过期后购物车就没了。真实商城更喜欢把购物车数据持久化到 tb_cart 表，登录后从库里恢复。我这里建议新手先把 Session 版跑通，再考虑持久化，毕竟购物车只是辅助功能，订单才是交易的核心凭证。

4.2 生成订单与扣减库存的原子性问题

从购物车生成订单，是全程最需要小心翼翼的一段业务。用户点击“去结算”后，系统要做四件事：第一，从 Session 里拿出购物车数据；第二，校验购物车不为空；第三，计算订单总金额；第四，写订单表和订单明细表；第五，扣减商品库存；第六，清空购物车。

写订单表的时候我特别强调两点。订单号不依赖数据库自增主键，而要自己生成。因为自增 ID 很容易被猜到，比如第一笔订单是 1，第二笔是 2，竞对直接遍历就知道你的单量。我用的是 yyyyMMddHHmmss + 4 位随机数，只保证同一秒内不重复，阅读性也好。

java复制String orderNo = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date())
        + String.format("%04d", (int) (Math.random() * 10000));

订单明细要为每一种商品生成一条记录，记录商品 ID、下单时的名称、下单时的价格、数量。这一步是快照，因为商品价格后续可能调整，但订单一旦生成就锁定当时的交易价格。

最后扣库存，要用前面提到的原子 SQL：

java复制String sql = "UPDATE tb_product SET stock = stock - ? WHERE id = ? AND stock >= ?";
int rows = update.executeUpdate();
if (rows == 0) {
    throw new BizException("商品库存不足，下单失败");
}

这里需要把“生成订单”和“扣库存”放到同一个事务里。传统 JDBC 的写法是先 conn.setAutoCommit(false)，全部执行成功后 commit()，任何一个环节异常就 rollback()。如果不这样做，可能出现订单生成了但库存没扣，后面发货时才发现超卖甚至把库存扣成负数，这是商城项目不能接受的。我自己早期就犯过这个错，把库存扣减放在订单插入之后但没有引入事务，测试的时候买了 10 瓶啤酒，库存从 50 变成 40，再买 10 瓶直接变成 30，看起来“正常”，但一旦下单中途报错，数据就不一致了。

订单生成后，我把购物车从 Session 里 remove 掉，然后跳转到“下单成功”页面，页面展示订单号提醒用户保存。整套闭环跑下来，才算是一个能说服答辩老师的完整商城系统。

5. 部署运行、常见问题与优化建议

5.1 IDEA 运行 JavaWeb 项目的配置细节

本地运行这套项目的标准配置是：JDK 8 或 11，Tomcat 8.5 或 9，MySQL 8.0，IDEA 2021 及以上版本，项目结构为老式 Web 项目（不是 Spring Boot 那种内置容器的 jar 结构）。

IDEA 里最容易被卡住的是运行配置。新建项目后，要保证 src/main/webapp 被标记为 Web 资源目录，项目的 facet 里有 Web 配置，Artifacts 选择 Web Application: Exploded。然后创建 Tomcat Server 的 Run Configuration，Deployment 面板里把当前 artifact 加上，Application context 设为 / 或者 /liquor。

很多新手遇到的“启动 Tomcat 后访问 404”，大半是 deployment 里没有把 artifact 加上，或者应用上下文配了路径但访问时没带。理清这层关系最有效的办法：启动后看 IDEA 下方 Tomcat 日志，日志会打印 Web 应用上下文路径，一般是 Context path 那一行，访问地址就是 http://localhost:8080/项目路径/。

启动前还要确保 MySQL 已经启动、数据库和密码无误。MySQL 安装后注意初始化数据目录，mysql -u root -p 能登进去再说项目的事。连接数据库的密码如果和 DBUtil 里的不一致，一定要同步改，不然项目启动成功但一查询就报 Access denied。

5.2 常见问题速查表

我把整个开发过程里遇到的高频问题整理成了表格，按可能出现的顺序排好，基本覆盖了从环境配置到业务逻辑的大多数事故现场。

表格里最后一条其实很典型。新手写商品新增时，经常是 DAO 层插入成功，但返回页面时 productList 还是旧数据，因为列表查询在插入之前执行了。正确做法是新增完直接 redirect:product?action=list，让浏览器重新请求列表接口，这样数据一定是最新的。

5.3 安全边界与后续优化

项目跑通之后，如果还想让它经得起推敲，一定要补三块内容。

第一，密码不能明文存。我在建表时已经用注释提示了，实际做法建议用加盐哈希。可以用最简单的 MD5 加固定盐，更好的是 BCrypt。不要觉得这只是个练手项目无所谓，答辩时老师大概率会问数据库安全。

第二，所有 SQL 必须用 PreparedStatement 参数化查询，禁止字符串拼接 SQL。新手最顺手就是 "select * from tb_user where username = '" + username + "'"，这正好是 SQL 注入的经典入口。用占位符 ? 传参数，既安全又容易读，没有任何理由不使用。

第三，后台管理页面要有访问控制。虽然角色字段已经放在用户表里了，但单有字段没用，必须通过 LoginFilter 拦截请求，只放行管理员会话访问后台 Servlet。简单做法是在过滤器中判断 session 里的用户角色，不是管理员就重定向到登录页。

优化方向的优先级我建议这样排：排序与分页优先做，商品列表按销量或价格 ORDER BY，页面支持分页；其次是商品搜索，加一个关键字模糊查询；最后是订单状态管理，把“发货”“完成”这些状态在后台做成可操作按钮。排序和搜索是最能在答辩时展示编码能力的点，而且实现成本低，一把梭就能加完。

写在最后的实操体会

整个项目前前后后改了三轮，我对 JavaWeb 的理解才算真正到位。第一轮是照着教程敲，能跑但说不清为什么；第二轮开始自己拆模块，把购物车和订单闭环重写了一遍，才算理解 Session、事务这几个概念不是背出来的，是在项目里被迫想明白的；第三轮加了图片上传、连接池、权限过滤这些细节后，代码量涨了不多，但皮实程度天差地别。

如果你正在上手这个项目，我强烈建议别满足于“跑通”，可以试着做三件事：把 user 表改成支持记住登录状态的 token 登录；把商品列表加分页和搜索；再把订单表加上“取消订单回补库存”的功能。这三件事做完，你对这套技术栈的掌握程度基本可以出去接外包或者应付绝大多数校内项目了。最后分享一个我自己的习惯：每次改完代码，先在本地跑一遍全流程——注册一个新用户，加几件商品进购物车，下一单，后台改一下商品价格，再刷新前台看看。这套冒烟测试流程花不了几分钟，但能帮你挡住八成低级事故。