Java Web全栈实战：零食商店管理系统源码技术拆解

简介：这是一套面向Java Web开发初学者与中小型零食电商项目实践者的完整管理系统源码，解决线上零食店铺的商品管理、订单处理与数据统计等核心业务需求。资源包共322个文件，总大小51.48MB，涵盖92个Java后端逻辑文件、23个JSP动态页面、33个JavaScript交互脚本、26个CSS样式文件及73个JPG商品图等，技术栈清晰分层：Java实现业务与数据控制，JSP+JavaScript+CSS协同构建响应式前端界面，XML与properties文件支撑配置管理。已有377人学习下载，适合通过真实电商场景掌握MVC分层开发、购物车状态管理、订单流程闭环及营业额可视化统计等关键能力。源码结构规范，含bootstrap.min.css、easyui.css、sweetalert.css等主流UI组件样式，便于快速理解前后端协作机制并进行二次开发或课程设计拓展。 最近整理了一份零食商店管理系统源码，技术栈就是标题里写的 Java + JavaScript + CSS 三条主线：后端用 Java 处理业务逻辑、接口数据和数据库交互，前端用 JavaScript 负责页面交互和异步请求，CSS 负责整体界面布局和视觉效果。这个项目不算大，但完整走通了一个 Web 系统从数据库设计、后端接口、前端页面到部署运行的全流程，我把它分享出来，也把实现过程中的设计思路和踩坑点一起写清楚。

适合谁看？主要是三类人：第一是准备课程设计或毕业设计的学生，需要一个功能完整、能跑通、能说清原理的系统；第二是刚学完 Java 基础、想通过一个实际项目把 Servlet、JDBC、JSP 这些串联起来的初学者；第三是想模仿一个全栈项目练手的开发者，看看别人是怎么分层、怎么设计数据库、怎么处理并发和异常细节的。

这篇内容会包含：项目整体设计思路、数据库表结构、后端 Java 核心代码逻辑、前端 JavaScript 交互细节、CSS 布局方案、本地部署步骤，以及我在实际跑这个项目时遇到的典型问题。你可以把它当作一份技术拆解，也可以直接照着源码改造成自己的项目。

1. 项目定位与整体设计思路

1.1 系统核心功能拆解

先把这个系统到底做什么讲清楚。这是一个面向校园/社区小卖部场景的零食商店管理系统，包含用户端和管理端两个入口。

用户端功能：

• 注册登录：用户注册账号、登录，登录后才有加购物车和下单的权限
• 商品浏览：首页展示所有零食商品，支持按分类筛选
• 商品详情：点击商品查看详情，包括价格、库存、描述
• 购物车：加入购物车、修改数量、删除商品、计算总价
• 下单结算：从购物车生成订单，模拟支付后订单状态变为已支付
• 我的订单：查看个人历史订单和订单状态

管理端功能：

• 管理员登录：账号和普通用户区分开，进入不同后台
• 商品管理：商品信息的增删改查，包括上下架、库存调整
• 分类管理：维护零食分类，如膨化食品、饮料、糖果、坚果等
• 订单管理：查看所有用户订单，修改订单状态，比如发货、完成
• 用户管理：查看注册用户列表，禁用异常账号

功能看着不少，但每一个点都不复杂，正好适合作为综合练手项目。相比只写一个"图书管理系统"，零食商店的业务场景更生活化，商品、分类、购物车、订单之间的关联关系也更自然，写起来不会觉得脱离实际。

1.2 为什么选这套技术栈

有人会问，现在企业里都用 Spring Boot + Vue 前后端分离，为什么还写 Java + JavaScript + CSS 这种"原始"组合？我的看法是：学习路径不同，项目目标不同。

先看一张选型对比表：

这份源码之所以采用传统方式，是因为它能让你"看见"一个请求从浏览器发出来之后发生了什么：Tomcat 容器启动，Servlet 接收请求，调用 Service、DAO，再通过 JDBC 操作数据库，数据回传到 JSP 渲染成 HTML。这个过程如果用 Spring Boot，很多细节被框架封装了，反而不容易建立底层认知。

