企业官网建设流程全解析

1. 项目概述与整体设计思路

1.1 核心需求解析：网购平台管理系统到底在管什么

很多人一听到“网购平台管理系统”这个名字，第一反应就是“又一个电商CRUD”。确实，市面上基于Spring Boot的电商管理系统不在少数，但真正把“管理系统”和“网购平台”这两件事都讲清楚的并不多。这个项目要解决的，其实是两类角色、五条核心链路的完整闭环。

先拆角色。网购平台一定有前台用户和后台管理员，二者是天然割裂的。前台用户关心的是注册登录、浏览商品、加购物车、下单支付、查看订单状态；后台管理员关心的是商品上下架、库存管理、订单审核与发货、用户管理、销售数据统计。一个合格的毕设级项目，至少要覆盖这两个端口的核心操作，否则就只是“商品展示页”而不是“管理系统”。

再拆链路。我把整个系统的核心流程归纳为五条：用户认证链路、商品流转链路、购物车到订单的转化链路、支付与订单状态机链路、后台数据统计链路。这五条链路不是各自孤立的，它们在订单主表上汇聚——订单既是用户行为的终点，也是管理员操作的起点。项目设计的第一原则，就是把订单这条主线理清楚，其他所有模块都围绕它展开。

商品的流转链路则是整个系统最普遍也最容易被忽略的一部分。从后台录入商品、设置库存和价格，到前台展示、加入购物车、扣减库存，再到订单完成后的库存恢复，这里面的状态一致性处理得好不好，直接影响系统在演示时的专业度。比如下单失败要不要回滚库存、超卖怎么防、取消订单要不要恢复库存，这些细节不是靠CRUD能糊弄过去的，而是需要事务和状态机配合。

1.2 为什么是Spring Boot而不是SSH或SSM

技术选型这件事，很多人觉得无所谓，能跑就行。但我个人的建议是：哪怕不用来做毕设，而是为了真正理解一个企业级Web项目的全貌，Spring Boot依然是目前性价比最高的选择，没有之一。

SSH（Struts+Spring+Hibernate）和SSM（Spring+SpringMVC+MyBatis）是老一辈项目的主流，问题在于配置繁琐。一个SSM项目从零搭起来，光XML配置文件就要写几百行，而且不同版本之间兼容性问题非常折磨人。Spring Boot的核心理念是“约定优于配置”，它把Web容器（默认Tomcat）、自动装配、依赖管理全部处理好，你只需要关注业务代码，而不是在配置文件里跟ClassNotFound异常搏斗。

我实测过同一套网购平台业务逻辑，用SSM搭骨架大概需要大半天，而Spring Boot从创建项目到能跑通“Hello World”只需五分钟。这不是某个框架的优劣问题，而是开发模式在本质上的不同：Spring Boot把“搭建”变成了“组装”，把重点还给业务本身。

另外，Spring Boot的生态整合能力也值得一提。这个网购项目里要用的MyBatis-Plus、JWT鉴权、Knife4j接口文档、Redis缓存、Spring Security，全都有对应的Spring Boot Starter，一行依赖就可以引入，不用再手动配置一堆Bean。对于时间有限、又想快速把系统跑起来的人来说，这个优势是决定性的。

选型定型后，版本问题也必须提前锁定。我不止一次看到有人用Spring Boot 3.x的教程去做毕设，结果遇到javax到jakarta的迁移问题，折腾几天才能跑通。这个项目的技术栈建议锁定在Spring Boot 2.7.18，这是2.x系列的最后一个稳定版本，兼容性最稳妥，网上的教程资料也最丰富。如果你要用3.x，那就得接受JDK 17+和一系列API变更，代价并不值得。

2. 核心技术拆解与关键模块设计

2.1 系统功能模块全景图

一个完整的网购平台管理系统，功能结构上可以划分为六个模块。

用户模块负责前台用户的注册、登录、个人信息维护和收货地址管理。注册环节需要校验用户名唯一性、密码强度，密码不能明文存储，要使用BCrypt加密。登录环节我采用的是JWT（JSON Web Token）方案，服务端生成Token返回给前端，前端每次请求在Header里带上Token，后端通过拦截器校验身份。相比Session方案，JWT天然适合前后端分离，也不需要担心集群环境下的Session共享问题。

