JavaWeb仿小米商城项目实战：从Servlet到订单事务全流程解析

简介：这是一套面向JavaWeb初学者与课程设计者的仿小米在线商城实战项目，聚焦Servlet+JSP+MySQL技术栈的完整电商功能实现，涵盖商品浏览、详情查看、购物车添加及价格实时计算等核心业务逻辑。资源包共2个文件，包含一个39.94MB的完整Web应用工程压缩包（含HTML/CSS/JavaScript/jQuery前端页面、Java Servlet后端逻辑、JDBC数据库连接及MySQL建表脚本）和一个独立的shop.sql数据库初始化文件，结构清晰、模块分明，便于导入部署与代码研读。已有28026人学习下载，广泛用于高校JavaWeb课程实训、毕业设计参考及自学能力提升。读者可直接运行项目理解MVC分层思想，掌握前后端交互细节、会话管理机制与数据库增删改查实践，同时获得可二次开发的完整源码基础与标准化SQL建模方案。 做JavaWeb练手项目，我见过太多人一上来就怼Spring Boot，结果连HTTP请求怎么从浏览器流到Servlet都说不清楚。如果你正处于大二大三、或者刚自学完JavaSE想找个完整项目练手，这个仿小米商城的ShoppingMall项目，恰好是帮你把Servlet/JSP/MySQL这些基础彻底打通的好选择。项目本身不依赖任何重量级框架，用最原生的JavaWeb技术栈，把一个真实电商网站的前台展示、购物车、下单支付流程和一整套后台管理完整做出来，学完之后你再去看市面上的框架课程，会发现那些概念一下就通了。

这篇文章我会把一个完整的JavaWeb仿小米商城项目从设计到落地的全过程拆开讲一遍：包括数据库怎么设计、购物车用Session还是存数据库、订单事务怎么处理、后台图片上传怎么搞、以及部署到Tomcat时那些高频报错怎么排查。内容尽量贴着实际开发时的思考过程来写，里面有大量我自己踩过的坑和后来总结的改进方案，建议跟着思路，一个模块一个模块地动手敲。

1. 项目整体设计与功能拆解

1.1 商城项目的核心功能模块

做任何项目之前，先把需求想清楚，这是最重要的一步。仿小米商城这个ShoppingMall项目，拆开来看，其实就是一个“前台卖货、后台管货”的双端系统，一共分成两大块。

前台这一侧，核心是用户能走的完整购物流程：用户注册登录后，在首页看到商品分类和推荐位，点进商品列表页按条件筛选，再点进详情页看大图和描述，满意了就加购物车，去购物车调整数量或删除，然后提交订单、模拟支付，最后在个人中心看到订单列表和状态变化。这里每一步都是独立的页面和独立的Servlet接口，但它们串在一起就形成了一条完整的业务闭环。

后台这一侧，是管理员用来维护商城数据的操作台：登录验证后进入管理首页，能看到商品总数、订单总数、用户总数这些统计信息；然后要能做商品分类管理（增删改查）、商品管理（上架、下架、编辑、图片上传）、订单管理（查看订单详情、修改订单状态）、用户管理（列表展示、禁用/启用账号）。后台看起来简单，但它是检验一个人对“权限控制”理解深不深的地方——绝对不能从前台登录一下就能打开后台页面。

1.2 技术选型：为什么不用框架反而更好

这个项目我刻意避开了Spring、SpringBoot、MyBatis这类的框架组合，全部用JavaWeb原生生态来做：Servlet处理请求、JSP渲染页面、JDBC操作数据库、Filter做拦截过滤、Listener做启动初始化。你可能会有疑问：现在企业里都上SpringBoot了，学这些老古董还有什么用？

这里我讲一下个人理解。框架的本质是封装和自动化，Servlet和JSP才是理解Web应用的底层逻辑的钥匙。你只有亲手写过doGet、doPost，才明白请求参数是怎么从HTTP协议里解析出来、又是怎么通过Response返回给浏览器变成HTML页面的；你只有自己手写过分页查询的SQL，才懂MyBatis-Plus那行page()背后到底帮你做了什么事。所以练手阶段用原生的这套组合，恰恰是为了之后学框架时不死记硬背，而是能真正看懂它们在解决什么问题。

前端部分我也没有引Vue或者React，用的是HTML + CSS + JavaScript + jQuery + Ajax。原因很简单：知识点太多会冲淡JavaWeb本身的学习目标。这个阶段前端能完成页面渲染和Ajax交互就够了，把精力集中在后端逻辑上，等后端通了，以后要接前端框架也就是改改接口返回格式的事。

