企业官网建设流程全解析

简介：面向计算机专业毕业设计与Web开发入门者的网上购物系统完整项目包，围绕电商主流程提供可运行的源码与配套论文，帮助读者理解商品浏览、购物车、订单处理、用户中心及后台管理等模块的实现思路。压缩包共2000个文件、约200MB，其中693个JavaScript脚本、275个CSS样式与247个HTML页面承担前端交互和界面，75个aspx页面、137个C#源文件连同sln解决方案、csproj工程文件与dll程序集构成ASP.NET服务端实现，另有图片素材、配置与说明文档补充资源和部署信息。已有81人学习下载。读者可对照论文梳理需求分析、系统架构与数据库表结构，结合ashx一般处理程序与ajax脚本理解前后端数据交互方式，并借助现成页面模板、样式表和解决方案文件快速搭建调试环境，适合作为课程设计、毕设参考与二次开发的基础骨架。

1. 用户点完"提交订单"后卡住的那三秒，系统到底在做什么

用户点下结算，页面转圈三秒，弹回一句"库存不足"。他退回商品页刷新，明明还挂着 3 件。这类问题几乎出现在每一个基于 Web 的网上购物系统的设计与实现过程里：加购物车时查了一次库存，下单时又查了一次，两次读到的不是同一份数据，中间也没有任何约束兜底。这套方案要解决的就是这件事——把一次交易从浏览、加购、下单、扣库存到支付回调的完整链路讲清楚，给出可落地的表结构、接口约定和关键代码，再配一份能照着走的验收清单。它适合正在做电商类毕设或课程设计的人，也适合需要交付一套可运行购物系统原型的开发者，尤其是那种"功能都能点，但一被追问就说不清"的处境。

2. 需求拆解与技术选型：把"能演示"和"能扛住"分成两条线

2.1 三类角色与功能清单的收敛方式

购物系统的功能清单很容易失控。打开任何一个电商网站，能数出上百个入口，全抄一遍既做不完也讲不清。我一般的做法是先按角色切三端，每端只保留"少了它这笔交易就跑不通"的功能，剩下的全部归入扩展区，答辩时明确说"这是二期"。这样功能边界清晰，工作量可控，评审时也不会被抓着问"为什么这个没做"。

这张表的作用不是限制你，而是让你在写文档时有个"功能—角色—优先级"的三维坐标。毕设常见的扣分点是功能列表写了一大页，实际能演示的只有三个，反过来把这张表贴进设计文档，评委会直接看到你的取舍逻辑。买家端的六个功能是主干，必须全部闭环；商家端只要做到"改库存"和"发货"两条，订单状态机就能跑通；平台后台做用户封禁和分类维护即可，别在权限矩阵上花两周。

功能收敛完之后再定非功能指标，这部分很多人直接跳过，但它恰恰是答辩时拉开差距的地方。对这套体量，我一般给三条：单次列表查询响应控制在 300 毫秒以内、下单接口在 50 并发下不出现超卖、所有涉及金额的字段小数点后两位不丢精度。三条指标都可测，也都能对应到具体设计决策上，后面讲表结构和事务时你会看到它们是怎么被兑现的。

2.2 技术选型：这个体量为什么不该上微服务

每年都能看到把购物系统拆成六个微服务的毕设，注册中心、网关、配置中心全上，最后连"启动项目"这一步都要写三页说明。问题不在于微服务不好，而在于这套方案的交易链路只有一条，拆开之后分布式事务、跨服务鉴权、链路追踪全成了额外负担，而这些恰恰是最难讲清楚的部分。单体分层 + 一个数据库，能覆盖全部必做功能，部署只需要一条命令，答辩现场也不会因为中间件没起来而演示失败。

如果是课程设计、时间只有两三周，前端可以退一步用 Thymeleaf 服务端渲染，省掉跨域、打包、接口联调三件事，把精力全放在后端链路上。这不是偷懒，是资源分配——购物系统的评分重点在交易逻辑，不在页面动效。

