选题选到最后还是回到了“网上商城”，这几乎是计算机专业毕设里的必答题。尤其是这个标题——SpringBoot农产品网上销售平台——一眼看过去，好像人人都在做，但真到自己动手的时候，功能设计、表结构、下单流程、库存扣减，每一步都能卡住一批人。这篇东西不是给你贴一个“教学视频式”的项目概览，而是直接把一个能过答辩的农产品电商平台拆开来看，功能怎么分、表怎么建、接口怎么写、哪些坑必须绕开，一步到位。

这篇文章适合谁？正在为毕设选题发愁的同学，已经开题但系统还没跑通的初级开发者，以及想快速了解一个标准电商系统如何落地的新人。默认你懂Java基础、会写简单的SQL、知道SpringBoot是什么，但不要求你有多深的分布式经验——这里用的技术方案，全是单机应用里最成熟、最不会给自己挖坑的那一套。

1. 项目定位与整体技术栈选择

1.1 为什么是SpringBoot + 农产品这个组合

先说一个观点：毕设选型的第一原则是“稳妥”，而不是“炫技”。SpringBoot在这几年已经成了Java后端的事实标准，原因很简单——它把Spring那套繁琐的XML配置几乎全都省掉了，一个main方法直接启动Web服务，内嵌Tomcat，连部署都省了。对毕设来说，这意味着你能把80%的精力放在业务逻辑本身，而不是跟环境配置较劲。

农产品网上销售平台这个业务方向也很聪明。它本质上是电商系统，但比“通用商城”多了一层场景感——生鲜的保质期、产地信息、重量单位（斤/份）、冷链配送提示，这些都是买家决策的关键信息。答辩的时候，你把这些业务细节说清楚，比单纯讲“我做了个CRUD”要加分得多。而且农产品平台的数据模型比标准商品模型更有话说，后面我会详细拆。

1.2 技术栈清单与选型理由

这是一个标准的单体应用架构，我直接给你能用的组合：

• 后端框架：SpringBoot 2.7.x，稳定版本，网上资料最多，文档最好找
• 持久层框架：MyBatis-Plus，注意不是MyBatis。MyBatis-Plus内置了分页插件、条件构造器和代码生成器，能省掉大量重复的Mapper XML
• 数据库：MySQL 5.7或8.0，推荐8.0，默认字符集直接utf8mb4，避免中文乱码问题
• 前端方案：后台管理用Thymeleaf模板引擎或Vue3 + Element-Plus二选一。前台商城建议用Vue3 + Element-Plus，页面交互更现代，答辩演示的时候效果更好
• 鉴权方案：JWT + 拦截器，前后端分离下的最简方案，比Session更适合Vue项目
• 文件存储：本地磁盘 + Nginx映射静态资源，毕设不需要接七牛云或者OSS，除非你的中期检查要求必须用，否则别给自己找麻烦

这里有一条经验：毕设项目最忌讳“过度设计”。如果我只做了毕业设计，我会把分布式事务、消息队列、微服务全部从方案里划掉。农产品平台的单日订单量再大，单库单表也完全扛得住。你答辩讲“SpringCloud微服务化”听着高级，但评委一句“你这个微服务拆分依据什么原则”就能把你问住。

前端技术栈的补充说明：如果你前端基础普通，就别硬上Vue3的Composition API，用Options API就能完成全部功能。后台管理页面优先用现成的AdminLTE或vue-element-admin的简化版，自己从零画后台UI是纯浪费时间。系统里用户的角色分三类：买家、卖家（平台自营）、管理员，角色不同看到的菜单和能点的按钮完全不同，这个在路由鉴权阶段要结合JWToken中的角色字段做判断。

1.3 开发环境与工具准备

这个其实是最容易翻车的一环，很多人代码写到一半才发现JDK版本不对、数据库驱动不匹配。我这里列一套经过验证的组合，你照着装：

• JDK：1.8以上，建议用JDK 8。SpringBoot 2.7对JDK 8的支持最成熟，JDK 17会有一堆模块化的问题，不适合新手。
• 构建工具：Maven 3.8+，阿里云镜像在settings.xml里配好，不然拉依赖能让你怀疑人生。
• IDE：IntelliJ IDEA旗舰版，社区版也够用但少了Spring Assistant，自己手动写配置也不难。
• 数据库客户端：Navicat或DBeaver，前者对中文文档和支持更好。
• 接口测试：Postman或Apifox。我建议直接用Apifox，它能把接口文档和测试用例放在一起管理，期末写文档的时候直接导出即可。