商品模块包含商品分类、商品信息、商品图片和库存管理。商品分类使用自关联表结构，可以支持无限层级的分级，但考虑到实际演示效果，两级分类就够了。商品信息表要设计好状态字段：草稿、上架、下架、售罄，后台管理员可随时切换状态。库存字段要单独放在商品主表中，因为它是高频更新字段，且与订单事务强相关，拆出去反而增加复杂度。

购物车模块的设计有一个特别容易踩坑的点：购物车数据到底是放Redis还是放数据库。如果只是存在Redis，用户换台设备购物车就消失，体验很差；如果只存数据库，每次加减商品都要更新数据库，性能负担大。我采用的是双写策略——数据库做持久化，Redis做读取缓存，用户在浏览商品时将购物车写入Redis，结算时一次性同步到数据库。这个折中方案既保证了数据不丢，又保证了交互流畅度。

订单模块是整个系统的核心，我单独在后面用一节来讲。支付模块我选择了模拟支付的方式——在系统内创建一个虚拟支付页面，用户点击“确认支付”后直接跳转到支付成功页，同时在后台生成一条支付流水记录。这样既避开了真实支付接口的繁琐申请流程，又能把支付从下单到支付成功、订单状态流转的完整链路跑通。

后台管理模块则覆盖用户管理、商品管理、订单管理、数据统计四大块。数据统计我采用了ECharts展示近七天的订单量和销售额趋势图，后台管理页面用Vue+Element UI来搭建，两个端口都通过同一套RESTful API与后端交互。

2.2 订单状态机设计：如何避免逻辑混乱

订单模块为什么难做？因为订单不只是“创建订单”这一个动作，而是一个有多个状态节点、且每个节点都有前置条件的状态机。

我把订单状态分为六种：待付款、待发货、待收货、已完成、已取消、售后中。每个状态之间允许哪些转换，必须在代码里明确写死，不能让开发人员自由发挥。比如待收货状态就只能往两个方向走：用户确认收货变成已完成，用户申请售后变成售后中；待付款只能往两个方向走：用户付款变成待发货，用户超时或主动取消变成已取消。

状态转换的具体实现，我用了一个OrderStatus枚举类来管理：