提示：技术栈一旦写进开题报告就不要中途换。换框架带来的返工量，通常比"选了一个不够时髦的框架"带来的扣分大得多。

2.3 接口约定：先定返回结构，再写第一个 Controller

后端最容易返工的地方不是业务逻辑，是接口格式。今天返回{code, msg, data}，明天某个接口直接返回数组，前端就得写两套解析。所以第一个 Controller 之前，先把统一返回体和分页参数定死，后面所有接口照抄。

// 统一返回体：所有接口的出口都是它，前端只需写一套解析 public class Result<T> { private Integer code; // 200 成功，401 未登录，403 无权限，500 业务异常 private String msg; // 面向用户的提示语，前端可直接弹 toast private T data; // 业务数据，失败时为 null public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> fail(Integer code, String msg) { Result<T> r = new Result<>(); r.code = code; r.msg = msg; return r; } }

code分四档是有讲究的：200 走正常分支，401 让前端跳登录页，403 弹"无权操作"，500 只用来承载可预期的业务失败（库存不足、订单状态不允许）。真正的系统异常交给全局异常处理器兜底，返回 500 但不暴露堆栈。分页参数统一成pageNum、pageSize，默认 1 和 10，上限卡在 100，防止有人传pageSize=99999把数据库拖垮。

前端拿到code之后的处理也要提前约定：401 清 token 跳登录、500 直接弹msg、200 之外的其他码统一提示"操作失败"。这套约定写进文档只有半页，但能省掉后期大量的对接口时间。

3. 架构与数据模型：六张核心表撑起整条交易链路

3.1 分层结构与各层职责边界

单体不等于一锅乱炖。分层的目的很实际：出问题时你能在三秒内判断该看哪个包。Controller 只做参数接收和结果包装，Service 承载业务规则和事务边界，Mapper 只管 SQL，实体和 VO 分开是为了避免"数据库字段直接吐给前端"这种把内部结构暴露出去的做法。

com.shop ├── common 统一返回体、异常定义、常量、工具类 ├── config MyBatis-Plus 配置、跨域、拦截器注册 ├── controller 参数校验 + 调用 Service + 包装 Result ├── service 业务规则、事务注解、跨表编排 │ └── impl ├── mapper 继承 BaseMapper，复杂查询写 XML ├── entity 与表一一对应的持久化对象 ├── dto 接收前端入参（下单请求、登录请求） └── vo 返回前端的视图对象（商品卡片、订单详情）

一个具体的边界判断：商品列表页需要"商品 + 库存 + 分类名"三份数据，有人会在 Controller 里查三次再拼装，结果一个接口里出现了三个 Mapper 调用。正确做法是 Service 组装 VO，Controller 只负责return Result.ok(list)。这条边界守住了，后面加缓存、加权限都只需要改 Service 一层。

DTO 和 VO 分开还有一层安全意义。用户实体里有密码字段，如果直接返回实体，前端 F12 就能看到密码哈希；用 VO 只挑 id、昵称、头像三个字段，泄露面直接归零。这类问题在答辩时被问到的概率不低，提前分开就是最好的回答。

3.2 核心表设计：从用户到订单明细

六张表是这套系统的最小闭环：用户、商品、库存、购物车、订单、订单明细。分类表可以并进商品表的一个字段，收货地址可以先挂在用户表上，把表数量压到六张，画 ER 图时一页放得下，讲起来也清爽。

