尧图网站建设 
简介这是一套面向Java Web开发初学者与中小型零食电商项目实践者的完整管理系统源码解决线上零食店铺的商品管理、订单处理与数据统计等核心业务需求。资源包共322个文件总大小51.48MB涵盖92个Java后端逻辑文件、23个JSP动态页面、33个JavaScript交互脚本、26个CSS样式文件及73个JPG商品图等技术栈清晰分层Java实现业务与数据控制JSPJavaScriptCSS协同构建响应式前端界面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 这种原始组合我的看法是学习路径不同项目目标不同。先看一张选型对比表技术方案上手难度学习价值适合场景JSP Servlet JDBC低能看透 Web 底层原理课程设计、面试打底Spring Boot Thymeleaf中贴近企业主流后端开发找工作项目经验Spring Boot Vue 前后端分离较高业界主流前后端协作方式完整商业项目复刻这份源码之所以采用传统方式是因为它能让你看见一个请求从浏览器发出来之后发生了什么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 数据表结构与关系设计数据库设计是整个项目的地基。表结构没设计好后面写代码到处别扭表结构清爽了业务代码写起来会很顺。这份源码一共设计了六张表表名作用关键字段user用户表id、username、password、role、statuscategory商品分类表id、name、sortproduct商品表id、category_id、name、price、stock、image、description、statuscart购物车表id、user_id、product_id、quantityorders订单表id、order_no、user_id、total_price、status、create_timeorder_item订单明细表id、order_id、product_id、quantity、price这里有两个设计点值得说明。第一个是订单和订单明细为什么要拆成两张表因为一个订单包含多个商品如果不拆要么把多个商品拼在一个字段里字符串处理非常痛苦要么就没办法记录每个商品下单时的单价。拆成主表和明细表之后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 ListProduct findProductsByCategory(int categoryId) { ListProduct 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); }这段代码在单用户测试环境下没问题一旦两个用户同时下单购买同一件商品就可能出现超卖两个请求都读到 stock5都判断够扣先后执行更新库存实际变成 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 改成 letlet 是块级作用域每次循环迭代都会创建独立的绑定二是用 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;charsetUTF-8 }, body: formData.toString() }); let data await resp.json(); if (data.code 200) { refreshTotal(); } else { alert(data.msg); } }注意 Content-Type 的写法这里容易踩坑。用 URLSearchParams 拼 body 时后端如果没有配置编码过滤器中文参数会乱码配置了正确 charsetUTF-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.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/snack_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse jdbc.usernameroot jdbc.password123456注意如果你的 MySQL 是 8.x驱动类名必须是 com.mysql.cj.jdbc.Driver并且 URL 里要带 serverTimezoneAsia/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 常见报错与解决办法速查表我在实际运行这个项目时以及平时帮别人排查时遇到的最多的就是下面这些报错。整理成表格方便你直接对照处理报错现象根本原因解决办法页面访问 404项目部署路径与访问路径不一致确认 webapps 下项目目录名或 IDEA 中 Application context 配置MySQL 连接拒绝账号密码错误、端口不对或服务没启动检查 jdbc.properties确认 MySQL 服务状态ClassNotFoundException: com.mysql.cj.jdbc.DriverMySQL 驱动 jar 没引入在 WEB-INF/lib 下放入 mysql-connector-java 对应版本的 jar插入数据库中文变问号数据库编码或连接 URL 未指定 UTF-8URL 加 characterEncodingutf8建库时指定 utf8mb4控制台 Tomcat 中文乱码控制台输出编码问题修改 Tomcat 的 conf/logging.properties 或 IDE 控制台编码为 UTF-8端口 8080 被占用其他程序占用了 Tomcat 端口找到占用进程结束或修改 Tomcat server.xml 端口请求参数中文乱码请求和响应编码未统一配置 CharacterEncodingFilter 过滤器强制 UTF-8java.lang.OutOfMemoryError: insufficient memoryJVM 堆内存不够调整 Tomcat 的启动内存参数catalina.sh 中设置 JAVA_OPTS这些报错里有几个是新手阶段必踩的。比如端口占用很多人第一次装完 MySQL 再装 Tomcat发现 8080 被别的程序占了直接一脸懵其实用 netstat -ano | findstr 8080 查出 PID进任务管理器结束进程就行或者更保险一点改 Tomcat 端口。4.3 我在跑这个项目时印象最深的三个坑分享几个我从这段源码里实际踩过的坑都不是文档里会写的那种。第一个坑是数据库连接没复用导致页面卡顿。早期版本直接每次 new Connection系统能跑但一旦有多个用户并发访问数据库连接反复创建和销毁响应时间明显变长。后来改成 Druid 连接池之后性能稳定了非常多。连接池的概念不难它就是一个连接复用池预先创建好一批连接谁要用谁取用完归还避免频繁建立 TCP 连接的开销。这个优化虽然代码改动不大但对系统的稳定性提升是本质性的。第二个坑是前端 JS 把价格计算寄托在浮点数比较上。有次测试结算时某件商品价格 0.1 元买三件总价显示本文还有配套的精品资源点击获取 Java Web全栈实战：零食商店管理系统源码技术拆解
简介这是一套面向Java Web开发初学者与中小型零食电商项目实践者的完整管理系统源码解决线上零食店铺的商品管理、订单处理与数据统计等核心业务需求。资源包共322个文件总大小51.48MB涵盖92个Java后端逻辑文件、23个JSP动态页面、33个JavaScript交互脚本、26个CSS样式文件及73个JPG商品图等技术栈清晰分层Java实现业务与数据控制JSPJavaScriptCSS协同构建响应式前端界面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 这种原始组合我的看法是学习路径不同项目目标不同。先看一张选型对比表技术方案上手难度学习价值适合场景JSP Servlet JDBC低能看透 Web 底层原理课程设计、面试打底Spring Boot Thymeleaf中贴近企业主流后端开发找工作项目经验Spring Boot Vue 前后端分离较高业界主流前后端协作方式完整商业项目复刻这份源码之所以采用传统方式是因为它能让你看见一个请求从浏览器发出来之后发生了什么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 数据表结构与关系设计数据库设计是整个项目的地基。表结构没设计好后面写代码到处别扭表结构清爽了业务代码写起来会很顺。这份源码一共设计了六张表表名作用关键字段user用户表id、username、password、role、statuscategory商品分类表id、name、sortproduct商品表id、category_id、name、price、stock、image、description、statuscart购物车表id、user_id、product_id、quantityorders订单表id、order_no、user_id、total_price、status、create_timeorder_item订单明细表id、order_id、product_id、quantity、price这里有两个设计点值得说明。第一个是订单和订单明细为什么要拆成两张表因为一个订单包含多个商品如果不拆要么把多个商品拼在一个字段里字符串处理非常痛苦要么就没办法记录每个商品下单时的单价。拆成主表和明细表之后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 ListProduct findProductsByCategory(int categoryId) { ListProduct 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); }这段代码在单用户测试环境下没问题一旦两个用户同时下单购买同一件商品就可能出现超卖两个请求都读到 stock5都判断够扣先后执行更新库存实际变成 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 改成 letlet 是块级作用域每次循环迭代都会创建独立的绑定二是用 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;charsetUTF-8 }, body: formData.toString() }); let data await resp.json(); if (data.code 200) { refreshTotal(); } else { alert(data.msg); } }注意 Content-Type 的写法这里容易踩坑。用 URLSearchParams 拼 body 时后端如果没有配置编码过滤器中文参数会乱码配置了正确 charsetUTF-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.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/snack_shop?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse jdbc.usernameroot jdbc.password123456注意如果你的 MySQL 是 8.x驱动类名必须是 com.mysql.cj.jdbc.Driver并且 URL 里要带 serverTimezoneAsia/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 常见报错与解决办法速查表我在实际运行这个项目时以及平时帮别人排查时遇到的最多的就是下面这些报错。整理成表格方便你直接对照处理报错现象根本原因解决办法页面访问 404项目部署路径与访问路径不一致确认 webapps 下项目目录名或 IDEA 中 Application context 配置MySQL 连接拒绝账号密码错误、端口不对或服务没启动检查 jdbc.properties确认 MySQL 服务状态ClassNotFoundException: com.mysql.cj.jdbc.DriverMySQL 驱动 jar 没引入在 WEB-INF/lib 下放入 mysql-connector-java 对应版本的 jar插入数据库中文变问号数据库编码或连接 URL 未指定 UTF-8URL 加 characterEncodingutf8建库时指定 utf8mb4控制台 Tomcat 中文乱码控制台输出编码问题修改 Tomcat 的 conf/logging.properties 或 IDE 控制台编码为 UTF-8端口 8080 被占用其他程序占用了 Tomcat 端口找到占用进程结束或修改 Tomcat server.xml 端口请求参数中文乱码请求和响应编码未统一配置 CharacterEncodingFilter 过滤器强制 UTF-8java.lang.OutOfMemoryError: insufficient memoryJVM 堆内存不够调整 Tomcat 的启动内存参数catalina.sh 中设置 JAVA_OPTS这些报错里有几个是新手阶段必踩的。比如端口占用很多人第一次装完 MySQL 再装 Tomcat发现 8080 被别的程序占了直接一脸懵其实用 netstat -ano | findstr 8080 查出 PID进任务管理器结束进程就行或者更保险一点改 Tomcat 端口。4.3 我在跑这个项目时印象最深的三个坑分享几个我从这段源码里实际踩过的坑都不是文档里会写的那种。第一个坑是数据库连接没复用导致页面卡顿。早期版本直接每次 new Connection系统能跑但一旦有多个用户并发访问数据库连接反复创建和销毁响应时间明显变长。后来改成 Druid 连接池之后性能稳定了非常多。连接池的概念不难它就是一个连接复用池预先创建好一批连接谁要用谁取用完归还避免频繁建立 TCP 连接的开销。这个优化虽然代码改动不大但对系统的稳定性提升是本质性的。第二个坑是前端 JS 把价格计算寄托在浮点数比较上。有次测试结算时某件商品价格 0.1 元买三件总价显示本文还有配套的精品资源点击获取