1.3 项目目录结构与MVC分层

项目的代码组织上，我严格按照MVC分层思想来拆包，这一点在面试里也经常被问到。基本的包结构是：entity（实体类，对应数据库表结构）、dao（数据访问层，写JDBC和SQL）、service（业务层，处理事务和业务规则）、servlet（控制层，接收请求和分发响应）、util（工具类）、filter（拦截器）、listener（监听器）。

这样的分包方式有什么好处？最直接的是职责清晰。一个请求到达以后，Servlet只负责“接客”和“转手”，不写业务逻辑；Service层只处理业务，不写SQL；DAO层只跟数据库打交道，不关心页面长什么样。改起来的时候，比如你想把数据库从MySQL换成Oracle，理论上只需要改动DAO层，其他一层都不用碰。这个思想不管以后你用什么框架，都是通用的。

2. 数据库设计与搭建

2.1 表结构设计：六张核心表

数据库设计是商城项目的根基，表建不好，后面写代码处处踩坑。我用的MySQL数据库，字符集统一utf8mb4，一共设计了六张核心表：用户表、分类表、商品表、购物车表、订单表、订单明细表。另外还可以加一张轮播图表和一张收货地址表，属于锦上添花，看你自己时间。

用户表（t_user）我保留了最核心的字段：用户ID（主键自增）、用户名、密码（MD5加密）、昵称、手机号、邮箱、头像地址、角色（1是普通用户，2是管理员）、注册时间、状态。注意状态字段，这个在后台用户管理里要用到，禁用用户就是改这个值。

分类表（t_category）简单：分类ID、分类名称、父分类ID、排序号。为什么加父分类ID？因为小米商城这种大平台分类一般有两级（比如“手机”下面还有“小米手机”“Redmi手机”），做成一父多子结构，以后要扩展就很容易。

商品表（t_product）是字段最多的表：商品ID、商品名称、副标题、分类ID（外键关联分类表）、主图地址、轮播图地址（多个图片地址用逗号分隔）、商品详情（长文本）、价格、原价（用来显示划线价）、库存数量、销量、是否上架、创建时间。这里有个细节：商品图片我只存了图片的文件名或者相对路径，不存整张图片的二进制数据，这是规范做法，图片本身扔到Tomcat的部署目录或者静态资源目录，数据库里只存一个字符串路径。

订单表（t_order）和订单明细表（t_order_item）是父子关系。订单表存的是订单编号、下单用户ID、收货人、联系电话、收货地址、订单总金额、订单状态、下单时间。订单明细表存的是明细ID、订单编号（关联订单表）、商品ID、商品名称（快照）、商品图片（快照）、购买价格（快照）、购买数量、小计金额。

为什么明细表里要存商品名称、图片、价格这些看起来冗余的信息？这是电商系统的常见设计，叫做“快照”。避免以后商品改名、改价或者直接被删除，历史订单却变得对不上了。这个点挺重要的，你在设计表的时候就要有这个意识，省得以后写订单详情页的时候发现商品已经没了，只能显示一个空壳。

2.2 建表SQL和初始化数据

建表SQL这里我贴一下重点表的结构，你们可以直接参考。

CREATE DATABASE IF NOT EXISTS shopping_mall DEFAULT CHARACTER SET utf8mb4; USE shopping_mall; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(50), phone VARCHAR(20), email VARCHAR(100), avatar VARCHAR(255), role INT DEFAULT 1, status INT DEFAULT 1, create_time DATETIME ); CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, parent_id INT DEFAULT 0, sort INT DEFAULT 0 ); CREATE TABLE t_product ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL, subtitle VARCHAR(200), category_id INT, main_image VARCHAR(255), sub_images TEXT, detail TEXT, price DECIMAL(10,2), original_price DECIMAL(10,2), stock INT, sales INT DEFAULT 0, is_sale INT DEFAULT 1, create_time DATETIME ); CREATE TABLE t_cart_item ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT, product_id INT, quantity INT, checked INT DEFAULT 1, create_time DATETIME ); CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id INT, receiver_name VARCHAR(50), receiver_phone VARCHAR(20), receiver_address VARCHAR(255), total_amount DECIMAL(10,2), status INT DEFAULT 10, create_time DATETIME ); CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32), product_id INT, product_name VARCHAR(100), product_image VARCHAR(255), current_price DECIMAL(10,2), quantity INT, total_price DECIMAL(10,2) );