public enum OrderStatusEnum { WAIT_PAY(0, "待付款"), WAIT_SEND(1, "待发货"), WAIT_RECEIVE(2, "待收货"), FINISHED(3, "已完成"), CANCELLED(4, "已取消"), AFTER_SALES(5, "售后中"); private final int code; private final String description; // 构造方法、getter省略 public static boolean canTransition(int current, int target) { switch (current) { case 0: return target == 1 || target == 4; case 1: return target == 2 || target == 4; case 2: return target == 3 || target == 5; case 3: return target == 5; default: return false; } } }

这个枚举类的canTransition方法就是状态机规则的具体落地。所有涉及订单状态变更的Service方法，都必须先调用这个判断，不满足转换条件的直接抛出业务异常。这样做的好处有两个：一是在业务层面避免了非法状态跳转，比如从待付款直接跳到已完成；二是在代码评审时，逻辑一目了然，不会出现“这个状态为什么能到那个状态”的争论。

配合状态机的，还有一张独立的订单操作日志表。每次状态变更，系统都会自动记录“什么时间、哪个用户、把订单从什么状态改为什么状态”的日志。这张表在调试和演示时价值极大——当你的订单状态出现“灵异事件”时，翻日志就能定位到是哪段代码干的。

2.3 库存并发扣减方案：经典“超卖”问题的应对

网购平台在并发场景下最容易暴露的一个问题就是超卖——库存只剩10件，但订单下出了12件。这里面最难的地方在于：下单时用户可能同时发起请求，程序先查询库存、判断是否足够、再扣减库存，这三个动作如果不加控制，就会出现多个线程同时读到“库存充足”的假象。

我在这个项目中采用的是“乐观锁+条件更新”的方案。具体来说，不先查库存再扣减，而是直接在更新语句中加库存判断条件：

@Update("UPDATE product SET stock = stock - #{num}, version = version + 1 " + "WHERE id = #{productId} AND stock >= #{num} AND version = #{version}") int deductStock(Long productId, Integer num, Integer version);

这条SQL的精髓在于WHERE stock >= #{num}，它把库存判断和库存扣减合并成了一个原子操作。如果库存不足，这条UPDATE语句会返回受影响行数为0，程序据此判断扣减失败并抛出库存不足异常。用数据库层面的行锁机制来保证并发安全，比在Java代码里加Synchronized之类的分布式锁要简单得多，也靠谱得多——因为你没法保证所有服务实例都用同一个锁。

有了扣减方案，还得防另一个坑：订单超时未支付，库存却一直被占用。我的处理方式是给待付款状态加了“超时自动取消+释放库存”。实现有两个选择：一是定时任务扫描超过30分钟未付款的订单并取消；二是引入消息队列做延迟消息。考虑到毕设项目的复杂度，我选择的是Spring自带的定时任务，每两分钟扫描一次待付款超过30分钟的订单，将其置为已取消状态，并调用库存回补方法。

这套方案最简单直接，不必引入额外的中间件，就能应对低并发的演示场景。如果将来要扩展到真实业务，再把定时扫描替换成RabbitMQ延迟队列即可。

2.4 数据库核心表结构设计

数据库是网购平台的基座，表结构设计得好不好，直接决定了业务逻辑写的痛不痛苦。我设计了十张核心业务表，这里重点说六张：

一个关键设计决策必须说明：订单明细表为什么要冗余商品名称和商品价格，而不是下单时去关联商品表？因为商品的价格和名称是会变的——后台管理员改个价，之前下单的订单如果直接查商品表，价格就全乱了。正确的做法是在生成订单明细的那一刻，把当时商品的核心信息“拍照存根”，之后就与商品表不再有依赖关系。这是电商系统的必备经验，也是很多新手容易忽略的细节。

另外需要注意的是金额字段一律用decimal(10,2)，不能用double或float，否则会出现0.1+0.2不等于0.3的经典浮点精度问题。Java实体类中对应的字段类型用BigDecimal，所有涉及金额的计算都要通过BigDecimal的方法来完成，不能直接做加减乘除运算。

3. 实操过程：从开发环境搭建到系统跑通

3.1 环境准备与项目初始化步骤

老规矩，先把环境清单列出来。我在这个项目中使用的版本组合是：JDK 1.8、Maven 3.6.3、Spring Boot 2.7.18、MyBatis-Plus 3.5.1、MySQL 5.7、Redis 5.x（缓存购物车用），前端页面使用Vue 2 + Element UI通过Nginx部署（本地开发用Vite即可）。

这个版本组合是我反复验证过的，唯一的建议是：不要在这个组合上随意升版本。Spring Boot 3.x的包名从javax改成了jakarta，MyBatis-Plus 3.5.x之后的协同关系也会变，除了给自己增加排查问题的时间外，没有任何额外收益。

项目初始化我用的是Spring Initializr，IDEA里直接打开File -> New -> Project -> Spring Initializr，填写项目坐标后，在弹出的依赖选择窗口勾选以下依赖：

• Spring Web
• Spring Data Redis
• Spring Security（登录鉴权用）
• MySQL Driver（数据库驱动）
• Lombok（简化实体类代码）
• Validation（参数校验）

需要说明的是Spring Security这一项有点“危险”。Spring Security功能强大但学习曲线陡峭，如果你只是要一个简单的JWT登录拦截，不一定非要引入它；用Spring MVC自带的HandlerInterceptor即可完成Token校验。我在项目里选择了Spring Security，是为了给后台端提供更灵活的权限控制，但在集成之前你要有心理准备——它的过滤器链路非常长，第一次配置登录接口放行时要查阅不少资料。

项目创建完成后，配置application.yml，这里给出核心配置项：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/shop_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里有两个资深从业者才会注意的点。第一，MySQL连接URL里的serverTimezone=Asia/Shanghai非常重要，有人启动项目后数据库连接正常、但所有时间字段都差了8小时，基本就是时区没配置。第二，MyBatis-Plus的逻辑删除配置建议从一开始就加上——网上很多示例是在运行中才加，遇到老数据要写SQL脚本去补救。虽然这是一个很小的点，但直接决定了表结构调整的成本。

3.2 前后端分离架构下的接口联调细节

系统采用前后端分离架构，前端端口在8081（Vue开发服务器），后端端口在8080（Spring Boot）。前后端分离会引入跨域问题，后端必须配置CORS（跨域资源共享）过滤器，否则浏览器会拦截所有响应。

CORS配置不要写成一个散落的过滤器，我建议用Spring Boot的全局配置类统一处理：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

allowedOriginPatterns("*")表示允许所有来源跨域访问，这种方式适合开发阶段。但在真实部署时，最好把这里替换成具体的域名，防止其他站点随意调用你的API。

接口联调阶段另一个高频问题是登录后前端要携带Token访问受限接口。我的做法是：前端在axios请求拦截器中统一把Token塞进Header，后端用HandlerInterceptor统一校验，两个端口各管一头，互不干扰。

前端axios配置核心代码：

// 请求拦截器 service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })

需要注意前端那边有一个规范的细节：Token放置在Header的Authorization字段，格式是Bearer token。这个Bearer前缀是行业标准惯例，后端解析时要先按空格分割，取后半段才是真正的Token。有些人会直接把Token裸放，不受行业规范，别人审查代码时观感不好，所以我还是按标准来写。

后端侧我额外配置了Swagger（Knife4j增强版）来生成接口文档。前端在联调阶段，能实时看到每个接口的请求参数和响应结构，不需要我再打开Word文档对着接口含义慢慢解释。如果你做毕设答辩，评委通常会要求看“接口文档”，Swagger自动生成的页面就是一个很好的加分项。

3.3 核心业务功能实现精讲

注册与登录模块

注册接口的核心逻辑是三步：参数校验、密码加密、数据插入。参数校验用Validation注解处理，密码用BCrypt加密，插入前先查username是否存在。

public String register(RegisterRequest request) { // 1.校验参数 if (!request.getPassword().equals(request.getConfirmPassword())) { throw new BusinessException("两次输入的密码不一致"); } // 2.检查用户名是否已存在 LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(User::getUsername, request.getUsername()); if (userMapper.selectCount(wrapper) > 0) { throw new BusinessException("用户名已存在"); } // 3.密码加密存储 User user = new User(); user.setUsername(request.getUsername()); user.setPassword(BCrypt.hashpw(request.getPassword(), BCrypt.gensalt())); userMapper.insert(user); return "注册成功"; }

这里有一件事我必须专门提醒：密码一定不能明文入库。很多初学者在交出项目时密码明文躺在数据库里，面试官或评委一旦打开数据库就是大事故。BCrypt加盐加密的好处是即使数据库被拖库，攻击者也无法轻易逆推出原始密码。

登录接口验证成功后，生成JWT返回给前端：

String token = Jwts.builder() .claim("userId", user.getId()) .claim("username", user.getUsername()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 3600 * 1000)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();

Token有效期设了24小时，过期后需要重新登录。实际生产项目一般用双Token机制（短期Access Token + 长期Refresh Token），但毕设或课程设计用单Token足够，逻辑反而更清晰。

商品列表与详情展示

商品列表接口需要支持分页、按分类筛选、按关键词搜索、按价格排序。既然用了MyBatis-Plus，分页查询直接使用其内置的Page对象即可，不用手写SQL的LIMIT条件。

public Page<ProductVO> listProducts(Integer pageNum, Integer pageSize, Long categoryId, String keyword, String sort) { LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.isNotBlank(keyword)) { wrapper.like(Product::getName, keyword); } wrapper.eq(Product::getStatus, 1); // 只显示上架商品 if ("priceDesc".equals(sort)) { wrapper.orderByDesc(Product::getPrice); } else { wrapper.orderByAsc(Product::getPrice); } Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper); // 转换为VO并填充图片完整路径等 return convertToVO(page); }

这里把状态为“上架”作为硬性过滤条件，是因为后台有草稿或下架商品，一旦忘了过滤就会把后台才可以看见的非在售商品暴露给用户。加这一行代码，几乎为零成本，但能防止演示现场出大糗。

购物车添加与结算

添加购物车接口要注意的是幂等性：同一个用户重复添加同一商品，不应该创建两条购物车记录，而应该是已存在记录里数量加一。实现方式是先查user_id + product_id是否存在，存在则做更新，否则才执行插入。

结算接口的逻辑比较复杂，要分六步走：查购物车勾选商品列表、校验商品状态、校验库存、生成订单号和订单主记录、批量插入订单明细、扣减库存并清空购物车。这整个过程必须用@Transactional注解包住——任何一个环节失败，所有数据变更全部回滚，不留半拉子数据。

@Transactional(rollbackFor = Exception.class) public OrderInfo createOrder(Long userId) { // 1.查询购物车选中商品 // 2.计算总金额，生成订单主数据 // 3.批量插入订单明细 // 4.扣减商品库存 // 5.清空购物车对应商品 // 6.返回订单详情 }

3.4 后台管理端与数据可视化

后台管理端是评委比较关注的部分，因为它体现了管理员的视角和规范化操作。我用Vue 2 + Element UI搭了一套简单后台界面，核心页面包括：登录页、商品管理（表格+上架/下架按钮）、订单管理（订单列表+发货按钮）、用户管理（用户列表+禁用/解禁）、数据统计大屏。

数据统计页我接入了ECharts，后端接口返回近七天的订单金额和订单数量的聚合数据。SQL写法如下，按日期分组求和：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, COUNT(*) AS order_count, SUM(pay_amount) AS order_amount FROM `order` WHERE status IN (2, 3, 5) AND create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE_FORMAT(create_time, '%Y-%m-%d') ORDER BY day;

执行完SQL后，后端组装成折线图需要的JSON结构返回，前端根据结构直接渲染。这里要注意订单状态筛选——只统计已支付和已完成、售后中的订单，待付款订单不能计入销售额，否则统计口径就不对。

4. 常见问题与调试经验实录

4.1 前端接口跨域与Token失效问题

前后端分离项目中最常遇到的第一个拦路虎就是跨域问题。现象是前端页面请求后端接口时，浏览器控制台报出类似“Access to XMLHttpRequest at 'http://localhost:8080/api/...' from origin 'http://localhost:8081' has been blocked by CORS policy”的红色错误。

这个错误看起来吓人，解决起来其实就是后端加CORS配置。但我遇到过不少同学照抄网上的CORS配置后依然报错，排查半天发现是allowCredentials(true)和allowedOrigins("*")不能同时使用造成的。Spring Boot在较新版本中，如果设置allowCredentials(true)，就不能再用allowedOrigins("*")，必须改成allowedOriginPatterns("*")。这个细节改一下，问题立刻消失。

Token失效的问题也很常见，典型症状是登录成功后第一次请求接口正常，但过十几分钟再操作就报401。我在排查中定位到的原因基本是这两种：一是Token有效期设置太短，二是前端没有正确处理Token过期后的刷新逻辑。解决方案也简单：把Token有效期设置为24小时；前端在响应拦截器里检测到401时，自动跳转到登录页并清理本地Token，让用户重新登录。

4.2 Spring Boot版本过高导致的依赖兼容性问题

网上很多Spring Boot教程默认用最新版本，但跟着教程做项目时，各种奇奇怪怪的报错就会冒出来。最常见的两个：一个是Spring Boot 3.x将javax.servlet包迁移到jakarta.servlet，导致老代码里所有的import javax.servlet.*全部编译失败；另一个是Spring Security 6.x的配置API大幅调整，网上搜到的解决方案大多是旧版写法，照抄过来直接报错。

排查报错要养成习惯——先看异常信息栈顶的几行。根据我的经验，70%以上的依赖兼容问题可以通过固定Spring Boot版本解决，不用一路追新。Spring Boot 2.7.18是我在多个毕业设计项目中验证过的稳定版本：它支持JDK 8，各种第三方Starter兼容资料大而全，MyBatis-Plus、Knife4j、JWT库都能完美配合。

4.3 上传文件失败与资源映射配置

网购平台的商品图片上传功能，是整个项目中一个非常容易出问题的点。我遇到的典型报错是：图片上传接口返回成功，但前端通过URL访问图片时404。排查后发现，图片确实已经写到服务器的磁盘目录了，但Spring Boot默认不会把本地磁盘目录暴露成可访问的静态资源路径，需要在配置类中追加资源映射。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + Constants.UPLOAD_DIR); } }

