1. 项目概述与整体设计思路1.1 核心需求解析网购平台管理系统到底在管什么很多人一听到“网购平台管理系统”这个名字第一反应就是“又一个电商CRUD”。确实市面上基于Spring Boot的电商管理系统不在少数但真正把“管理系统”和“网购平台”这两件事都讲清楚的并不多。这个项目要解决的其实是两类角色、五条核心链路的完整闭环。先拆角色。网购平台一定有前台用户和后台管理员二者是天然割裂的。前台用户关心的是注册登录、浏览商品、加购物车、下单支付、查看订单状态后台管理员关心的是商品上下架、库存管理、订单审核与发货、用户管理、销售数据统计。一个合格的毕设级项目至少要覆盖这两个端口的核心操作否则就只是“商品展示页”而不是“管理系统”。再拆链路。我把整个系统的核心流程归纳为五条用户认证链路、商品流转链路、购物车到订单的转化链路、支付与订单状态机链路、后台数据统计链路。这五条链路不是各自孤立的它们在订单主表上汇聚——订单既是用户行为的终点也是管理员操作的起点。项目设计的第一原则就是把订单这条主线理清楚其他所有模块都围绕它展开。商品的流转链路则是整个系统最普遍也最容易被忽略的一部分。从后台录入商品、设置库存和价格到前台展示、加入购物车、扣减库存再到订单完成后的库存恢复这里面的状态一致性处理得好不好直接影响系统在演示时的专业度。比如下单失败要不要回滚库存、超卖怎么防、取消订单要不要恢复库存这些细节不是靠CRUD能糊弄过去的而是需要事务和状态机配合。1.2 为什么是Spring Boot而不是SSH或SSM技术选型这件事很多人觉得无所谓能跑就行。但我个人的建议是哪怕不用来做毕设而是为了真正理解一个企业级Web项目的全貌Spring Boot依然是目前性价比最高的选择没有之一。SSHStrutsSpringHibernate和SSMSpringSpringMVCMyBatis是老一辈项目的主流问题在于配置繁琐。一个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加密。登录环节我采用的是JWTJSON Web Token方案服务端生成Token返回给前端前端每次请求在Header里带上Token后端通过拦截器校验身份。相比Session方案JWT天然适合前后端分离也不需要担心集群环境下的Session共享问题。商品模块包含商品分类、商品信息、商品图片和库存管理。商品分类使用自关联表结构可以支持无限层级的分级但考虑到实际演示效果两级分类就够了。商品信息表要设计好状态字段草稿、上架、下架、售罄后台管理员可随时切换状态。库存字段要单独放在商品主表中因为它是高频更新字段且与订单事务强相关拆出去反而增加复杂度。购物车模块的设计有一个特别容易踩坑的点购物车数据到底是放Redis还是放数据库。如果只是存在Redis用户换台设备购物车就消失体验很差如果只存数据库每次加减商品都要更新数据库性能负担大。我采用的是双写策略——数据库做持久化Redis做读取缓存用户在浏览商品时将购物车写入Redis结算时一次性同步到数据库。这个折中方案既保证了数据不丢又保证了交互流畅度。订单模块是整个系统的核心我单独在后面用一节来讲。支付模块我选择了模拟支付的方式——在系统内创建一个虚拟支付页面用户点击“确认支付”后直接跳转到支付成功页同时在后台生成一条支付流水记录。这样既避开了真实支付接口的繁琐申请流程又能把支付从下单到支付成功、订单状态流转的完整链路跑通。后台管理模块则覆盖用户管理、商品管理、订单管理、数据统计四大块。数据统计我采用了ECharts展示近七天的订单量和销售额趋势图后台管理页面用VueElement 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 数据库核心表结构设计数据库是网购平台的基座表结构设计得好不好直接决定了业务逻辑写的痛不痛苦。我设计了十张核心业务表这里重点说六张数据表名核心字段说明用户表(user)id, username, password, nickname, phone, avatar_url, created_time密码用BCrypt加密存储nickname可空商品分类表(category)id, parent_id, name, sort_orderparent_id为0表示顶级分类商品表(product)id, category_id, name, subtitle, main_image, sub_images, price, stock, status, sales_count, created_timeprice使用decimal(10,2)status用tinyint购物车表(cart)id, user_id, product_id, quantity, checked, created_time用user_idproduct_id建唯一索引订单表(order)id, order_no, user_id, total_amount, pay_amount, status, address_detail, receiver_name, receiver_phone, create_time, pay_time, send_time, finish_timeorder_no必须唯一订单明细表(order_item)id, order_id, product_id, product_name, product_image, current_unit_price, quantity, total_price商品快照字段不能join商品表查最新信息一个关键设计决策必须说明订单明细表为什么要冗余商品名称和商品价格而不是下单时去关联商品表因为商品的价格和名称是会变的——后台管理员改个价之前下单的订单如果直接查商品表价格就全乱了。正确的做法是在生成订单明细的那一刻把当时商品的核心信息“拍照存根”之后就与商品表不再有依赖关系。这是电商系统的必备经验也是很多新手容易忽略的细节。另外需要注意的是金额字段一律用decimal(10,2)不能用double或float否则会出现0.10.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改成了jakartaMyBatis-Plus 3.5.x之后的协同关系也会变除了给自己增加排查问题的时间外没有任何额外收益。项目初始化我用的是Spring InitializrIDEA里直接打开File - New - Project - Spring Initializr填写项目坐标后在弹出的依赖选择窗口勾选以下依赖Spring WebSpring Data RedisSpring 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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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里的serverTimezoneAsia/Shanghai非常重要有人启动项目后数据库连接正常、但所有时间字段都差了8小时基本就是时区没配置。第二MyBatis-Plus的逻辑删除配置建议从一开始就加上——网上很多示例是在运行中才加遇到老数据要写SQL脚本去补救。虽然这是一个很小的点但直接决定了表结构调整的成本。3.2 前后端分离架构下的接口联调细节系统采用前后端分离架构前端端口在8081Vue开发服务器后端端口在8080Spring 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裸放不受行业规范别人审查代码时观感不好所以我还是按标准来写。后端侧我额外配置了SwaggerKnife4j增强版来生成接口文档。前端在联调阶段能实时看到每个接口的请求参数和响应结构不需要我再打开Word文档对着接口含义慢慢解释。如果你做毕设答辩评委通常会要求看“接口文档”Swagger自动生成的页面就是一个很好的加分项。3.3 核心业务功能实现精讲注册与登录模块注册接口的核心逻辑是三步参数校验、密码加密、数据插入。参数校验用Validation注解处理密码用BCrypt加密插入前先查username是否存在。public String register(RegisterRequest request) { // 1.校验参数 if (!request.getPassword().equals(request.getConfirmPassword())) { throw new BusinessException(两次输入的密码不一致); } // 2.检查用户名是否已存在 LambdaQueryWrapperUser 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 PageProductVO listProducts(Integer pageNum, Integer pageSize, Long categoryId, String keyword, String sort) { LambdaQueryWrapperProduct 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); } PageProduct 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中固定加serverTimezoneAsia/Shanghai后端启动类或配置文件中设置spring.jackson.time-zoneGMT8实体类中统一用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的网购平台管理系统”代码本身并不复杂但把每一个模块的设计思路梳理清楚、把每一处容易踩坑的细节都处理到位之后它就是一个拿得出手的完整项目。希望这份拆解能帮你在自己的项目里少走一些我已经走过的弯路。
1. 项目概述与整体设计思路1.1 核心需求解析网购平台管理系统到底在管什么很多人一听到“网购平台管理系统”这个名字第一反应就是“又一个电商CRUD”。确实市面上基于Spring Boot的电商管理系统不在少数但真正把“管理系统”和“网购平台”这两件事都讲清楚的并不多。这个项目要解决的其实是两类角色、五条核心链路的完整闭环。先拆角色。网购平台一定有前台用户和后台管理员二者是天然割裂的。前台用户关心的是注册登录、浏览商品、加购物车、下单支付、查看订单状态后台管理员关心的是商品上下架、库存管理、订单审核与发货、用户管理、销售数据统计。一个合格的毕设级项目至少要覆盖这两个端口的核心操作否则就只是“商品展示页”而不是“管理系统”。再拆链路。我把整个系统的核心流程归纳为五条用户认证链路、商品流转链路、购物车到订单的转化链路、支付与订单状态机链路、后台数据统计链路。这五条链路不是各自孤立的它们在订单主表上汇聚——订单既是用户行为的终点也是管理员操作的起点。项目设计的第一原则就是把订单这条主线理清楚其他所有模块都围绕它展开。商品的流转链路则是整个系统最普遍也最容易被忽略的一部分。从后台录入商品、设置库存和价格到前台展示、加入购物车、扣减库存再到订单完成后的库存恢复这里面的状态一致性处理得好不好直接影响系统在演示时的专业度。比如下单失败要不要回滚库存、超卖怎么防、取消订单要不要恢复库存这些细节不是靠CRUD能糊弄过去的而是需要事务和状态机配合。1.2 为什么是Spring Boot而不是SSH或SSM技术选型这件事很多人觉得无所谓能跑就行。但我个人的建议是哪怕不用来做毕设而是为了真正理解一个企业级Web项目的全貌Spring Boot依然是目前性价比最高的选择没有之一。SSHStrutsSpringHibernate和SSMSpringSpringMVCMyBatis是老一辈项目的主流问题在于配置繁琐。一个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加密。登录环节我采用的是JWTJSON Web Token方案服务端生成Token返回给前端前端每次请求在Header里带上Token后端通过拦截器校验身份。相比Session方案JWT天然适合前后端分离也不需要担心集群环境下的Session共享问题。商品模块包含商品分类、商品信息、商品图片和库存管理。商品分类使用自关联表结构可以支持无限层级的分级但考虑到实际演示效果两级分类就够了。商品信息表要设计好状态字段草稿、上架、下架、售罄后台管理员可随时切换状态。库存字段要单独放在商品主表中因为它是高频更新字段且与订单事务强相关拆出去反而增加复杂度。购物车模块的设计有一个特别容易踩坑的点购物车数据到底是放Redis还是放数据库。如果只是存在Redis用户换台设备购物车就消失体验很差如果只存数据库每次加减商品都要更新数据库性能负担大。我采用的是双写策略——数据库做持久化Redis做读取缓存用户在浏览商品时将购物车写入Redis结算时一次性同步到数据库。这个折中方案既保证了数据不丢又保证了交互流畅度。订单模块是整个系统的核心我单独在后面用一节来讲。支付模块我选择了模拟支付的方式——在系统内创建一个虚拟支付页面用户点击“确认支付”后直接跳转到支付成功页同时在后台生成一条支付流水记录。这样既避开了真实支付接口的繁琐申请流程又能把支付从下单到支付成功、订单状态流转的完整链路跑通。后台管理模块则覆盖用户管理、商品管理、订单管理、数据统计四大块。数据统计我采用了ECharts展示近七天的订单量和销售额趋势图后台管理页面用VueElement 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 数据库核心表结构设计数据库是网购平台的基座表结构设计得好不好直接决定了业务逻辑写的痛不痛苦。我设计了十张核心业务表这里重点说六张数据表名核心字段说明用户表(user)id, username, password, nickname, phone, avatar_url, created_time密码用BCrypt加密存储nickname可空商品分类表(category)id, parent_id, name, sort_orderparent_id为0表示顶级分类商品表(product)id, category_id, name, subtitle, main_image, sub_images, price, stock, status, sales_count, created_timeprice使用decimal(10,2)status用tinyint购物车表(cart)id, user_id, product_id, quantity, checked, created_time用user_idproduct_id建唯一索引订单表(order)id, order_no, user_id, total_amount, pay_amount, status, address_detail, receiver_name, receiver_phone, create_time, pay_time, send_time, finish_timeorder_no必须唯一订单明细表(order_item)id, order_id, product_id, product_name, product_image, current_unit_price, quantity, total_price商品快照字段不能join商品表查最新信息一个关键设计决策必须说明订单明细表为什么要冗余商品名称和商品价格而不是下单时去关联商品表因为商品的价格和名称是会变的——后台管理员改个价之前下单的订单如果直接查商品表价格就全乱了。正确的做法是在生成订单明细的那一刻把当时商品的核心信息“拍照存根”之后就与商品表不再有依赖关系。这是电商系统的必备经验也是很多新手容易忽略的细节。另外需要注意的是金额字段一律用decimal(10,2)不能用double或float否则会出现0.10.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改成了jakartaMyBatis-Plus 3.5.x之后的协同关系也会变除了给自己增加排查问题的时间外没有任何额外收益。项目初始化我用的是Spring InitializrIDEA里直接打开File - New - Project - Spring Initializr填写项目坐标后在弹出的依赖选择窗口勾选以下依赖Spring WebSpring Data RedisSpring 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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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里的serverTimezoneAsia/Shanghai非常重要有人启动项目后数据库连接正常、但所有时间字段都差了8小时基本就是时区没配置。第二MyBatis-Plus的逻辑删除配置建议从一开始就加上——网上很多示例是在运行中才加遇到老数据要写SQL脚本去补救。虽然这是一个很小的点但直接决定了表结构调整的成本。3.2 前后端分离架构下的接口联调细节系统采用前后端分离架构前端端口在8081Vue开发服务器后端端口在8080Spring 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裸放不受行业规范别人审查代码时观感不好所以我还是按标准来写。后端侧我额外配置了SwaggerKnife4j增强版来生成接口文档。前端在联调阶段能实时看到每个接口的请求参数和响应结构不需要我再打开Word文档对着接口含义慢慢解释。如果你做毕设答辩评委通常会要求看“接口文档”Swagger自动生成的页面就是一个很好的加分项。3.3 核心业务功能实现精讲注册与登录模块注册接口的核心逻辑是三步参数校验、密码加密、数据插入。参数校验用Validation注解处理密码用BCrypt加密插入前先查username是否存在。public String register(RegisterRequest request) { // 1.校验参数 if (!request.getPassword().equals(request.getConfirmPassword())) { throw new BusinessException(两次输入的密码不一致); } // 2.检查用户名是否已存在 LambdaQueryWrapperUser 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 PageProductVO listProducts(Integer pageNum, Integer pageSize, Long categoryId, String keyword, String sort) { LambdaQueryWrapperProduct 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); } PageProduct 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中固定加serverTimezoneAsia/Shanghai后端启动类或配置文件中设置spring.jackson.time-zoneGMT8实体类中统一用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的网购平台管理系统”代码本身并不复杂但把每一个模块的设计思路梳理清楚、把每一处容易踩坑的细节都处理到位之后它就是一个拿得出手的完整项目。希望这份拆解能帮你在自己的项目里少走一些我已经走过的弯路。