但也要强调一点：这个项目的分层思想与企业开发是一致的。你别看它用的是 Servlet，代码照样是 Controller-Service-DAO 三层结构。后面想升级成 Spring Boot，前面业务逻辑基本可以平移复用，只需要把 Servlet 换成 Controller、把 JDBC 换成 MyBatis 就行。

1.3 代码分层与目录设计

源码的目录结构我按惯例做了分包，大概长这样：

src/main/java/com/snack/ ├── bean/ 实体类：User、Product、Category、Cart、Order ├── dao/ JDBC访问层：ProductDao、OrderDao等 ├── service/ 业务逻辑层：ProductService、OrderService等 ├── servlet/ 控制器层：LoginServlet、CartServlet等 ├── filter/ 登录过滤、编码过滤 └── util/ 工具类：DBUtil、StringUtil src/main/webapp/ ├── admin/ 管理端页面 ├── css/ 全局样式 ├── js/ 前端交互脚本 ├── images/ 商品图片 ├── login.jsp 登录页 └── index.jsp 前台首页

这个分层的核心思想就是"各层只干自己该干的事"：Servlet 只负责接收参数、调用 service、决定跳转哪个页面；Service 只负责业务规则，比如下单时要校验库存、计算总价；DAO 只负责拼 SQL、执行数据库操作。这样做的好处是，任何一个环节出问题，你能直接定位到对应文件，而不是在一个大 Java 类里翻几百行代码。

2. 数据库设计与后端 Java 核心实现

2.1 数据表结构与关系设计

数据库设计是整个项目的地基。表结构没设计好，后面写代码到处别扭；表结构清爽了，业务代码写起来会很顺。这份源码一共设计了六张表：

这里有两个设计点值得说明。

第一个是订单和订单明细为什么要拆成两张表？因为一个订单包含多个商品，如果不拆，要么把多个商品拼在一个字段里，字符串处理非常痛苦，要么就没办法记录每个商品下单时的单价。拆成主表和明细表之后，orders 记录订单整体信息，order_item 记录每一条商品快照。这一步是标准的"一主多从"设计，在任何电商项目里都是这个套路。

第二个点是 order_item 里的 price 字段。为什么商品价格已经在 product 表里有了，订单明细还要再存一份？因为商品价格会变，用户下单时的价格必须"快照"到订单里，否则三天后商品涨价了，用户查订单发现价格变了，这是不可接受的事情。所以别嫌字段冗余，业务上必要的冗余一定要留。

数据库脚本我放在项目根目录的 sql/snack_shop.sql 里，包含建库、建表、初始数据的完整语句。初始管理员账号是 admin/123456，普通用户 test/123456，跑起来就能直接登录测试。

2.2 后端 Java 核心代码实现

后端代码里，最核心的部分就是登录和商品管理。先看登录，这是整个系统权限控制的第一道关卡。