配置说明：/upload/**是前端访问图片的URL前缀，file:加磁盘绝对路径指向图片上传的物理目录。配置之后，前端访问http://localhost:8080/upload/xxx.jpg就能正常显示。如果你在Windows上开发，注意路径中的反斜杠问题，统一使用正斜杠分割目录，否则在Linux服务器上部署时又会踩坑。

大文件上传则是另一个常见的坑。Spring Boot默认的单次请求大小限制为1MB，上传大于1MB的图片或视频会直接报错。如果你希望支持更大文件上传，需要在配置文件中放开限制：

spring: servlet: multipart: max-file-size: 100MB max-request-size: 200MB

这两个限制一个针对单个文件的体积，一个针对整个请求的体积。当你上传多文件时，max-request-size一定要比max-file-size大，否则文件数量一多就会触发异常。

4.4 数据库时间与本地时间不一致

这个问题的经典症状是：在后台上架一个商品，时间字段在页面上显示比当前时间多8小时。这个8小时的偏差，就是时区问题。

排查思路：

• 如果数据库、后端、操作系统都默认使用UTC时区，那么记录的时间是UTC时间；而东八区用户看到的时间就会比北京时间早8小时。
• 如果只有后端设置了国内时区，数据库没有设置，那么JDBC连接时会采用MySQL连接URL中时区参数或操作系统默认时区，导致读取到的时间差8小时。

解决方法是三层统一时区：MySQL连接URL中固定加serverTimezone=Asia/Shanghai；后端启动类或配置文件中设置spring.jackson.time-zone=GMT+8，实体类中统一用LocalDateTime类型；前端统一使用后端返回的ISO字符串格式时间，不做额外的本地转换。

时间字段的存储类型也要注意。我看到很多项目用java.util.Date和timestamp搭配，代码中各种Date转String的操作既繁琐又容易出错。直接用LocalDateTime对应MySQL的datetime类型，配合MyBatis-Plus的自动填充功能，创建时间和更新时间字段不用手动赋值，设置起来要顺手得多。

4.5 事务不生效：@Transactional的常见误用

在创建订单时，我用@Transactional保证了多表操作的原子性。但很多人会遇到事务不生效的问题——方法内某个步骤抛异常，前面已经执行的数据库操作没有回滚。

排查结果通常归结为以下三种情况：

第一，@Transactional加在了非public方法上。Spring默认通过代理实现事务，代理只能拦截public方法。如果你把注解加在private或protected方法上，事务不会生效，而且Spring不会报警告。这个坑非常隐蔽。

第二，同类内部调用。用户在Service类中调用另一个方法，这个方法虽然加了@Transactional，但由于是同类内部this调用，不会经过Spring代理，事务依然不生效。

第三，事务方法中自己捕获了异常。@Transactional默认只能回滚RuntimeException，如果代码里catch住了异常，事务判定“没有异常发生”，自然就不回滚。正确做法是捕获后重新抛出，或者在注解中声明rollbackFor = Exception.class并向外抛出异常。

这里也推荐一种我在项目中的做法：在事务方法开头校验所有必要的状态，提前返回业务错误；对于真正要回滚的情况，抛出BusinessException并向外层传递，由统一的全局异常处理器转化为HTTP响应。

5. 文档配套：从“能跑”到“讲得清”

5.1 项目文档应该写什么

这个项目的标题里带了“文档+源码”，说明交付的不只是代码，还有一份能够配合答辩或汇报的说明文档。很多人在开发上花了很多时间，写文档却草草了事，这是非常不划算的。一份好的项目文档，应该包含以下内容：

项目背景与研究意义：说明网购平台的市场需求和本项目的价值，不用写太多，一页左右即可。

技术选型说明：逐个介绍使用的框架和中间件，并简要说明为什么要选它。比如“采用Spring Boot是因为其自动配置机制可以减少XML配置、快速搭建项目”就是一句能说明白的话。

系统需求分析：包括功能性需求（用户端功能、管理员端功能）和非功能需求（性能、安全性、可扩展性），可以用用例图来辅助说明。

系统设计：架构图、模块划分、数据库ER图、核心表结构说明、接口设计列表。这部分是文档最核心的部分，直接反映你对系统的理解深度。

系统实现：挑2~3个核心功能点展开描述，说明实现思路和关键代码。比如订单状态机的设计、库存扣减的并发方案、JWT认证机制。选1-2张关键代码截图放进去（用Snipaste截图保存为PNG再插入），比全部从PDF里截取的效果更好。

系统测试：包括测试用例表、测试结果、异常场景处理示例。逐个模块说明测试通过情况，并列举一两个如何修复Bug的解决问题过程。

总结与展望：简明扼要地总结完成情况和不足，以及未来可以扩展的方向（如接入Redis缓存热点商品、使用消息队列处理订单高峰等）。最后这部分是最容易被忽视的，但对拿了“良好”或者“优秀”的评价很关键。

5.2 答辩时的高频提问准备

做完系统，更重要的环节是“讲清楚”。我根据多次答辩经验，总结了评委最常问的问题，你在交付前不妨先对照自检：

• 为什么选Spring Boot？选它的优势在哪里？
• JWT和Session有什么区别？你为什么会选JWT？
• 库存扣减时多个用户同时下单怎么保证不超卖？
• 订单状态是怎么管理的？状态之间如何转换？
• 如果用户下单后一直不付款，库存会被一直占用吗？
• 数据库表有哪些？表之间的联系是什么？为什么订单明细要冗余商品信息？
• 如何保证密码安全？数据库的账号密码是明文吗？
• 前后端分离架构中如何解决跨域问题？

这些问题基本上覆盖了系统的每一个核心模块，是应对答辩的“题库”。哪怕之前没有系统整理过，只要把这篇博文中的设计思路真正理解了，结合实际代码去回答，基本都能讲得比较清楚。

6. 项目扩展与后续演进建议

这个项目真正做进去之后，你会发现它已经具备了一个电商系统的雏形，但距离真实商城还有距离。如果时间有余力，或者你想在简历上写得更有亮点，可以考虑以下几个扩展方向。

商品搜索目前基于数据库的LIKE模糊查询，简单但不支持分词和多字段排序。引入Elasticsearch作为搜索服务，把商品名称、分类、描述建索引，检索速度和搜索体验会明显提升。

购物车和商品热点数据目前还是直接查数据库，每次刷新页面都要访问MySQL。引入Redis缓存热点商品数据，设置过期时间，能够明显降低数据库的压力，把这部分改动和现有代码整合后，可以讲出一个比较漂亮的“缓存优化”故事。

订单超时未支付的定时扫描方案效率有限，换成RabbitMQ延迟队列之后，下单时把订单号投递到延迟队列，延迟时间到了之后监听者自动检查并处理超时订单，既不用轮询数据库，延迟也更精确。

单机部署对毕设来说够用，但在简历上写“支持高并发”之前，先想想自己的系统是否真的扛得住。把Nginx反向代理和负载均衡搭起来、将会话状态外置到Redis，才等于真正迈入了分布式环境的门槛。

这些扩展点不需要全部做完，挑选一个能讲透就足够。很多人在简历里写“熟悉Redis、消息队列”，但在项目介绍时却没有对应的实践支撑，一追问就露馅。与其那样，不如只做一个扩展点，把它和现有系统的关系讲清楚。

7. 个人实操心得与踩坑提醒

这个项目整体做下来，我的切身感受是：网购平台管理系统是典型的“看起来简单、做起来繁杂、打磨起来无底洞”。它不像“图书管理系统”那样几块业务就完事，也不像“秒杀系统”那样一个点钻到黑，而是涉及用户、商品、订单、支付、后台统计等多个领域的交叉整合。正是这种广度，让它成为毕业设计和课程设计的常青树——但我还是想给大家几句实在的建议。

版本锁定优先于功能开发。这句话我重复了多次，但值得再强调一遍：一个项目开始之前，先把Spring Boot、JDK、MySQL、第三方Starter的版本全部固定下来，写成一份README.md放到项目根目录。不要在网上看哪个版本新就换哪个，稳定能跑才是第一优先级。

不要忽略异常处理和日志输出。很多同学写代码时只关注正常流程，完全没有考虑异常分支。一旦演示现场出了问题，没有日志根本无法定位。我在项目中使用了SLF4J结合Logback统一记录日志，接口入口打印请求参数，事务方法打印执行结果，排查问题时省了非常多的时间。

答辩前至少自己要完整跑一遍“从注册到收货”的全流程，而不是在演示时才发现购物车添加成功了但结算按钮永远置灰。把用户端和管理端的核心路径都过一遍，比背十遍PPT都有效。

最后，文章的文档目录里我附上了完整的SQL初始化脚本和配置文件的注释版本。如果你拿到项目源码之后第一件事是修改数据库密码和Redis密码再启动，那至少不会被自己设置的密码坑半小时了。

这套“基于Spring Boot的网购平台管理系统”，代码本身并不复杂，但把每一个模块的设计思路梳理清楚、把每一处容易踩坑的细节都处理到位之后，它就是一个拿得出手的完整项目。希望这份拆解能帮你在自己的项目里少走一些我已经走过的弯路。