所有配置我都建议统一放application.yml里，不要用application.properties——YAML格式的层级结构清晰得多，而且MyBatis-Plus的配置在YAML下看起来一目了然。

2. 系统功能模块设计与流程拆解

2.1 角色划分与权限模型

农产品平台的角色不是随意定的，每个角色的背后都是一个真实的业务场景。我把系统拆成三种角色，对应三套功能集合：

• 买家（消费者）：围绕“浏览—加购—下单—支付—收货—评价”这条链路设计功能。界面必须突出产地、价格、库存、评价数四个要素。
• 卖家（平台方）：只做后台商品管理与订单处理。这里要注意，农产品平台早期通常只允许自营，所以卖家角色可以直接并入管理员后台，不需要单独C端店铺功能。
• 系统管理员：负责用户管理、类目管理、首页Banner管理、订单总览、数据统计。这是答辩时评委最喜欢打开看的模块，因为能直观展示系统的完整性。

权限模型这层，如果只做前端按钮级控制而不在后端拦截，就是个金玉其外的漏洞。我建议在SpringMVC的拦截器里做二次校验：凡是用@AdminOnly标注的接口，Java方法执行前都必须检查Token里的角色字段。判定规则写一个自定义注解+拦截器，一共不到二十行代码，但能给系统的安全性写上一个很扎实的注脚。

2.2 前台功能模块地图

前台商城是这个项目最花时间的部分，它几乎决定了答辩演示的好看程度。核心功能包括：

首页展示：轮播图、限时推荐、按蔬菜/水果/肉禽蛋/粮油四个大类导航。如果是农产品，首页还要预留“时令推荐”和“产地直供”两个区块，这两个词很加分。

商品检索：关键词模糊查商品名称、产地、简介，按价格区间筛选，按销量排序，按价格升序降序排列。建议列表页分页每页显示12个商品，搜索历史记录保存在前端localStorage里。

商品详情页：多图展示、详细描述、库存显示、销量显示、加入购物车按钮。详情页的图片放大功能不建议自己写，直接用Element-Plus的Image组件，预览效果比原生好得多。

购物车：增删改查，支持批量勾选，计算总价实时更新。购物车是典型的“纯前端交互+后端同步”功能，后端接口只需要接收最终的选中列表和数量即可。

订单结算：确认收货地址、商品清单、配送方式（普通/冷链）、支付方式（模拟支付），生成订单号。因为毕设不接真实支付网关，模拟支付表单弹窗即可，但要注意订单状态必须完整走完“待支付→已支付→配送中→已完成”这条链路，不能只做一步到位。

个人中心：查看订单列表、订单详情、取消订单、确认收货、评价商品、修改个人信息和头像。

地址管理：这里有个坑，很多人只用一张address表搞定，但在快递单、结算页和订单详情的快照之间，必须要做到“查询时关联、下单时复制”，不然用户改了地址会导致订单历史地址变化，这个细节做得好的寥寥无几。

2.3 后台管理功能模块地图

后台是整个系统的“黑话场”，也是工作量的大头，右键一个商品让你从0到1去思考数据如何流转，以下模块一个都不能少：

商品管理：列表查询、新增商品、编辑商品、上下架、删除。删除这里一定要用逻辑删除，不要物理删除，哪怕是毕设，因为订单历史引用商品的关联记录，物理删了会导致联查结果为null。

类目管理：二级分类结构，一级为蔬菜/水果/肉禽蛋/粮油，二级为具体品名。最简单的实现就是一张表parent_id指向自己，加载为两级级联。

订单管理：按状态筛选（待付款/待发货/已发货/已完成/已取消），订单详情可查看商品快照、地址快照、支付流水号，管理员可以手动发货填入物流单号，也可以取消异常订单。

用户管理：用户列表、状态封禁/解禁、重置密码。重置密码不是让你存明文，而是调一个工具类生成MD5+随机盐的新密码，把新初始密码返回给管理员去通知用户。

Banner管理：首页轮播图的CRUD，上传图片、设置跳转链接、排序值、启用状态。

数据统计：今日订单量、今日销售额、近七日走势图、商品销量Top10。图表用ECharts，后端只需要提供JSON格式的统计数据，前端画图就行。这个模块放在最后做，因为它是锦上添花，不影响主流程。

2.4 核心业务流程串讲

从买家下单到库存扣减，这里我用文字画一条主链路，代码实现时按这个顺序走：