订单状态我用了整数常量来标识，比如10待支付、20已支付、30已发货、40已完成、50已取消。为什么不用字符串“待支付”？一是存整数性能更好，二是在代码里可以定义常量类统一管理，看起来更规范，也方便以后做状态流转判断。

初始化数据方面，分类表先插入“手机”“电视”“笔记本”“家电”“配件”几个大类，每个大类下面再插一两个子分类；商品表每个分类插三五条商品，数据内容可以随便编，但图片路径要放真实的图片进去，不然页面会显示破图。我当时是用一些免费图床上传了几张商品图，然后直接把图片URL写在数据库里，这样开发阶段页面效果好看很多，也不会因为本地图片文件缺失而出问题。

2.3 连接池配置与JDBC工具类封装

JavaWeb连数据库，最怕的就是每个DAO里都写一遍Class.forName("com.mysql.jdbc.Driver");DriverManager.getConnection()，然后finally里关连接。第一是重复代码太多，第二是性能不行——每次请求都新建物理连接，高并发下数据库直接被拖垮。

所以我在项目里引入了Druid连接池，阿里巴巴开源的，配置简单而且自带监控功能。配置一个druid.properties文件：

driverClassName=com.mysql.cj.jdbc.Driver url=jdbc:mysql://localhost:3306/shopping_mall?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 username=root password=你的数据库密码 initialSize=5 maxActive=20 maxWait=3000 minIdle=2

然后写一个工具类，用一个静态代码块加载配置文件并初始化Druid数据源，提供两个方法：一个从连接池拿连接，一个释放资源（把连接还给连接池而不是物理关闭）。

public class DBUtils { private static DruidDataSource dataSource; static { try { Properties props = new Properties(); props.load(DBUtils.class.getClassLoader().getResourceAsStream("druid.properties")); dataSource = (DruidDataSource) DruidDataSourceFactory.createDataSource(props); } catch (Exception e) { e.printStackTrace(); } } public static Connection getConnection() throws SQLException { return dataSource.getConnection(); } public static void close(Connection conn, Statement stmt, ResultSet rs) { if (rs != null) { try { rs.close(); } catch (SQLException e) { } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { } } if (conn != null) { try { conn.close(); } catch (SQLException e) { } } } }

注意：MySQL 8.x版本的驱动类名是com.mysql.cj.jdbc.Driver，不是老的com.mysql.jdbc.Driver，而且URL里必须带serverTimezone参数，否则会报时区异常。这个坑99%的初学者都会踩，一定注意。

3. 前台核心功能实现解析

3.1 用户注册登录与Session会话管理

用户模块是整个商城的第一道门，任何人下单、评论都离不开它。注册功能我实现了用户名唯一性校验、两次密码一致性校验、手机号格式校验，密码存库之前用MD5加盐处理，防止数据库泄露后明文密码直接暴露。

登录的设计上有个点需要注意：登录成功之后，怎么记住这个用户的登录状态？我当时的方案是把用户对象整体存到Session里，键名就叫"loginUser"。然后写了一个LoginFilter，拦截所有除登录页、注册页、静态资源之外的请求，判断Session里有没有loginUser，没有就直接重定向到登录页。

@WebFilter("/*") public class LoginFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse resp = (HttpServletResponse) response; String uri = req.getRequestURI(); // 放行静态资源和登录相关接口 if (uri.contains("/login") || uri.contains("/register") || uri.contains("/css/") || uri.contains("/js/") || uri.contains("/images/") || uri.contains("/index")) { chain.doFilter(request, response); return; } Object user = req.getSession().getAttribute("loginUser"); if (user == null) { resp.sendRedirect(req.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }

用Session而不是Cookie存用户信息，原因很简单：Session的数据保存在服务器端，客户端手里只有一个SessionID，想伪造和篡改都难得多，而且Session天然有超时机制，用户一段时间不操作自动失效，安全性和体验都更好。如果你做了Cookie存用户信息，一定要记得加HttpOnly和加密处理，不然后患无穷。

3.2 商品列表分页与分类检索

商城的商品列表页是访问量最大的页面，肯定不能一次把几百条商品全查出来渲染到页面上。这里就要做分页。我封装了一个PageBean类，包含当前页码、每页条数、总条数、总页数、当前页数据列表这几项，然后DAO层写一个方法查总数，再写一个方法查当前页的数据，用LIMIT ? OFFSET ?实现。