@WebServlet("/user/login") public class LoginServlet extends HttpServlet { @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding("UTF-8"); String username = req.getParameter("username"); String password = req.getParameter("password"); User user = userService.login(username, password); if (user != null) { HttpSession session = req.getSession(); session.setAttribute("loginUser", user); if ("admin".equals(user.getRole())) { resp.sendRedirect(req.getContextPath() + "/admin/index.jsp"); } else { resp.sendRedirect(req.getContextPath() + "/index.jsp"); } } else { req.setAttribute("error", "用户名或密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); } } }

登录成功之后，把 user 对象放进 Session。这里有个关键点：后续所有需要登录的页面都会通过 Filter 检查 Session 里有没有 loginUser 这个属性，没有就直接重定向到登录页。Filter 的注册用 @WebFilter("/*") 注解，然后通过判断请求路径是否包含 admin 或需要登录的前台页面来做过滤逻辑。

商品查询这里用到了基本的 JDBC 封装。以商品列表为例，核心代码是这样的：

public List<Product> findProductsByCategory(int categoryId) { List<Product> list = new ArrayList<>(); String sql = "SELECT * FROM product WHERE status = 1"; if (categoryId > 0) { sql += " AND category_id = ?"; } try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { if (categoryId > 0) { ps.setInt(1, categoryId); } try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { Product p = new Product(); p.setId(rs.getInt("id")); p.setCategoryId(rs.getInt("category_id")); p.setName(rs.getString("name")); p.setPrice(rs.getBigDecimal("price")); p.setStock(rs.getInt("stock")); p.setImage(rs.getString("image")); p.setDescription(rs.getString("description")); list.add(p); } } } catch (SQLException e) { e.printStackTrace(); } return list; }

这里特意用了 PreparedStatement 而不是拼字符串，原因只有一个：防 SQL 注入。如果用字符串拼接 categoryId，传入的参数一旦带恶意 SQL 片段，整个表都可能被攻击。PreparedStatement 通过预编译和参数占位符从机制上杜绝了这个问题，这是写任何 Java Web 项目的底线要求，不是可选项。

2.3 库存扣减：一个容易被忽略的并发问题

这个项目里我觉得最有讲解价值的一个点，是下单时的库存扣减逻辑。很多人第一次写库存操作会这样写：

// 反例演示，不要这样写 int stock = productDao.getStock(productId); if (stock >= quantity) { productDao.updateStock(productId, stock - quantity); }

这段代码在单用户测试环境下没问题，一旦两个用户同时下单购买同一件商品，就可能出现"超卖"：两个请求都读到 stock=5，都判断够扣，先后执行更新，库存实际变成 3 而不是 4，甚至更极端的场景下变成负数。

正确的做法是把"查库存"和"扣库存"合并成一条原子的 SQL 更新语句：

public int deductStock(int productId, int quantity) { String sql = "UPDATE product SET stock = stock - ? WHERE id = ? AND stock >= ?"; try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, quantity); ps.setInt(2, productId); ps.setInt(3, quantity); return ps.executeUpdate(); } catch (SQLException e) { e.printStackTrace(); return 0; } }

返回 0 表示 affected rows 为 0，说明库存不足，下单失败；返回 1 表示扣减成功。这个方法既保证了原子性，数据库层面单条 UPDATE 本身就是原子的，又省去了先查询再判断的往返。

下单事务也是一个可以聊的细节。生成订单包含三件事：向 orders 表插入主记录、向 order_item 插入明细、扣减商品库存。这三件事必须要么全部成功、要么全部失败。如果在插入明细后、扣减库存时抛异常，订单数据就不完整了。因此下单逻辑必须开启数据库事务：

Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 关闭自动提交 // 1. 插入订单主表 // 2. 插入订单明细 // 3. 扣减库存 conn.commit(); // 全部成功才提交 } catch (SQLException e) { conn.rollback(); // 任何一步失败整体回滚 e.printStackTrace(); } finally { conn.setAutoCommit(true); DBUtil.close(conn); }

对这个体量的系统来说，事务手动控制足够了。等你以后上 Spring Boot，直接用 @Transactional 注解，但底层原理还是这个。

3. 前端 JavaScript 交互与 CSS 界面细节

3.1 购物车模块的 JavaScript 实现

前端交互里最核心的模块是购物车。用 JavaScript 控制购物车里的数量增减、删除、总价计算，是这份源码里 JavaScript 应用最多的部分。

购物车页面的数量输入框绑定了 change 事件，用户修改数量后自动异步更新后端数据，同时页面上的小计、合计要同步刷新。初始化时给所有数量框绑定事件的代码：

document.querySelectorAll('.quantity-input').forEach(function (input) { input.addEventListener('change', function () { let productId = this.getAttribute('data-product-id'); let quantity = parseInt(this.value); if (isNaN(quantity) || quantity < 1) { quantity = 1; this.value = 1; } updateCartItem(productId, quantity); }); });

这里有一个 JavaScript 初学者非常容易踩的坑——闭包陷阱。早期写法喜欢用 for 循环给多个元素绑事件，比如：

