企业官网建设流程全解析

简介：一份基于JavaWeb开发的山地车网上购物系统项目包，面向正在学习JavaWeb框架的学生、需要课程设计或快速搭建电商原型的开发者，项目已做好基本配置，导入IDE即可直接运行。系统实现了运营商、店铺、顾客、一般浏览者四类账户管理：运营商可管理店铺与顾客，店铺能维护商品、订单及店铺信息，顾客可查询商品、管理自身订单和个人资料，浏览者拥有商品浏览、搜索与排行统计权限。完整交易流程参考淘宝模式，覆盖登录注册、主页商品展示、搜索、购物车、下单支付、发货、收货、评价及商品添加等核心环节，从权限控制到交易闭环均有代码支撑。压缩包约22.27MB，内含可直接导入的Web工程文件，目前已有797人学习下载。通过研读该项目，可快速掌握JavaWeb的目录结构、框架整合方式以及购物车、订单、支付等模块的实现思路，对提升实战能力和准备毕业设计很有参考价值。

1. 这个山地车购物系统：拿 Javaweb 练手最完整的淘宝仿品

做 Javaweb 课程设计或者毕业设计的人，十有八九最后都绕不开购物系统。但网上能下到的项目，要么是只有增删改查的玩具，要么是代码乱到根本跑不起来。这个山地车网上购物系统（webbikeshop）是个例外——它把淘宝那套买卖流程完整搬了下来：多角色登录注册、店铺管理、商品搜索浏览、购物车、下单、支付、发货、收货、评论，甚至运营商管理店铺和顾客都齐了。换句话说，这不是一个只演示 CRUD 的教学片段，而是一个「直接导入 IDE 就能跑、能演示完整交易闭环」的 Javaweb 项目。

它用的是 JSP + Servlet + JavaBean 这套经典技术栈，配合分层思想，对还在校或者刚工作的 Javaweb 学习者非常友好。系统里分了运营商、店铺、顾客、普通浏览者四类角色，模拟的就是淘宝的运营模式。如果你正在找项目源码做课设、或者想搞清楚购物系统从用户点击到商家发货中间到底经过哪些环节，这个资源值得花一个晚上认真拆一遍。这篇文章我就带你把它从头到尾过一遍。

2. 拆项目结构：先分清四个角色和六张核心表

拿到压缩包直接扔进 IDEA 之前，我建议你先花十分钟把目录结构摸一遍。很多人在这一步偷懒，结果后面改需求时找不到文件在哪，血压直接拉满。这个项目虽然是教学向的，但包结构做得很规矩，基本上按照 MVC 思路在组织。

2.1 目录结构速览：从 web.xml 到 DAO 层

解压之后你会看到一个标准的 Javaweb 工程目录。src 下按 com.xxx 的包名分层，常见的做法是分为 entity（实体类）、dao（数据访问层）、service（业务逻辑层）、servlet（控制器）、filter（过滤器）这几个包。web 目录下是 JSP 页面和静态资源，css、js、images 各归各的。WEB-INF 里是 web.xml 和 lib 目录，lib 里应该有 MySQL 驱动、JSTL 标签库这类基础依赖。

webbikeshop/ ├── src/ │ ├── com/bikeshop/entity/ # 实体类：User, Shop, Product, Order, CartItem... │ ├── com/bikeshop/dao/ # DAO接口和实现：UserDao, ProductDao, OrderDao... │ ├── com/bikeshop/service/ # 业务逻辑：登录校验、下单事务... │ ├── com/bikeshop/servlet/ # Controller层：LoginServlet, RegisterServlet... │ └── com/bikeshop/filter/ # 编码过滤、登录状态过滤 ├── web/ │ ├── index.jsp # 主页，商品浏览入口 │ ├── login.jsp / register.jsp # 登录注册页 │ ├── shop/ # 店铺管理相关页面 │ ├── cart/ # 购物车页面 │ ├── order/ # 订单列表和详情页 │ └── WEB-INF/ │ ├── web.xml # 核心配置：Servlet映射、过滤器 │ └── lib/ # MySQL驱动、JSTL等依赖包 └── sql/ └── bikeshop.sql # 建库建表脚本（重点）

这里你要特别注意一个东西：web.xml。因为这是 Servlet 3.0 之前风格的写法，所有 Servlet 的 URL 映射、过滤器注册、欢迎页面都得靠它声明。你自己加新功能的时候，如果页面 404 或者请求打不到 Servlet，第一个要检查的就是 web.xml 里有没有配<servlet-mapping>。