关键SQL大概是这样的：

SELECT * FROM t_product WHERE category_id = ? AND is_sale = 1 ORDER BY id DESC LIMIT ? OFFSET ?;

计算总页数的逻辑：totalPage = (int) Math.ceil(totalCount * 1.0 / pageSize)。分页条上显示上一页、下一页、页码列表，点击页码时通过?page=2&categoryId=3这样的参数传回Servlet重新查询。这里有个细节要注意：接收页码时一定要做参数校验，用户手动改成负数或者超过总页数，后端要兜底处理，不能查出一个空列表让前端报错。

分类检索其实就是给分页查询多加一个category_id的过滤条件，如果分类是二级的，还得先查出该分类下的所有子分类ID，用IN查询子分类下的所有商品。

3.3 购物车实现：Session存储还是数据库存储

购物车是商城项目里最有讨论价值的一个模块，因为设计方案的取舍直接决定了代码复杂度。我当时最开始图省事，把购物车整个放在Session里，结构是一个Map<Integer, CartItem>，key是商品ID，value是购物车条目（包含商品信息和数量）。这样做的确简单，加购就是把商品塞进Map，Session不失效数据就不丢，页面渲染时直接遍历Map，完全不用操数据库。

但后来我发现这个方案有明显的坑：用户清一下浏览器缓存或者Session超时，购物车里的东西就全没了。而且更严重的是，如果用户在不同设备上登录，购物车互相不共享，这在实际场景里是不可接受的。所以我最终改成了数据库存储方案，建了t_cart_item表，以用户ID和商品ID为维度存购物车数据。

数据库方案的核心逻辑是：查询购物车列表时，先根据用户ID从t_cart_item表查出所有条目，再连表查出商品的最新信息；加购时先检查这个用户有没有加过同一商品，加过就做数量累加，没加过就插入新记录；修改数量就执行UPDATE；删除就执行DELETE。这样一来，用户换设备、清缓存，只要重新登录，购物车数据还在，也方便以后做“稍后购买”“商品收藏”这类扩展。

补充一个细节：如果购物车里的商品被后台下架或者删除了，商品列表查出来可能为空。所以我在查询购物车时做了关联商品状态过滤，状态异常的条目直接提示用户“该商品已失效”，前端渲染时置灰显示，这个体验细节值得做一下。

3.4 订单提交与事务管理

订单模块是整个项目里最容易出Bug的地方，为什么？因为一个订单的提交涉及多张表的修改：往订单表插一条记录、往订单明细表插多条记录、扣减商品库存、清空购物车，这四步操作必须绑在一起，做一个“要么全成功、要么全失败”的原子性保证，也就是事务管理。

JDBC里控制事务的办法很简单：在Service层拿到Connection之后，先conn.setAutoCommit(false)，然后执行多条SQL，全部成功后conn.commit()，任何一步抛出异常就conn.rollback()，最后把连接还给连接池。要注意的是，不能用DAO层各自拿连接去执行SQL，因为那样各用各的连接，事务根本控制不住。我当时踩过一个很惨的坑：库存扣减成功、订单也插进去了，但是明细插入失败，回滚的时候发现因为连接不是同一个，回滚根本不起作用，结果数据库里多了好几条孤儿订单。后来改成Service层统一管理连接，并且把Connection通过参数传递到DAO层，问题才解决。

订单状态流转上，我定义了常量类，10待支付、20已支付、30已发货、40已完成、50已取消，支付这块因为是模拟项目，没有接真实的支付宝或微信支付接口，只是让用户确认一下“模拟支付”按钮，点击后把订单状态从10改成20。如果你想让项目更完整，可以接一个沙箱支付（比如支付宝沙箱环境），但那是另一个大话题了，后面可以单独说。

4. 后台管理系统的设计实现

4.1 后台登录与权限隔离

后台管理端和前台最大的区别就是权限控制。我当时的做法是：用户表里加了一个role字段，1是普通用户，2是管理员。后台登录接口做了双重判断：首先用户必须存在且密码正确，其次role必须是2，否则前台用户就算把密码蒙对了也进不了后台。