// 反例演示 var inputs = document.querySelectorAll('.quantity-input'); for (var i = 0; i < inputs.length; i++) { inputs[i].addEventListener('change', function () { console.log(i); // 永远打印 inputs.length }); }

为什么 i 永远是最后一个值？因为 var 声明的变量是函数级作用域，循环结束后 i 变成了 inputs.length，所有闭包共享同一个 i。解决办法有两个：一是把 var 改成 let，let 是块级作用域，每次循环迭代都会创建独立的绑定；二是用 forEach 或者立即执行函数包裹一层。项目中我统一用 let 和 forEach，从源头上避开这种问题。

价格计算部分有一个 JavaScript 隐式转换的经典陷阱。用户可能在输入框里拿到的是字符串，如果你用 + 号直接相加，结果会变成字符串拼接：

// 反例：'19.9' + '9.9' 结果是 '19.99.9'，不是 29.8 let total = parseFloat('19.9') + parseFloat('9.9'); // 正确做法

这个项目里所有的总价计算我都强制用 parseFloat 转换后再算，并且最终结果保留两位小数，避免出现本不该有的浮点数精度问题。这两个点虽然不起眼，但在面试里很容易被问到："购物车的价格计算你考虑过类型问题吗？""for 循环绑定事件的闭包问题怎么解决？"源码里我已经给出了标准答案，你能理解背后的原因，比硬背结论有用得多。

3.2 表单验证与异步请求的实现

注册页面和后台商品编辑页面涉及表单校验。前端校验先用 JavaScript 做第一层筛除，比如用户名不能为空、密码长度不少于 6 位、价格必须是大于 0 的数字。后端 Servlet 里再做二次校验，防止跳过前端直接构造请求。

注册页面的前端校验代码片段：

function validateRegisterForm() { let username = document.getElementById('username').value.trim(); let password = document.getElementById('password').value; let confirmPwd = document.getElementById('confirmPwd').value; if (username === '') { alert('用户名不能为空'); return false; } if (password.length < 6) { alert('密码长度不能少于6位'); return false; } if (password !== confirmPwd) { alert('两次输入的密码不一致'); return false; } return true; }

这里提醒一句：前端校验只是用户体验层面的"早发现早提示"，真正的安全底线在后端。任何数据在 Java 代码里都要重新校验一遍，前端传过来的数据默认是不可信的，这个原则到企业项目里也一样成立。

购物车数量修改这种局部刷新的需求，我用的是 Fetch API 发异步请求。之所以没有引入 jQuery，是因为这个项目要尽量保持依赖最小，原生 JavaScript 已经足够应付这些场景。请求的写法：