用户登录→浏览商品详情→加入购物车→进入结算页填写收货地址→点击提交订单，后端一次性干四件事：生成订单主表记录（状态=待付款）、生成订单明细快照（含商品名称、单价、图片、数量）、扣减商品库存（库存字段减掉购买数量）、清空购物车中对应商品。

订单生成后，用户点击“模拟支付”，后端把订单状态改成“已支付”，同时生成一条支付流水记录。管理员在后台看到“已支付”订单后点击发货，填入物流单号；用户收到货后点“确认收货”,状态变成“已完成”，此时开放评价入口。

这个流程看似简单，但实现时要注意“事务”两个字——上面说的四件事必须在同一个事务里完成，任何一个失败都要全部回滚。后面第五章会专门讲事务失效的坑。

3. 数据库表结构设计

3.1 核心表清单与关系说明

数据库是电商系统的地基，地基不稳，后面写接口全是补丁。下面这张表清单是我认为的“最小完整集”，一共9张表，每张表都带业务含义来设计，不搞冗余字段：

• user：用户表，含手机号、昵称、头像、密码、角色、状态、盐
• address：收货地址表，含userId、收货人、电话、省市区、详细地址、是否默认
• category：商品分类表，含父级id、分类名、排序
• product：商品表，含分类id、名称、副标题、主图、轮播图、详情、价格、原价、库存、销量、单位、产地、状态
• cart：购物车表，含userId、productId、数量、选中状态
• orders：订单主表，含订单号、userId、总金额、支付方式、支付状态、订单状态、收货信息快照、物流单号
• order_item：订单明细表，含订单id、商品id、商品名称、商品图片、单价、数量、小计
• payment：支付流水表，含订单id、支付单号、支付金额、支付方式、支付状态、回调时间（模拟回调可缺省）
• comment：评论表，含订单明细id、商品id、userId、评分、内容、图片、回复

3.2 关键表字段设计详解

我挑两张最容易被设计错的表来拆解一下。

第一张是product表。价格字段推荐用decimal(10,2)，不要用double，否则在计算金额时会出现0.1+0.2!=0.3的问题。农产品要特别关注unit字段，蔬菜按“500g”或“份”计价，水果按“1kg”或“3个装”计价更符合场景，这是产品与标准商品不同的地方。库存字段要用int，默认值设为0，并在逻辑上增加“上架时必须库存大于0”的校验。还有一个细节，product表要有sales（销量）字段，而不要实时count订单明细，因为后者在千万级数据下性能会崩，毕设虽然数据量小，但好习惯要养成。

第二张是orders表。订单金额和商品单价都必须冗余存储，不能去联查product，因为商品价格会变，历史订单必须保持当时的成交快照。收货人也必须冗余，因为地址表可以被编辑或删除。这些冗余虽然违背“数据库设计范式”，但在电商场景中恰恰是正确做法。订单状态默认值为0，对应的状态机是0待支付、1已支付、2已发货、3已完成、4已取消。

3.3 索引设计与SQL优化建议

毕设的SQL量级不大，但如果你把“性能优化”这段写进论文里，是很加分的实操小节。建议在以下字段建索引：

• 高频查询字段：product表的category_id、product_name（前缀匹配）、sales；orders表的user_id、status；order_item表的order_id
• 唯一约束：user表的phone、orders表的order_no
• 联合索引：orders表(user_id, status)是查询“我的订单列表+状态筛选”的标配；order_item表(order_id, product_id)用于防止同一商品重复插入

再补充一个简易分页技巧：MyBatis-Plus的分页插件做到物理分页，不要用PageHelper那个旧款。配置一个MybatisPlusInterceptor的Bean，把PaginationInnerInterceptor加进去，后续Page对象直接透传，很顺手。

4. 核心功能实现实战

4.1 项目初始化与统一返回结构

项目创建直接用Spring Initializr，依赖选择Web、MySQL驱动、Lombok、Validation、MyBatis-Plus。但用MyBatis-Plus时要注意，它和Spring Boot 2.7的版本兼容性极佳，无需额外改配置。pom.xml里加入一行hutool工具包的依赖，后面生成订单号、日期格式化都能省很多代码。

后端接口为了统一风格，我习惯建一个Result类作为所有接口的返回体，包括code、msg和data三个字段，静态方法success和fail。前端axios响应拦截器统一处理code非200的情况，弹出错误提示。这样做的好处是前后端联调时不用各管各的格式，所有接口的返回结构一致，排查问题非常轻松。