2.2 四类角色到底能干什么：权限设计的参照系

这个项目的权限模型是按淘宝的逻辑设计的，四类角色各管一摊。我整理了一张表，你对照着看项目代码会非常清楚：

这四类身份在代码里通常用一个role字段区分，登录成功后写入 Session，后续请求靠 Filter 拦截判断。我一般会建议你在理解这个项目时，不要只盯着某一条业务链去看，而是先把「谁能访问哪个页面」对照着捋一遍——这是购物系统里最重要的骨架，比你纠结某个查询 SQL 怎么写要有价值得多。

2.3 数据库表结构：订单表和购物车表是核心

项目自带的 sql 脚本名字一般是bikeshop.sql，你在 MySQL 里执行完会自动建库建表。核心表建议重点关注这几张：

我见过很多人拿到项目第一步就去研究商品查询的 SQL，其实不对。这个项目最有学习价值的是order_item的设计——为什么订单详情里要单独存一份商品名称和价格快照？因为商品表里的价格是会变的，而订单必须保留下单那一刻的成交数据。这个思想在真实电商项目里叫「订单快照」，你现在在课程设计里养成这个习惯，以后做企业项目会省掉很多返工。

3. 登录注册与 Session 权限控制：四类身份如何隔离

购物系统的第一道门槛就是登录注册，它直接决定了后面的角色权限能不能撑住。这个项目的登录逻辑并不复杂，就是一个典型的「表单提交 → 查询数据库 → 写 Session → 跳转对应首页」流程，但它在角色分配上做的处理值得你细看。

3.1 注册流程：注册时如何决定账号类型

注册页面一般会带一个角色选择下拉框。顾客注册选「顾客」，想开店的人选「店铺」，注册后默认等待运营商审核。这个设计比较接近真实场景——你不可能让随便一个人注册个账号就成运营商，所以运营商账号要么在数据库里手动生成，要么是固定的初始化账号。

// register.jsp 里的角色选择部分 <select name="role"> <option value="customer">我要买东西</option> <option value="shop">我要开店</option> </select>

// RegisterServlet 的核心处理逻辑 String username = request.getParameter("username"); String password = request.getParameter("password"); String role = request.getParameter("role"); if (role.equals("shop")) { // 店铺账号默认状态为 0（待审核），运营商通过后才可登录 user.setStatus(0); } else { // 顾客和运营商直接激活 user.setStatus(1); } userDao.insert(user);

这段逻辑的要点是「店铺账号需要审核」这个状态设计。你在真实项目里做得更细致的话，还会加一个audit_time字段记录审核时间，加audit_note字段让运营商填驳回原因。这个项目的处理比较简单，但状态字段status已经为审核留了位置，这就是一个足够好的课程设计水准。

3.2 登录校验与 Session 角色区分

登录 Servlet 拿到表单提交的用户名密码后，调用 DAO 层查库比对。校验通过就把用户对象放进 Session，然后根据角色跳去不同首页。这里项目里常见的一个默认做法是：顾客跳 index.jsp，店铺跳店铺管理页，运营商跳运营商后台。

// LoginServlet 关键逻辑 User user = userDao.findByUsernameAndPassword(username, password); if (user == null) { response.sendRedirect("login.jsp?error=1"); // 用户名或密码错误 return; } if (user.getRole().equals("shop") && user.getStatus() == 0) { response.sendRedirect("login.jsp?error=2"); // 店铺未通过审核 return; } HttpSession session = request.getSession(); session.setAttribute("currentUser", user); // 按角色分发到不同首页，避免顾客看到店铺后台菜单 if ("customer".equals(user.getRole())) { response.sendRedirect("index.jsp"); } else if ("shop".equals(user.getRole())) { response.sendRedirect("shop/index.jsp"); } else if ("operator".equals(user.getRole())) { response.sendRedirect("admin/index.jsp"); }

参数层面你要注意几点：error=1和error=2是给 JSP 页面判断用的错误码，页面里通过${param.error}配合 EL 表达式显示不同的提示文案。Session 中存的currentUser就是后续所有权限判断的数据来源。很多人在做这类项目时会忽视「登录后跳转按角色分流」这个细节，直接统一跳到首页，结果店铺用户跑到顾客页面，还得手动点链接切后台——这在你答辩时都是可以被老师追问的点。

3.3 登录状态拦截：Filter 的使用位置