权限隔离还体现在页面和接口两个层面。页面层面，后台的JSP都放在独立的admin目录下，然后写了一个AdminFilter，专门拦截/admin/*路径，检查Session里的用户role是否是2。这样做的好处是干净利落，接口路径天然分隔。有些项目直接把后台和前端混在一起，判断写在每个Servlet里，那样很容易漏，后期加接口容易忘记加权限判断，非常危险。

4.2 商品管理中的图片上传

后台商品管理的重头戏是图片上传功能。我用的方案是 commons-fileupload 组件，处理multipart/form-data格式的请求。核心步骤是：解析请求 -> 遍历文件字段 -> 把文件写入服务器磁盘目录 -> 把生成的访问路径存入数据库。

这里有几个关键细节。第一，上传目录要放在Tomcat部署项目的物理路径下，这样浏览器可以直接通过URL访问。我用的是request.getServletContext().getRealPath("/upload")拿到部署后的真实目录，然后以时间戳+随机数的方式重命名文件，避免重名覆盖。第二，要对文件大小和类型做限制——只允许jpg、png、gif，单张不能超过2MB。第三，一次只能传一张主图，多图的子图我简化成了一次传一张、点击追加的方式，多张图片地址逗号拼接。

文件上传表面看着简单，实际运行时经常出问题：配置文件不对、依赖包缺失、上传后图片无法访问。我建议你先把单个图片上传跑通，再考虑多图，不然调试会非常痛苦。

4.3 订单状态与发货管理

后台订单列表，默认展示所有订单，按照下单时间倒序排列，每行显示订单号、用户、金额、状态、下单时间。订单号我还加了详情按钮，点击弹出订单明细页，能看到用户购买的具体商品和数量。管理员的核心操作是“发货”：把订单状态从20（已支付）改成30（已发货）。

这里有个小技巧，我加了一个“待发货订单数”的统计角标，放在后台首页上，管理员一登录就能看到今天有没有要处理的订单。还有一个统计块的实现，需要联表查询：商品总数查t_product的count，订单总数查t_order的count，用户总数查t_user的count，今日下单量按create_time做日期区间查询。这个管理端首页虽然简单，但是特别能让项目显得完整，在答辩或演示时很加分。

5. 常见问题与排查技巧实录

5.1 环境配置与本地部署步骤

这个项目从零到能跑起来，环境配置反而是拦路虎。我梳理一遍完整的部署流程，你照着做就行：

1. 装好JDK1.8、Maven（项目用了Maven管理依赖）、Tomcat8.5或9、MySQL5.7或8.0、IDEA。

2. 创建数据库，执行我上面贴的建表SQL，再插入测试数据。

3. IDEA里创建一个Maven项目，POM里加入Servlet、JSP、JSTL、MySQL驱动、Druid连接池、commons-fileupload这些依赖。

4. 把项目配置到Tomcat：IDEA里的Run Configuration，选Tomcat Server，Local，Deployment里加Artifact。

5. 启动Tomcat，浏览器访问http://localhost:8080/项目名/index，能看到商城首页就说明环境通了。

5.2 高频报错与解决方案速查

我在开发和后来指导别人跑这个项目时，遇到过一大批几乎一模一样的问题，这里列出来给你省时间：

中文乱码这个坑要重点说。全项目涉及三处编码：JSP文件本身的编码（pageEncoding）、Tomcat接收请求参数的编码（post请求和get请求还不一样）、数据库连接URL的编码。我踩过的坑是在过滤器里设置了request.setCharacterEncoding("UTF-8")，但get请求的参数在Tomcat8之前默认是ISO-8859-1解析的，所以URL上的中文参数照样乱，后来干脆在Tomcat的server.xml里给Connector加了URIEncoding="UTF-8"，才算彻底根治。

5.3 线上问题复盘：事务失控与库存为负

除了环境问题，业务逻辑层面的Bug也很值得复盘。有一次我在测试下单功能时，明明库存只有5件，但订单提交成功后库存变成了负数。查了半天发现是并发问题——两个请求同时读到库存为5，各自扣减1，最后写回的时候互相覆盖，一个写4一个写3，最终库存被改成了3，但产生了两个订单，总量变成6，明显对不上。

解决的办法是在扣减库存的SQL上用原子操作：UPDATE t_product SET stock = stock - 1 WHERE id = ? AND stock > 0。这句话的意思是，扣库存这个动作本身就是原子的，数据库行锁保证了同一时间只有一个事务能改这条记录，并且stock > 0条件能保证扣成负数。如果update返回的影响行数是0，说明库存不足，直接回滚事务并提示用户。

这个问题当初折腾了我一个晚上，也让我真正理解了为什么电商系统里的并发控制那么关键。这个经验我建议你也亲手复现一遍，比看十遍理论都管用。

6. 项目扩展：从练手到可用的小优化

6.1 在商城中整合高德地图API的思路

有些场景下商城需要展示店铺自提点或者配送范围，这时候就可以在页面上接入地图API。比如你要在HTML页面里做“按关键字查询地点”，思路是引入高德地图的JS API，初始化一个AMap.Map实例，然后用AMap.PlaceSearch插件做关键字搜索，搜索结果通过AMap.Marker标注在地图上。

大概的流程是先在高德开放平台申请一个Web端(JS API)的Key，然后在JSP页面里通过<script>标签引入地图JS文件。初始化地图的时候设置中心点和缩放级别，搜索时把用户输入的关键字传给PlaceSearch，回调函数里拿到匹配的地点列表，遍历生成标记，并且点击标记可以弹出信息窗体显示名称和地址。这些能力可以跟后台的店铺表打通——把商家实体的地址存到数据库里，页面加载时批量查出来在地图上打点，用户在详情页就能直接看到门店位置。

我自己在项目里做过一版，前端HTML里只需要几步就能跑通。代码大概长这样：

<script src="https://webapi.amap.com/maps?v=2.0&key=你的Key"></script> <script> var map = new AMap.Map('mapContainer', { zoom: 11, center: [116.397428, 39.90923] }); AMap.plugin('AMap.PlaceSearch', function () { var placeSearch = new AMap.PlaceSearch({ pageSize: 5, pageIndex: 1, city: '全国', map: map }); placeSearch.search('小米之家', function (status, result) { if (status === 'complete' && result.poiList) { console.log(result.poiList.pois); } }); }); </script>

注意，地图API是纯前端能力，你只要把返回的数据格式搞清楚，就能很自然地把它集成进JavaWeb项目里，不需要后端做任何特殊处理。这个扩展非常适合写进结课报告的“项目亮点”里。

6.2 给项目加分的几个细节

如果你的项目要用来面试、答辩或者考研复试，我建议你在这些地方稍微多用点心：

一是增加一个搜索功能，商品列表页顶部的搜索框可以根据商品名称或副标题模糊查询，SQL用LIKE CONCAT('%', ?, '%')实现，注意用PreparedStatement占位符防止SQL注入风险。

二是把日志加上，引入slf4j + logback，在Service层关键位置打日志，比如用户登录成功、订单创建成功、异常堆栈输出。将来线上排问题，日志就是你的眼睛。

三是做一个简单的数据校验工具类，封装用户名格式、手机号格式、价格是否为正数这些公共校验逻辑，尽量别在各个Servlet里复制粘贴校验代码。

四是优化一下体验细节：商品详情页点击图片可以放大预览、购物车为空时的提示插画、登录时的验证码功能。验证码我用的Kaptcha组件，配置三分钟就能出来，但是对项目的观感提升很直接。

写在最后的个人心得

做这个JavaWeb仿小米商城ShoppingMall项目，前后花了我大约三周时间，白天写代码晚上看需求文档，中间踩过的坑比我想象中多得多。但回过头看，这恰恰是整个JavaWeb学习过程中收获最大的一段经历。因为这个项目逼着我把每个零散的知识点串联成了一个整体：Servlet怎么跟JSP配合、DAO层怎么抽象才能复用好写、事务在什么情况下会失效、线上问题要怎么一步步排查。这些能力是看书和看视频学不来的，必须亲手写一遍代码、亲手炸掉一个数据库、再亲手把它修好，才真正长在你自己身上。

如果你现在是刚学完JavaSE、想挑战第一个完整项目，我建议你直接从这个项目开始，但是一定不要对着网上的代码一行行抄，先自己画一个功能图，然后按模块逐渐实现，遇到不会的再去看参考代码。如果你已经做完了这个项目，下一步可以尝试把Spring、SpringMVC、MyBatis这些框架逐步迁入进来，你会发现原来很多你手写了很多遍的繁琐代码，框架就是用几行配置帮你完成了，但底层的东西你已经懂了，学起来完全是降维打击。

最后再分享一个小技巧：项目跑通之后，记得把你的建表SQL、项目结构说明、功能清单、运行截图整理成一份README文档，附上部署步骤和测试账号。这份文档不仅方便你自己以后查阅，也方便老师、面试官快速理解你的项目。好的项目能力不仅仅是代码写得6，能让别人轻松看懂你的作品，本身也是一种非常重要的能力。

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