统一异常处理用@RestControllerAdvice注解加一个@ExceptionHandler，把业务异常（自己定义的BizException）和参数校验异常全量拦截，返回Result格式。这一招在答辩现场演示时特别提气，你输入非法参数系统弹出的不是一大串异常堆栈，而是一句“商品库存不足”，这个细节绝对能让评委眼前一亮。

4.2 JWT登录鉴权与拦截器配置

登录接口：查询用户表，MD5加密（加盐）验证密码——不要用明文比对。验证通过后，生成JWT字符串，把userId和role封装在token里，连同用户昵称一起返回给前端。前端把token存到localStorage，每次请求在axios拦截器加Authorization: Bearer 头。

拦截器类继承HandlerInterceptorAdapter，实现preHandle方法，读取header中的token，用JWT工具类把校验和解析做了。如果token无效或过期，直接向响应流写一段JSON（用Result.fail，让它转json）然后返回false阻断。注册拦截器到WebMvcConfigurer时，需要在excludePathPatterns里放行登录、注册、商品列表、商品详情这些公开接口，否则前端第一次进首页就会被拦截。

JWT有个细节要注意：token过期后不能自动续签，简单方案是设置过期时间为2小时，前端在axios的响应拦截器里检测到401后，清空本地登录态，跳转到登录页。毕设不做“续签”不算缺陷，别在这种边缘功能上钻牛角尖。

4.3 商品列表与搜索接口实现

商品查询是最常用的接口，建议使用MyBatis-Plus的分页能力实现。

@GetMapping("/product/page") public Result productPage(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "12") Integer pageSize, @RequestParam(required = false) Long categoryId, @RequestParam(required = false) String keyword, @RequestParam(required = false) String sort) { Page<Product> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Product::getStatus, 1); if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (StringUtils.hasText(keyword)) { wrapper.like(Product::getProductName, keyword); } if ("sales".equals(sort)) { wrapper.orderByDesc(Product::getSales); } else if ("price_asc".equals(sort)) { wrapper.orderByAsc(Product::getPrice); } else if ("price_desc".equals(sort)) { wrapper.orderByDesc(Product::getPrice); } else { wrapper.orderByDesc(Product::getCreateTime); } return Result.success(productService.page(page, wrapper)); }

几点说明：Page对象会返回total、pages、records等字段，前端可以直接用来渲染分页组件。排序写法我是一个一个if判断，不拼接未过滤条件到字符串，防止注入。keyword字段用like时需要注意，如果keyword为空字符串，不要拼这个条件，所以要用StringUtils.hasText兜底。

4.4 购物车与订单提交核心逻辑

购物车数据表背后其实是一对多的关系，同样的商品加购两次是合并还是叠加？我建议按“同一用户+同一商品只有一条记录，数量累加”来设计，这样的购物车表不会膨胀。加购接口如果商品已存在，则update数量；否则insert。

订单提交是整个系统最核心的接口，我直接给出这段代码框架，它包含了你需要回答“库存扣减”问题的主要逻辑。