-- 用户表：密码存 BCrypt 哈希，不存明文 CREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL, password VARCHAR(100) NOT NULL COMMENT 'BCrypt 哈希值', nickname VARCHAR(32), role TINYINT NOT NULL DEFAULT 0 COMMENT '0买家 1商家 2管理员', status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0封禁', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_username (username) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 商品表：价格用 DECIMAL，绝不用 FLOAT CREATE TABLE t_product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, category VARCHAR(32) NOT NULL, price DECIMAL(10,2) NOT NULL, cover VARCHAR(255) COMMENT '封面图相对路径', stock INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_category_status (category, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 订单表：金额快照 + 状态机 + 幂等键 CREATE TABLE t_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '对外单号，防遍历', user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT '下单时快照，不随后续改价变动', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待支付 1已支付 2已发货 3已完成 4已取消', pay_time DATETIME, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_user_status (user_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

库存直接放在商品表里，对这套体量足够，省掉一次关联查询；如果后面要做多规格（颜色、尺码），再拆 SKU 表，那时库存字段跟着迁过去。t_order_item存的是下单那一刻的商品名、单价、数量快照——这是最容易被忽略的一点。商品改价之后，历史订单必须还是原价，靠关联商品表实时查价格的做法，会让三个月后的订单详情页显示错误金额。

order_no用独立字段而不是直接暴露自增 id，是为了防止用户改 URL 里的数字就能翻别人的订单。生成规则一般是"年月日时分秒 + 用户 id 后四位 + 随机两位"，长度固定 20 位左右，索引效率也好。

3.3 字段取舍：金额、状态、软删除这三个决定

金额字段选DECIMAL(10,2)而不是FLOAT，这不是洁癖。浮点数存 0.1 会变成 0.100000001490116，累加十次之后对不上账。Java 侧对应BigDecimal，比较大小用compareTo而不是equals，因为equals会比较 scale——1.0和1.00在equals下是不相等的，这个坑我在对账逻辑里踩过一次。另一种做法是把金额换算成"分"存 BIGINT，全程整数运算，展示时再除 100，适合对精度要求更严的场景，代价是所有输入输出都要记得换算。

状态字段统一用TINYINT加注释，不用字符串。"已支付"三个字看着直观，但一旦要加状态、要按状态排序、要建索引，字符串的维护成本立刻上来。状态值一旦定下来就写进常量类，不允许在代码里散落魔法数字。

软删除要看场景。用户、商品适合软删（历史订单还要引用），订单明细绝对不删。但软删字段一旦加上，每条查询都得带deleted = 0，漏一处就出脏数据。我的做法是只在确实需要保留历史的表上加，配合 MyBatis-Plus 的逻辑删除注解，其余表物理删除，减少心智负担。

3.4 一张订单的完整状态流转

状态机是订单模块的骨架，画不清楚就会出现"已取消的订单还能发货"这种逻辑漏洞。定状态机的关键是：每个状态只能由特定动作触发，且只能流向固定的下一状态。

所有状态变更走同一个方法changeStatus(orderId, from, to)，SQL 写成UPDATE t_order SET status = ? WHERE id = ? AND status = ?，靠影响行数判断是否成功。这样即使两个请求同时到达，也只有一个能改成功，第二个影响 0 行直接返回"订单状态已变更"。这个写法比先查再改可靠得多，后面避坑章节会再提到。

4. 核心链路实现：登录态、商品检索与下单事务的落地代码

4.1 登录与会话：JWT 存客户端，Redis 存一份

登录这块最常见的两种极端：一是纯 Session，服务重启或者多实例就掉线；二是纯 JWT，签发之后无法主动失效，用户被封禁了还能拿旧 token 逛。折中做法是 JWT 里只放 userId 和过期时间，Redis 存一份login:token:{userId}作为白名单，拦截器两道都校验。

// 登录：校验密码后签发 token，并写入 Redis 白名单 public String login(String username, String rawPassword) { User user = userMapper.selectByUsername(username); if (user == null || !encoder.matches(rawPassword, user.getPassword())) { throw new BizException("用户名或密码错误"); } if (user.getStatus() == 0) { throw new BizException("账号已被封禁"); } String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .setExpiration(new Date(System.currentTimeMillis() + 2 * 60 * 60 * 1000L)) .signWith(SIGN_KEY) .compact(); // 白名单 2 小时，与 token 有效期对齐；封禁时直接删这个 key 即可强制下线 redisTemplate.opsForValue().set("login:token:" + user.getId(), token, 2, TimeUnit.HOURS); return token; }

encoder.matches对应注册时的 BCrypt 加密，数据库里存的是哈希，任何人拿到表也还原不出明文。Redis 的 key 用login:token:{userId}而不是{token}，好处是封禁用户时按 id 就能删，不需要遍历。过期时间设 2 小时是个折中值，太长不安全，太短演示时反复登录很烦，答辩前可以临时调到 8 小时。

拦截器这边只做三件事：取 header 里的 token、验签、比对 Redis 里的值。三者任一失败就返回 401，前端统一跳登录。放行路径要显式列出——商品列表、商品详情、登录注册这三个必须匿名可访问，其余全部拦截。这里千万别图省事写"除登录外全部拦截"，否则游客连首页都打不开。

4.2 商品列表与分页检索

商品列表是访问量最大的接口，也是最能体现"有没有做过优化"的地方。基础版用 MyBatis-Plus 的分页插件，两行代码搞定；进阶版加分类筛选和关键词模糊查询，注意like的写法要让索引还能用上。

// 分页查询：pageNum 从 1 开始，pageSize 上限 100 在 Controller 层做钳制 public PageVO<ProductVO> page(int pageNum, int pageSize, String category, String keyword) { LambdaQueryWrapper<Product> qw = new LambdaQueryWrapper<>(); qw.eq(Product::getStatus, 1); if (StringUtils.hasText(category)) { qw.eq(Product::getCategory, category); } if (StringUtils.hasText(keyword)) { // 只做右模糊，左模糊会让索引失效 qw.likeRight(Product::getName, keyword); } qw.orderByDesc(Product::getCreateTime); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), qw); // 转 VO，把价格格式化成两位小数字符串，前端不用再处理 List<ProductVO> list = page.getRecords().stream().map(this::toVO).toList(); return new PageVO<>(page.getTotal(), list); }

likeRight生成的是name LIKE '关键词%'，能走索引；如果写成like，生成%关键词%，数据量上千之后明显变慢。分类和状态组成的联合索引idx_category_status正好覆盖最常见的"某分类下的在售商品"这个查询。分页参数在 Controller 层用Math.min(pageSize, 100)钳一下，防止有人手动改 URL 把数据库打满——这个细节在答辩时提一句，评委会觉得你考虑过边界。

商品详情页可以加一层缓存，key 用product:detail:{id}，过期 10 分钟，更新商品时主动删 key。缓存这块不用做太复杂，讲清楚"为什么缓存详情页而不是列表页"就够了：详情页读多写少、单条数据小、失效逻辑简单，是缓存的最佳切入点。

4.3 下单事务：库存、订单、明细一次写进去

下单是整个系统里唯一必须用事务的地方，也是面试和答辩最爱追问的地方。顺序是：校验商品状态 → 扣库存 → 建订单 → 写明细，四步在同一个事务里，任何一步失败全部回滚。

@Transactional(rollbackFor = Exception.class) public String createOrder(Long userId, List<OrderItemDTO> items) { BigDecimal total = BigDecimal.ZERO; List<OrderItem> details = new ArrayList<>(); for (OrderItemDTO item : items) { Product p = productMapper.selectById(item.getProductId()); if (p == null || p.getStatus() == 0) { throw new BizException("商品已下架"); } // 关键：带条件更新，库存不足时影响行数为 0，直接抛异常回滚 int rows = productMapper.deductStock(item.getProductId(), item.getQuantity()); if (rows == 0) { throw new BizException("库存不足：" + p.getName()); } total = total.add(p.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); details.add(buildItem(p, item.getQuantity())); } Order order = new Order(); order.setOrderNo(generateOrderNo(userId)); order.setUserId(userId); order.setTotalAmount(total); // 金额快照，商品改价不影响历史订单 order.setStatus(0); orderMapper.insert(order); details.forEach(d -> d.setOrderId(order.getId())); orderItemMapper.insertBatch(details); return order.getOrderNo(); }

扣库存对应的 SQL 只有一句，但它是防超卖的全部：

-- 条件更新：库存够才扣，不够影响 0 行，由 Java 侧判断并回滚 UPDATE t_product SET stock = stock - #{qty} WHERE id = #{productId} AND stock >= #{qty};

stock >= #{qty}这个条件放在 WHERE 里，利用的是 InnoDB 的行锁。两个请求同时扣同一件商品，数据库会排队执行，第二个拿到的是扣减后的值，条件不满足就影响 0 行。相比之下，"先 select 查库存，判断够了再 update"的写法在并发下必然超卖，因为查和改之间有空隙。@Transactional的rollbackFor必须显式写Exception.class，否则抛出受检异常时事务不会回滚，这个默认行为坑过不少人。

订单号生成也要注意别用时间戳加自增，高并发下会撞。用"yyyyMMddHHmmss + userId 后四位 + 两位随机"的组合，长度固定，冲突概率极低，真撞了还有唯一索引兜底。

4.4 支付回调：幂等是必须补的一课

真实支付要接第三方，毕设阶段一般用模拟回调。但不管真假，回调接口都面临同一个问题：同一个通知可能重复到达。第一次把订单改成已支付，第二次就必须直接返回成功，不能再改一次状态，更不能重复加库存或者重复记账。

public void handlePayCallback(String orderNo, BigDecimal payAmount) { Order order = orderMapper.selectByOrderNo(orderNo); if (order == null) { throw new BizException("订单不存在"); } // 金额校验：防止伪造回调少付钱 if (order.getTotalAmount().compareTo(payAmount) != 0) { throw new BizException("金额不一致"); } // 状态机兜底：只有待支付才能改成已支付，重复回调影响 0 行 int rows = orderMapper.updateStatus(orderNo, 0, 1); if (rows == 0) { log.info("订单 {} 已处理过，忽略重复回调", orderNo); return; } // 支付成功后的后续动作：发通知、记流水，全部幂等 notifyService.pushPaid(order.getId()); }

updateStatus的 SQL 是UPDATE t_order SET status = 1, pay_time = NOW() WHERE order_no = ? AND status = 0，status = 0这个条件就是幂等的核心。重复回调时影响行数为 0，直接返回，后续动作一个都不执行。这套写法不需要分布式锁，也不需要额外的幂等表，成本最低。

金额校验别省。哪怕回调是模拟的，也要养成"回调金额必须与订单金额严格一致"的习惯，比较用compareTo而不是equals。做这一行久了会发现，很多所谓的玄学问题，追到底都是某个地方少了一次校验。

5. 避坑与排查：五处最容易在答辩现场翻车的地方

5.1 数据一致性上的三个坑

现象一：压测时出现负库存。加购接口正常，下单接口偶发把库存扣成 -1。原因基本可以锁定在扣库存的写法上——要么是先查再改，要么是 update 语句没带stock >= qty条件。解决就是把条件塞进 WHERE，用影响行数判断结果，同时给stock字段加UNSIGNED约束，让数据库在最外层再拦一次。改完之后用 JMeter 或者一个简单的多线程脚本跑 50 并发，验证库存总数等于初始值，这个验证过程本身就是答辩时很好的素材。

现象二：订单金额和商品总价对不上，差几分钱。原因通常是金额字段用了 float/double，或者中途做过除法。解决是把所有金额字段换成DECIMAL(10,2)/BigDecimal，加减乘一律用BigDecimal的方法，除法必须指定精度和舍入模式（RoundingMode.HALF_UP）。历史脏数据要一次性修，写个脚本把旧订单按明细重算一遍，别指望在展示层四舍五入糊过去。

现象三：事务加了但没生效，库存扣了订单没建。最常见的原因是同类内部方法调用——A 方法调本类的 B 方法，B 上的@Transactional完全不生效，因为绕过了 Spring 代理。排查方法很直接：在 B 方法里打个断点看事务是否开启，或者看日志里有没有Creating new transaction。解决是把 B 方法抽到另一个 Service，或者注入自身代理调用。第二个原因是异常被 catch 之后没重新抛出，事务管理器认为一切正常，自然不会回滚。

5.2 权限与交互上的两个坑

现象四：改一下 URL 里的订单 id，就能看到别人的订单。这是水平越权，属于安全类问题里最容易被问到的一类。原因是查询只用了where id = ?，没有带user_id。解决办法是订单、购物车、地址这类私人数据，查询条件必须同时包含id和当前登录用户 id，写成where id = ? and user_id = ?；后台管理接口则要在拦截器里校验角色。校验逻辑统一放在 Service 层，别指望前端藏入口——前端能藏的东西，改个请求就绕过去了。

现象五：token 过期后购物车清空，演示现场很尴尬。原因是购物车存在服务端 Session 里，Session 一失效数据就没了。换成 Redis 存购物车，key 用cart:{userId}，跟登录态分开管理，token 过期重新登录后购物车还在。同时在前端加一个响应拦截器，收到 401 先尝试静默续期（如果刷新 token 机制有做），失败再跳登录页，别让用户正在填地址时被踢出去。

注意：这五个坑有个共同点——都不是功能没做，而是边界没考虑。答辩前把这几条对应的代码各看一遍，比多写三个页面有用。

5.3 排查顺序：从日志到数据库的四步定位

真出问题时，别急着改代码，按固定顺序走一遍能省很多时间。第一步看接口返回的code和msg，业务异常和系统异常先分清；第二步看后端日志里有没有堆栈，有堆栈直接定位到行；第三步看 SQL 执行情况，把 MyBatis 的 SQL 日志打开，确认参数和执行行数；第四步直接连数据库查一遍实际数据，别相信"应该写进去了"这种判断。

这四步里第三步最容易被跳过。很多人看到"操作失败"就去翻 Java 代码，结果查了半天发现 SQL 里少了个条件或者参数传了 null。把mybatis-plus.configuration.log-impl设成StdOutImpl，所有 SQL 和参数直接打屏，调试效率能翻一倍。

6. 验收与答辩：用一份可复现的验收清单替代口头演示

演示翻车是答辩现场最可惜的事。功能明明都做了，一紧张点错顺序，或者数据被之前的操作改乱了，讲什么都救不回来。我的建议是把演示变成验收：提前准备一份清单，每一条都有明确的动作和判定标准，照着走一遍，走完就等于讲完了。

准备这份清单还有一个隐藏收益：它逼你在写代码阶段就把每条判定标准设计出来。比如"次单提示库存不足"这条，没有条件更新就做不到；"已取消订单不能发货"这条，没有状态机就做不到。验收标准反过来约束了实现质量，这比写完再想怎么证明要有效得多。

答辩陈述的节奏我一般这么安排：先用三十秒讲清楚系统解决了什么问题、有哪三端，接着画一张订单状态流转图（手画在白板上比 PPT 更自然），然后现场跑清单里的"下单扣库存"和"越权校验"这两条——一条展示业务，一条展示思考。剩下的功能不用逐个点，一句"其余功能都有对应验收项，清单在这里"就够。评委真正想看的不是你能点多少页面，而是你知不知道哪里容易出问题。

被问到不会的地方，直接说"这块我考虑过，当时的取舍是……，如果继续做会……"。装懂反而露怯，说清楚边界和取舍，比硬答加分。至于我踩过最疼的一次，是演示前十分钟手动清了测试库里的订单数据，忘了库存已经扣过，结果现场第一单就提示库存不足。从那以后我每次演示前都强制走一遍"重置数据脚本 + 完整跑一遍验收清单"，脚本里带库存回填，跑通才上台。希望这套结构和清单能帮到你，照着改一改，就是一份能交付的方案。

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