async function updateCartItem(productId, quantity) { let formData = new URLSearchParams(); formData.append('productId', productId); formData.append('quantity', quantity); let resp = await fetch('/snack/cart/update', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8' }, body: formData.toString() }); let data = await resp.json(); if (data.code === 200) { refreshTotal(); } else { alert(data.msg); } }

注意 Content-Type 的写法，这里容易踩坑。用 URLSearchParams 拼 body 时，后端如果没有配置编码过滤器，中文参数会乱码；配置了正确 charset=UTF-8 之后就正常了。这个项目里我在后端加了 CharacterEncodingFilter，对所有请求和响应统一设置 UTF-8，这一步省掉了后面很多乱码麻烦。

3.3 CSS 布局选型与界面美化方案

CSS 部分我走的是"轻量美观、不引入重型框架"的路线。没有用 Bootstrap，纯手写样式，好处是文件体积小、完全可控，也方便你学习 CSS 本身。

页面整体布局上，主要用 Flex 和 Grid 配合。商品列表用了 CSS Grid，因为商品卡片天然是行列网格结构，Grid 一行代码就能控制列数：

.product-grid { display: grid; grid-template-columns: repeat(auto-fill, minmax(220px, 1fr)); gap: 20px; }

auto-fill + minmax 的组合能让商品卡片在不同屏幕宽度下自动换列，相当于免费获得了一个简易的响应式效果。这个写法比固定写死 3 列要灵活很多。

导航栏、表单、按钮这一类"一维排列"的场景用 Flex 更顺手：

.navbar { display: flex; justify-content: space-between; align-items: center; padding: 0 20px; }

Flex 和 Grid 不是互斥关系，而是各管一摊：一维布局用 Flex，二维网格用 Grid。这也是现在前端的主流共识。如果你还在纠结这两个属性怎么选，记住一句话就够了：要"排一行"用 Flex，要"排一个面"用 Grid。

写 CSS 时最容易让新手暴躁的问题有两个。第一个是盒模型混乱，元素加了 padding 或 border 后宽度溢出容器。解决方法是在全局样式的开头加一行：

* { box-sizing: border-box; }

第二个是垂直居中写不出来。以前要写很多行 hack，现在一行 Flex 就能解决：

.center-all { display: flex; justify-content: center; align-items: center; }

这两个问题我在项目开发过程中反复遇到，最后直接在最上面做了全局重置，一劳永逸。你如果自己从零写界面，建议一开始就把这两个规则加上。

4. 项目部署运行与问题排查实录

4.1 本地环境搭建与启动步骤

拿到源码想在本地跑起来，按下面的顺序操作就行。假设你已经装了 JDK 8 以上版本、IDEA 或者 Eclipse、MySQL 5.7 或 8.0、Tomcat 8.5 或 9。

第一步，初始化数据库。打开 MySQL 命令行或 Navicat，执行项目根目录 sql 文件夹下的 snack_shop.sql，会自动创建 snack_shop 数据库、六张表和初始数据。

第二步，修改数据库连接配置。源码里专门建了一个 jdbc.properties 文件：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/snack_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false jdbc.username=root jdbc.password=123456

注意如果你的 MySQL 是 8.x，驱动类名必须是 com.mysql.cj.jdbc.Driver，并且 URL 里要带 serverTimezone=Asia/Shanghai；如果是 MySQL 5.7，驱动类名是 com.mysql.jdbc.Driver。这两个版本参数写错了，启动后访问数据库必然报错。密码改成你自己 MySQL 的密码。

第三步，部署到 Tomcat。如果你用 IDEA，直接配置 Tomcat Server，然后把项目打成 war 包或者用 IDEA 的 Artifact 部署。如果你不用 IDE，也可以把编译好的项目整个丢到 Tomcat 的 webapps 目录下，启动 Tomcat 后访问 http://localhost:8080/snack_shop/ 即可。

第四步，登录系统。管理员账号 admin/123456 进入后台管理，普通用户 test/123456 模拟前台购物下单。

4.2 常见报错与解决办法速查表

我在实际运行这个项目时，以及平时帮别人排查时，遇到的最多的就是下面这些报错。整理成表格，方便你直接对照处理：

这些报错里有几个是新手阶段必踩的。比如端口占用，很多人第一次装完 MySQL 再装 Tomcat，发现 8080 被别的程序占了，直接一脸懵，其实用 netstat -ano | findstr 8080 查出 PID，进任务管理器结束进程就行，或者更保险一点改 Tomcat 端口。

4.3 我在跑这个项目时印象最深的三个坑

分享几个我从这段源码里实际踩过的坑，都不是文档里会写的那种。

第一个坑是数据库连接没复用，导致页面卡顿。早期版本直接每次 new Connection，系统能跑，但一旦有多个用户并发访问，数据库连接反复创建和销毁，响应时间明显变长。后来改成 Druid 连接池之后，性能稳定了非常多。连接池的概念不难：它就是一个"连接复用池"，预先创建好一批连接，谁要用谁取，用完归还，避免频繁建立 TCP 连接的开销。这个优化虽然代码改动不大，但对系统的稳定性提升是本质性的。

第二个坑是前端 JS 把价格计算寄托在浮点数比较上。有次测试结算时，某件商品价格 0.1 元，买三件总价显示

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