@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(Long userId, OrderCreateDTO dto) { // 1. 查询收货地址并校验归属 Address address = addressService.getById(dto.getAddressId()); if (address == null || !address.getUserId().equals(userId)) { throw new BizException("收货地址无效"); } // 2. 根据购物车id列表查询购物车记录 List<Cart> cartList = cartService.listByIds(dto.getCartIds()); // 3. 计算总金额，且逐项校验库存 BigDecimal totalAmount = BigDecimal.ZERO; List<OrderItem> itemList = new ArrayList<>(); for (Cart cart : cartList) { Product product = productService.getById(cart.getProductId()); if (product == null || product.getStatus() != 1) { throw new BizException("商品已下架"); } if (product.getStock() < cart.getQuantity()) { throw new BizException("商品库存不足：" + product.getProductName()); } BigDecimal subtotal = product.getPrice().multiply(BigDecimal.valueOf(cart.getQuantity())); // 4. 组装订单明细快照 OrderItem item = new OrderItem(); item.setProductId(product.getId()); item.setProductName(product.getProductName()); item.setProductImage(product.getMainImage()); item.setPrice(product.getPrice()); item.setQuantity(cart.getQuantity()); item.setSubtotal(subtotal); itemList.add(item); totalAmount = totalAmount.add(subtotal); } // 5. 生成订单主表 Orders order = new Orders(); order.setOrderNo(OrderNoGenerator.generate()); order.setUserId(userId); order.setTotalAmount(totalAmount); order.setReceiverName(address.getReceiverName()); order.setReceiverPhone(address.getReceiverPhone()); order.setReceiverAddress(address.getProvince() + address.getCity() + address.getDistrict() + address.getDetail()); order.setOrderStatus(0); order.setCreateTime(LocalDateTime.now()); ordersService.save(order); // 6. 批量插入订单明细 for (OrderItem item : itemList) { item.setOrderId(order.getId()); } orderItemService.saveBatch(itemList); // 7. 扣减库存 for (Cart cart : cartList) { productService.decreaseStock(cart.getProductId(), cart.getQuantity()); } // 8. 清除购物车 cartService.removeByIds(dto.getCartIds()); // 9. 返回订单id和订单号 return new OrderVO(order.getId(), order.getOrderNo(), totalAmount); }

四个业务动作放在同一个事务方法里，中途任何一步报错都会触发回滚。@Transactional的rollbackFor一定写成Exception.class，否则运行时异常被包装成别的类型，事务不生效，库存直接扣成负数，那是灾难。

这段代码里的decreaseStock方法，对应SQL为：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这里的点睛之笔在于“stock >= quantity”这个条件作为乐观锁替代方案：当库存不足时，受影响行数为0，我们据此判断并抛异常。高并发下，两个请求同时来扣减库存，数据库的行锁会保证只有一个成功，从而防止超卖。这个细节实操性强，写进论文“防止超卖的设计”一节，完全够用。

4.5 图片上传与本地存储映射

商品主图、轮播图和评论图片都要走文件上传接口。SpringBoot接收MultipartFile，把文件存储到本地某个目录（比如D:/upload/），文件名用UUID重命名以提交hash防重复。为了前端能访问，还要在WebMvcConfigurer里配置资源映射：

registry.addResourceHandler("/upload/**") .addResourceLocations("file:D:/upload/");

上传成功后，返回给前端的是相对URL“/upload/xxx.jpg”，前端拼接后端地址即得完整访问路径。这个方案不需要任何第三方依赖，Nginx配置都不用动，毕设演示完全站得住脚。注意控制上传文件大小，默认SpringBoot上传限制是1MB，图片稍微大点就会报错，要在application.yml里设置spring.servlet.multipart.max-file-size=10MB，max-request-size=20MB。

5. 常见问题与排查技巧实录

5.1 前端跨域与接口报错

前后端分离开发最常见的问题就是跨域。浏览器报“Access-Control-Allow-Origin”错误时，不要盲目在接口上加@CrossOrigin，这会让每个Controller都多一个注解，反而散乱。最标准的解法是注册一个CorsFilter全局处理，放行所有来源、所有请求头，允许GET、POST、PUT、DELETE方法。注意如果启用了Spring Security，跨域配置需要放在Security过滤器链之前，否则CORS预检请求仍然会被拦截。但毕设一般没引入Security，这个坑你只需知道即可。

5.2 分页查询返回total为0或数据不更新

分页插件没生效是高频问题，通常发生在忘记配置MybatisPlusInterceptor。另一个低级问题是修改了数据库记录后Page查询没变化，请确认前端请求是否真的传了pageNum=1，很多人默认参数写得不对，一直查的就是第一页数据。

5.3 数据库表字段与实体驼峰映射

MyBatis-Plus默认开启驼峰映射，所以product_name能自动映射到productName。如果你手动写了XML里的SQL，返回结果时一定检查resultMap或给列起别名。否则查出来一堆null字段，前端页面全空，排查到深夜。

5.4 订单超时未支付状态处理

毕设一般不做定时任务扫单，最简单的方式是买家或管理员在查看订单列表时，如果发现订单状态为0且创建时间超过30分钟，就把它改成“已取消”。这个“懒处理”方案避免引入XXL-Job或Spring Task，应付演示是够的。如果导师追问“真实电商怎么处理”，可以回答用消息队列延迟消息或定时任务扫单，你只是从简设计。

5.5 数据库连接配置中的时区问题

MySQL 8.0以上，在jdbc连接串里必须配置serverTimezone=Asia/Shanghai，否则使用中国时区的日期会偏8小时。URL里同时建议加characterEncoding=utf8&useSSL=false。我把这一段放在“常见问题”里，是因为几乎每届都有同学栽在这里，启动报时区异常直接懵掉。

5.6 事务注解失效

这个必须单独列一条。你有没有遇到过订单重复提交？排查方向之一就是看事务是否真正生效。需要注意：

• @Transactional注解加在private方法上时不会生效，只能加在public方法上
• 同类内部调用this.createOrder()不会走代理，事务也失效，必须从Controller层调Service，或者注入自身代理
• 时机：catch了异常后不往外抛，事务无法感知错误，同样不会回滚
• 保证：MySQL的InnoDB引擎才支持事务，检查建表语句是否为ENGINE=InnoDB

5.7 接口参数校验不可缺失

前端Vue可以挡掉大部分非法输入，但接口本身必须再加一道校验。在DTO字段上加@NotBlank、@NotNull、@Min(1)等注解，并在Controller参数前加@Validated。参数校验失败时，全局异常处理器会统一返回校验提示。这样做的优点是后端独立可测，安全性也提升一个档次，而且改动量极小——只是在几个字段上加注解而已。

6. 答辩准备与演示要点

6.1 功能演示脚本制定

答辩演示的时候最忌讳东点一下西点一下。提前准备一条完整的主线脚本：登录（演示JWT生效）→首页浏览（演示分类导航+搜索）→商品详情→加入购物车→下单（演示库存变化）→模拟支付→管理员发货→用户确认收货→评价。这条链路一气呵成，评委能清晰看到完整的业务闭环。

演示过程中注意把鼠标移动到订单号、商品价格等关键数据上，边演示边解释“订单状态是待付款”“库存从20变为19”，这种细节能让评委确信这是你自己做出来的项目。

6.2 评委常见提问应对

• 为什么选择SpringBoot而不选SSH？回答：SpringBoot简化配置、内嵌容器、生态成熟，是目前企业级开发的主流；SSH已经过时且配置繁琐。
• 库存扣减如何防止超卖？回答：SQL里加了stock >= quantity的条件更新，依赖数据库行锁保证原子性。
• 密码如何存储？回答：MD5（加盐）哈希存储，不存明文；登录时先查用户，再用盐做哈希比对。
• 订单号如何生成？回答：用时间戳+随机数+用户ID后四位拼接，保证唯一性。如果有更高并发场景，可以用雪花算法，但单机毕设不需要。
• 如果用户下单后一直不支付，怎么处理？回答：当前平台采用查看时懒取消；在生产环境会使用延迟任务扫单关闭超过30分钟的未支付订单。

6.3 值得写进论文的亮点小节

如果能提前在代码里埋好下面这些“亮点”，论文的深度会明显提升。我建议每一段都结合代码截图和运行效果展开：

• 统一返回体 + 全局异常处理的设计思路
• JWT鉴权在前端路由和后端拦截器的双重防护
• 订单快照（冗余存储）与数据一致性保证
• 乐观锁在库存扣减上的实现细节
• MyBatis-Plus分页插件配置与物理分页机制
• 地址簿在下单时的快照复制逻辑

每个亮点不需要长篇大论，能讲清楚“为什么这么设计”和“代码在哪里”即可，这样的论文查重率也不会太高。

7. 经验总结与后续扩展思路

项目跑通的那一刻，你先别急着交差。我建议你再看三个扩展方向，根据自己的时间挑一两个消化掉，毕设的深度会完全不一样。第一个是引入Redis缓存商品详情和首页推荐位，热点数据的QPS提升特别明显，代码改动也不大。第二个是把本地图片上传改为MinIO对象存储，趁毕设体验一把完整的上传链路，这个知识面试时能讲出东西。第三个是给订单模块增加一个定时关单功能，用Spring提供的@Scheduled注解，一分钟扫一次超时未付款的订单，就能彻底替代上面的“懒处理”方案。

还有一个容易被人忽略但很重要的点：代码注释。毕业设计答辩时，评委可能随时让你解释某段代码。如果项目里所有的方法名和核心逻辑都有清晰的中文注释，现场翻代码时你会轻松得多。我习惯在每个Service实现类的方法上写三五行注释，说明这个方法做了哪几件事，顺手把关键业务规则也写上去。这不是为了给谁看，而是为了半个月后的自己没有陌生感。

最后再分享一个做项目的心态：毕设项目不是生产项目，不需要你追求极致的性能和优雅的架构。但每一个功能都要能跑通、说清楚、经得起追问。很多同学到后期发现问题太多，都是因为前期需求梳理偷懒，拿到什么功能就埋头做，做到一半发现数据模型对不上，推倒重来。你花两天时间把表结构和流程图画清楚，后面写代码的速度会快一倍。这个平台做完，你收获的不只是一个学分，更是一套“从0设计一个业务系统”的完整经验，这在实习和校招面试里，比任何刷题记录都更能证明你的工程能力。