Session 里放了用户不等于万事大吉，你还需要一个 Filter 来拦截未登录用户的越权访问。这个项目一般在 web.xml 里注册了两个过滤器的位置：一个是编码过滤器（处理中文乱码），一个是登录状态校验过滤器。

<!-- web.xml 中的过滤器配置片段 --> <filter> <filter-name>CharacterFilter</filter-name> <filter-class>com.bikeshop.filter.CharacterFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>CharacterFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter> <filter-name>LoginFilter</filter-name> <filter-class>com.bikeshop.filter.LoginFilter</filter-class> </filter> <filter-mapping> <filter-name>LoginFilter</filter-name> <url-pattern>/shop/*</url-pattern> <url-pattern>/admin/*</url-pattern> </filter-mapping>

这个配置的意思是：所有 URL 先过编码过滤器保证中文不乱码；/shop/*和/admin/*前缀的请求额外过登录过滤器，Session 里没有currentUser就直接弹回登录页。

常见翻车点：很多人图省事把 LoginFilter 映射到/*，导致登录页本身也被拦截，形成死循环。正确做法是只拦截需要保护的目录。项目里把店铺后台放在/shop/前缀下就是为了方便做 URL 级别的权限控制，这个约定你一定要保留，别随便改路径。

4. 购物车到订单：交易主链路的状态机设计

购物车和订单是整个系统里最有含金量的部分，也是答辩时老师最喜欢深挖的地方。这个项目的交易链路覆盖得比较全：顾客加购物车 → 下订单 → 模拟支付 → 店铺发货 → 顾客收货 → 评论，每一步都有对应的数据库状态变化。把这条链路吃透，你才算真正看懂了这个项目。

4.1 添加购物车：库存与登录状态的双重校验

购物车的功能在页面端是「加入购物车」按钮，点击后提交商品 ID 和数量到 CartServlet。这个操作背后有两层校验：一是用户必须已登录，二是商品库存要够。

// AddCartServlet 核心逻辑 Product product = productDao.findById(Integer.parseInt(request.getParameter("productId"))); int quantity = Integer.parseInt(request.getParameter("quantity")); User user = (User) session.getAttribute("currentUser"); // 第一层：库存校验 if (product.getStock() < quantity) { response.sendRedirect("productDetail.jsp?id=" + product.getId() + "&error=stock"); return; } // 第二层：查询购物车是否已经存在该商品 CartItem cartItem = cartDao.findByUserIdAndProductId(user.getId(), product.getId()); if (cartItem == null) { cartItem = new CartItem(user.getId(), product.getId(), quantity); cartDao.insert(cartItem); } else { int newQuantity = cartItem.getQuantity() + quantity; if (newQuantity > product.getStock()) { response.sendRedirect("productDetail.jsp?id=" + product.getId() + "&error=stock"); return; } cartItem.setQuantity(newQuantity); cartDao.update(cartItem); } response.sendRedirect("cart.jsp");

这段代码里有两个细节值得做笔记。第一个是「购物车已有同款商品时做数量累加而不是新增条目」，这符合淘宝的行为——你把同一商品反复加购物车，它不会给你生成两条数据。第二个是「累加后依然要判断总数量是否超过库存」，这个边界条件是很多初学者容易漏的，漏了就会出现购物车里存了 10 件但库存只有 3 件的脏数据。

4.2 下单逻辑：事务和订单快照怎么配合

从购物车点击结算到订单生成，是这个项目里唯一涉及到事务的地方。因为这里同时要操作四张表：生成主订单、批量插入订单明细、扣减商品库存、清空用户购物车。任何一个环节失败，数据都会变成「订单生成了但库存没扣」或「钱付了但订单缺失」这种不一致状态。

// OrderServlet 下单核心逻辑（简化版） Connection conn = DBUtil.getConnection(); try { conn.setAutoCommit(false); // 开启事务 double totalPrice = 0; List<CartItem> items = cartDao.findByUserId(userId); // 计算总价 for (CartItem item : items) { Product p = productDao.findById(item.getProductId()); totalPrice += p.getPrice() * item.getQuantity(); } // 1. 生成主订单 Order order = new Order(); order.setOrderNo(generateOrderNo()); // 时间戳 + 随机数 order.setUserId(userId); order.setTotalPrice(totalPrice); order.setStatus("待支付"); int orderId = orderDao.insert(order); // 2. 批量写入订单明细（存商品快照） for (CartItem item : items) { Product p = productDao.findById(item.getProductId()); OrderItem oi = new OrderItem(); oi.setOrderId(orderId); oi.setProductId(p.getId()); // 关键：存快照，不存关联查询 oi.setProductName(p.getName()); oi.setPrice(p.getPrice()); oi.setQuantity(item.getQuantity()); orderItemDao.insert(oi); // 3. 扣减库存 p.setStock(p.getStock() - item.getQuantity()); productDao.update(p); } // 4. 清空购物车 cartDao.deleteByUserId(userId); conn.commit(); // 全部成功才提交 } catch (Exception e) { conn.rollback(); // 任何一步失败，全部回滚 throw e; } finally { conn.setAutoCommit(true); DBUtil.close(conn); }

你仔细看这段代码的顺序：先算总价，再生成主订单，再写明细，同时扣库存，最后清购物车。四步全部成功才算下单完成，任何一步抛异常都会滚回去。我见过太多课程设计把「下单」写成一个简单的 INSERT，库存不扣、快照不存，看起来能跑但漏洞百出。这个项目在这一块的取舍是很有参考价值的。

4.3 订单状态流转：从待支付到已完成的五态设计

订单状态是观察这个系统设计水平的一个窗口。严格按照淘宝流程，这个项目把订单生命周期拆成了几个状态节点：

// 支付状态的典型处理：模拟支付操作 String orderId = request.getParameter("orderId"); Order order = orderService.findById(Integer.parseInt(orderId)); // 校验当前状态必须是"待支付"才能支付 if (!"待支付".equals(order.getStatus())) { response.sendRedirect("orderDetail.jsp?orderId=" + orderId + "&error=status"); return; } order.setStatus("待发货"); order.setPayTime(new Timestamp(System.currentTimeMillis())); orderService.update(order);

这个「状态只能按顺序流转」的设计，用行话说就是状态机思维。下单只能从「待支付」开始，你不能把「已完成」的订单再改成「待发货」。这个项目在状态流转时的校验判断写得比较规矩，你在改造成真实项目时只需要把payTime换成调用支付接口的返回时间即可。

5. 店铺与商品管理：上架、库存、统计排行一起捋顺

店铺和商品是购物系统的供给侧，没有它们，用户端再流畅也是空壳。这个项目在店铺端做的事情包括开店审核、商品上下架、库存修改、订单处理。顺着运营视角看一遍代码，你就能明白一个完整的买卖闭环是怎么转起来的。

5.1 商品管理：图片上传与表单提交的常见姿势

店铺登录后台后，主要工作是添加商品、编辑商品、下架商品。添加商品的表单包含商品名称、价格、库存、分类和图片。图片上传这块用的是传统的Part接口（Servlet 3.0+ 支持），页面上用<input type="file" name="image">提交。

// 店铺后台上传商品图片的处理 Part part = request.getPart("image"); String fileName = extractFileName(part); // 从 header 中提取原始文件名 String savedDir = getServletContext().getRealPath("/uploads"); File dir = new File(savedDir); if (!dir.exists()) dir.mkdirs(); // 生成唯一文件名，避免中文文件名和重名问题 String savedName = System.currentTimeMillis() + "_" + fileName; part.write(savedDir + File.separator + savedName); // 保存到数据库时只存相对路径，页面用 <img src> 拼接访问 product.setImage("uploads/" + savedName); productDao.insert(product);

这里有几个关键实践点。一是「重命名文件」，直接用用户上传的原始文件名是危险的，中文名和特殊字符会导致访问出错，用时间戳加随机数重命名是工程里的标准做法。二是「数据库只存相对路径」，uploads/xxx.jpg这种写法在页面里直接拼到工程根路径后面就能访问到，如果存了全路径，以后换服务器或换部署位置就容易写死。三是注意web.xml里要让 Tomcat 能访问到 uploads 目录，IDE 里一般配一下部署目录就行。

5.2 店铺处理订单：发货动作的本质是改状态

店铺登录后台后能看到归属自己店铺的订单列表，订单里显示了顾客信息、购买的商品明细、收货地址。处理方式就是点一下「发货」，本质是把订单状态从「待发货」改成「待收货」，同时记录发货时间。

// 店铺发货逻辑 Order order = orderDao.findById(Integer.parseInt(request.getParameter("orderId"))); Shop shop = (Shop) session.getAttribute("currentShop"); // 校验订单归属：确保这个订单确实是这家店铺的 if (order.getShopId() != shop.getId()) { response.sendRedirect("shop/orderList.jsp?error=permission"); return; } if (!"待发货".equals(order.getStatus())) { response.sendRedirect("shop/orderList.jsp?error=status"); return; } order.setStatus("待收货"); order.setShipTime(new Timestamp(System.currentTimeMillis())); orderDao.update(order);

这段代码的亮点是「订单归属校验」——在改任何订单状态之前，先确认这个订单属于当前登录的店铺。很多课程设计里都忽略了这一层，导致店铺 A 可以改店铺 B 的订单。这在答辩时拿出来主动讲，是很加分的细节。

5.3 统计排行功能：商品热销榜和店铺榜组合查询

系统对一般浏览者提供了商品浏览、搜索、统计排行功能，后台的报告里也用到了这些统计。这个功能的实现通常是一段带 GROUP BY 和 ORDER BY 的聚合查询，把商品表的sales字段降序排列取前 N 名。有些版本会把已删除商品过滤掉，避免排行榜里出现下架商品。

-- 商品热销排行（按销售数量倒序，只取在售商品） SELECT p.id, p.name, p.price, p.image, p.sales, s.shop_name FROM product p JOIN shop s ON p.shop_id = s.id WHERE p.status = 1 ORDER BY p.sales DESC LIMIT 10;

你把它换成店铺维度，同样能写「店铺销量排行」。这类 SQL 在答辩演示时特别直观，跑出来就是一个真实的排行榜页面。把LIMIT的数字做成参数，前端就能做「查看完整排行」的分页。

6. 避坑手册：导入、部署、数据不一致的十个血泪经验

这个项目整体能跑通，但不代表你每一步都会顺利。我根据自己帮人调试这类 Javaweb 项目的经验，把最常见的问题整理出来。每一条都是真实的踩坑记录，按「现象 → 原因 → 解决」来写。

6.1 现象：导入 IDEA 后所有 JSP 页面找不到 JDBC 驱动

• 原因：WEB-INF/lib下的 jar 包没被正确识别。IDEA 有时不会自动把 lib 目录标记为依赖。
• 解决：右键WEB-INF/lib目录 → Add as Library → 选择 Module 级别。或者在 Project Structure → Libraries 里手动添加这个目录，别只在 Artifacts 里加。

6.2 现象：启动 Tomcat 后访问首页报 500，日志提示数据库不存在

• 原因：bikeshop.sql还没执行，或者 MySQL 端口/账号密码和项目里的DBUtil.java对不上。
• 解决：先用命令行或 Navicat 打开bikeshop.sql执行建库。然后打开DBUtil.java，改成你自己本地的数据库账号：

  private static final String URL = "jdbc:mysql://localhost:3306/bikeshop?useUnicode=true&characterEncoding=utf8&useSSL=false"; private static final String USER = "root"; private static final String PASSWORD = "你自己本地的密码";

6.3 现象：注册的店铺账号登录却提示「审核未通过」

• 原因：不是 Bug，是这个功能本身的设计。店铺注册后status默认是 0，需要运营商在后台审核通过后才能登录。
• 解决：去数据库执行UPDATE user SET status = 1 WHERE username = '你注册的店铺账号';，或者用运营商账号登录后台激活。这个机制是刻意做的，不是坏了。

6.4 现象：加购物车总是失败，提示库存不足

• 原因：商品表里的stock初始值可能是 0，或者你在测试时库存已经被上一个订单扣完了。
• 解决：在后台把商品库存改大，或者直接在数据库改：

  UPDATE product SET stock = 100;

  以后每次测试完别忘了改回来，不然越玩库存越少，最后所有商品都「库存不足」。

6.5 现象：页面中文全部变成问号

• 原因：Tomcat 默认编码不是 UTF-8，数据库连接串没带useUnicode=true&characterEncoding=utf8。
• 解决：项目里一般有 CharacterFilter，确认它在web.xml里映射了/*。另外确认 MySQL 连接串带了两个编码参数。实体包下如果用了 DBUtil，就统一检查一遍。

6.6 现象：商品图片上传后刷新页面看不到图

• 原因：文件存到了工程开发目录的 uploads 下，但 Tomcat 运行时的部署目录是另一个位置，两边不同步。
• 解决：IDEA 里检查 Artifacts 配置，把uploads目录加到部署描述里；或者直接把文件路径打印出来看一下存到了哪里，手工把 uploads 目录复制到 Tomcat 的 webapps 对应目录下。最好用 IDEA 的 exploded war 模式运行项目，文件改动直接生效。

6.7 现象：购物车结算时订单金额和商品总价对不上

• 原因：商品价格在下单过程中被修改了，比如后台编辑了价格。由于订单明细是在结算瞬间查的数据库，前端展示的总价是旧的。
• 解决：下单时在后端重新计算价格，不要信前端传过来的任何金额参数。这个项目如果出现对不上，优先检查OrderServlet里是否重新查库算价，前端 price 参数只做展示用。

6.8 现象：多角色登录后出现串号

• 原因：Filter 只校验 Session 是否为空，没校验 Session 里的角色和请求路径是否匹配。顾客登录后手动访问/shop/xxx，居然能进店铺后台。
• 解决：在 Filter 里加角色校验，例如/admin/*必须session.getAttribute("currentUser").getRole().equals("operator")，否则跳回登录页。

6.9 现象：商品删除后订单明细里空了

• 原因：order_item表外键关联了product.id，删了商品把订单记录也级联删掉了。
• 解决：如果建表脚本里外键带了ON DELETE CASCADE，说明设计有缺陷。正确做法是订单明细不建外键约束（或者只建索引不建外键），商品删除用逻辑删除（加status字段标记下架），而不是物理 DELETE。

6.10 现象：Tomcat 10 上跑起来直接报 ClassNotFound

• 原因：这个项目是 Servlet 3.x 时代的写法，Tomcat 10 换了 Jakarta EE 包名（javax.servlet变成jakarta.servlet），老代码编译不过。
• 解决：不用硬刚，直接用 Tomcat 8.5 或 9.0 跑。这个项目用的 JSP/Servlet 老写法就是为了适配传统 Tomcat，你没必要为了升级环境去改全套 import。

7. 扩展玩法：把课程设计升级成小型真实电商的细节打磨

跑通原版代码只是第一步。真正能让你在答辩时眼前一亮、或者写进简历加分的，是你在此基础上做了几个「工程化」改造。这里我给你三组具体操作，每一组工作量都不大，但价值立竿见影。

第一件事是给订单系统加一个「订单号生成器」。原版项目里订单号一般用时间戳或者简单的递增数字，你改成yyyyMMddHHmmss + 用户ID + 3位随机数这种格式，既保证了不可猜测性，也方便按订单号反查下单时间。第二件事是统一商品列表页的分页逻辑，把 Page 对象提取出来，做成 PageBean，前端用 JSP 标签渲染页码条，以后任何列表页都可以复用。第三件事是给支付加一个模拟回调接口，虽然项目里是点了「支付」按钮直接改状态，你还可以加一个 PaymentServlet 来模拟第三方支付通知——这样你在简历上写「接入支付流程」的时候就有真实代码支撑，而不是只说做了个按钮。

// 模拟支付回调接口的设计思路 public class MockPayCallbackServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String orderNo = request.getParameter("orderNo"); String amount = request.getParameter("amount"); String sign = request.getParameter("sign"); // 1. 验签（模拟，真实项目要和服务端约定加密算法） // 2. 查订单，确认金额一致 // 3. 把订单状态从"待支付"改成"待发货" // 4. 记录支付回调日志 Order order = orderService.findByOrderNo(orderNo); if (order != null && order.getTotalPrice() == Double.parseDouble(amount)) { orderService.updateStatus(order.getId(), "待发货"); response.getWriter().write("SUCCESS"); } else { response.getWriter().write("FAIL"); } } }

这个 Mock 接口的意义在于，它把你从「页面按钮直接改数据库」的玩具思路，拉到了「支付状态由回调触发」的真实业务思路上来。你只需要在页面上把这个 Servlet 的地址伪装成支付平台的异步通知地址，就能完整模拟出「用户跳转支付页面 → 模拟支付成功 → 平台回调 → 订单状态更新」的链路。

另外我再教你一个自查技巧：在自己电脑上部署好之后，用两个浏览器分别登录顾客账号和店铺账号，把交易链路从头到尾走一遍——顾客下单支付、店铺发货、顾客确认收货、顾客评论——看看每一步之后数据库的状态字段是否正确。这个操作你多走几遍，比你看十遍代码都管用。我当年做课设时因为偷懒跳过这个完整的互换测试，结果答辩现场当场翻车，从那以后我每次拿到新项目都强迫自己每晚睡前把交易闭环走一遍，连订单金额小数位都不放过。希望这个习惯也能帮到你。

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