前阵子帮学弟把他的毕业设计从需求分析一直跟到部署上线项目就是标题里这个很经典的基于SpringBoot的贵州农产品销售平台。这类题目在计算机毕设里属于常青树——电商系统、区域性特产、Java技术栈几乎每年都有人选。我做完这轮梳理之后最大的感受是这套东西的难点根本不在代码量而在于你怎么把电商平台该有的功能和贵州本地农产品的真实需求结合起来做出一个既完整又有亮点的系统。如果你正在做或者准备做类似的题目这篇文章从架构设计、数据库表设计、核心功能实现到答辩准备都会讲到照着走能省不少事。这个项目本质上是一个B2C/B2B混合的在线农产品交易系统。它解决的问题很直白贵州本地的优质农产品比如遵义辣椒、都匀毛尖、修文猕猴桃这些过去主要靠线下批发和本地集市销售渠道窄、中间环节多、品牌溢价低。做一个线上销售平台把农户、合作社、采购商和普通消费者拉到一个平台上缩短流通链条让产地信息透明化这就是项目的核心价值。对毕设来说它覆盖了用户注册登录、商品展示、购物车、订单管理、支付对接、后台管理等电商系统的完整闭环非常适合用来展示你对SpringBoot生态的掌握程度。下面我把整个项目从设计到实现的关键环节拆开讲包括我实际踩过的坑和调整过的方案。1. 项目定位与整体设计思路1.1 为什么选SpringBoot做毕设电商项目很多人在开题时会纠结用SSHSpringMVC Spring Hibernate老一套还是直接用SpringBoot我的建议非常明确直接选SpringBoot。理由有三点。第一SpringBoot大大降低了配置成本。传统SSH项目要写大量XML配置文件数据源、事务、视图解析器、拦截器每一项都要手工配置光是搭环境就要折腾一周。SpringBoot通过自动配置和Starter机制一个启动类加几个依赖就能把项目跑起来省下来的时间完全可以投入到业务功能开发上。对于毕设周期通常3到4个月来说这非常重要。第二SpringBoot是当前Java后端开发的事实标准。企业里新项目基本都用SpringBoot/SpringCloud这套体系你在毕设里用SpringBoot答辩时被问到的概率低面试时也能直接讲这个项目经历一举两得。第三SpringBoot内嵌Tomcat部署非常方便。打成jar包直接扔到服务器上就能运行不用单独装Tomcat、配环境变量。后面我会详细说部署过程这是能把工作量压缩到一天内的关键。1.2 贵州农产品电商的业务痛点决定了功能设计做电商系统不能光想着别人有什么我也要有什么得先想清楚这个农产品平台和普通电商平台的区别在哪里。我这里总结了四个直接影响功能设计的痛点。一是产地分散、标准化程度低。贵州地形复杂农产品产区分散同一个县可能同时有茶叶、辣椒、中药材但规模都不大。所以平台必须给商品加上清晰的产地标签和分类体系让用户能按地区、按品类筛选这直接决定商品表的设计。二是保鲜期短、物流要求高。很多农产品蔬菜、水果、鲜笋对配送时效要求很高平台需要区分可长途运输和仅限本地配送的商品类型。我在订单模块里设计了配送区域校验超出配送范围的商品会提示用户无法下单这个细节答辩时很加分。三是价格波动大。农产品价格随季节和产量波动明显后台管理系统需要支持快速改价和批量调整库存而不是每改一次价格都要走一遍商品上架流程。四是信任问题。农产品是入口的东西用户很在意来源是否可靠。平台需要农户/合作社实名认证、商品溯源信息展示和评价体系让消费者看到谁卖的从哪来的这比单纯拼价格更有说服力。1.3 三类角色与功能骨架系统一共设计了三类角色买家和卖家是两个前台角色管理员是后台角色。买家端功能注册登录、浏览商品、按分类/产地/关键词检索、加入购物车、提交订单、在线支付集成模拟支付或支付宝沙箱、查看订单状态、确认收货、发表评价、管理收货地址。卖家端功能店铺入驻申请、商品发布与管理上架、下架、改价、改库存、订单处理发货、查看买家留言、销售数据查看。管理员端功能用户管理、卖家入驻审核、商品分类管理、商品审核与上下架控制、订单管理、数据统计面板销售趋势、热销商品、用户增长。这三类角色通过Spring Security或拦截器加JWT进行权限控制。功能划分清晰以后数据库表结构、接口设计、前端页面都会跟着清晰起来这是整个项目最重要的一步一定不要跳过。2. 技术选型与架构方案2.1 核心技术栈选型对比毕设技术选型有一个原则在主流和能力范围内之间找平衡。我列一张对比表方便你直接照着选。模块推荐方案备选方案推荐理由后端框架SpringBoot 2.7.xSpringBoot 3.x2.7资料多、兼容性好3.x要求JDK17部分老教程不适用ORM框架MyBatis-PlusMyBatis / JPAMyBatis-Plus提供BaseMapper和QueryWrapper单表CRUD零SQL效率极高数据库MySQL 8.xMySQL 5.78.x支持window函数、JSON类型性能更好缓存Redis可选无做首页轮播图缓存、验证码存储时很有用但非必需前端Vue2 Element UIThymeleaf模板引擎前后端分离是主流Element UI组件成熟适合后台管理页面鉴权方案JWTSessionJWT无状态、前后端分离友好支付支付宝沙箱模拟支付本地写死成功回调支付宝沙箱有完整文档答辩效果好这里我想特别说一下前后端分离的问题。很多毕设为了省事直接用SpringBoot Thymeleaf做服务端渲染所有页面由后端控制跳转。这么做确实简单但你答辩时会很吃亏因为现在企业里主流做法就是前后端分离。我用的是Vue2 Element UI搭建前端页面后端只提供JSON接口通过axios调用。工作量会比Thymeleaf方案大一些但代码结构清晰得多而且这个经验面试时能直接讲。2.2 系统架构与工程结构整个系统按前后端分离的单体应用架构来搭。所谓单体架构就是把所有功能模块放在一个SpringBoot工程里通过包结构区分层次而不是拆成多个微服务。毕设阶段千万不要上微服务那会把你拖进服务注册、配置中心、分布式事务的泥潭一个毕设做不完。后端工程推荐按下面这个结构组织com.example.guizhouagro ├── common // 通用工具类、统一返回结果、异常处理 ├── config // 配置类跨域、拦截器、上传路径等 ├── controller // 接口层 ├── service // 业务逻辑层 ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 数据传输对象接收前端参数 ├── vo // 视图对象返回前端数据 └── utils // JWT工具、MD5加密工具等这种分包方式对应经典的三层架构Controller接收请求、校验参数Service处理业务逻辑、管理事务Mapper操作数据库。注意一个原则Controller里不要写业务逻辑Service层不要直接操作HttpServletRequest。层与层之间职责清晰答辩画架构图、讲数据流的时候非常顺畅。2.3 环境准备与初始化环境这块我用的是大家最常见的组合JDK 1.8、Maven 3.8.x、MySQL 8.0、Node.js 14前端用。IDEA社区版或者专业版都行。创建SpringBoot项目有两种方式去Spring官方Initializr生成骨架或者用IDEA自带的Spring Initializr。选好Java版本和依赖web、mysql、mybatis-plus、lombok、jwt、validation后等待Maven下载依赖就行。这里给一个容易踩坑的提示Maven仓库地址建议改成阿里云镜像否则下载依赖时网络不稳定会一直报错把settings.xml里的mirror配置好能省一晚上的时间。依赖下载完成后先做一件事写一个最简单的Controller返回一个Hello字符串跑通启动类。很多同学一上来就写大功能结果环境没跑通报错时根本分不清是代码问题还是环境问题。先跑通最小的闭环后面所有问题都有参照系。3. 数据库设计与核心功能实现3.1 核心表结构设计数据库是电商系统的地基。我开始设计的时候反复改了三次最后沉淀下来的核心表有9张这里重点讲5张最关键的。商品表goods字段设计字段名类型说明idbigint主键goods_namevarchar(100)商品名称goods_desctext商品详情描述pricedecimal(10,2)单价stockint库存数量category_idbigint商品分类IDorigin_placevarchar(50)产地如遵义-虾子镇area_tagvarchar(20)地区标签如黔北黔东南season_tagvarchar(20)季节标签如春季应季image_urlvarchar(255)商品主图statustinyint0下架 1上架 2待审核salesint销量versionint乐观锁版本号create_timedatetime创建时间订单表orders字段设计订单号、用户ID、总金额、订单状态0待付款、1待发货、2待收货、3已完成、4已取消、收货人姓名、电话、地址、下单时间、支付时间、发货时间。这里注意订单号不要用自增ID建议用时间戳加随机数的组合比如20250101120000001方便查询和展示。订单项表order_item字段设计订单ID、商品ID、商品名称快照、商品单价快照、购买数量、小计金额。快照字段很重要因为商品价格会变动订单生成后必须保留当时的价格信息不能直接关联商品表。购物车表cart_item和收货地址表address相对简单核心字段就是用户ID、商品ID、数量以及用户ID、收货人、联系电话、省市区、详细地址、是否默认地址。最后是用户表user角色用role字段区分0普通用户、1卖家、2管理员。商户入驻审核信息可以单独建一张seller_apply表记录申请人的真实姓名、身份证号、店铺名称、所属地区、审核状态。3.2 商品检索与分类展示商品展示是用户接触平台的第一界面做得好不好直接影响使用体验。我做了三个维度的检索关键词搜索like匹配商品名称和描述、分类筛选按茶叶、水果、蔬菜等大类、产地/地域筛选按遵义、贵阳、黔东南等地区。MyBatis-Plus的QueryWrapper可以非常方便地完成动态条件拼接不需要手写大量动态SQL。核心代码如下public PageGoods queryGoodsPage(int pageNum, int pageSize, GoodsQueryDTO dto) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); // 关键词搜索 if (StringUtils.hasText(dto.getKeyword())) { wrapper.and(w - w.like(Goods::getGoodsName, dto.getKeyword()) .or().like(Goods::getGoodsDesc, dto.getKeyword())); } // 分类筛选 if (dto.getCategoryId() ! null) { wrapper.eq(Goods::getCategoryId, dto.getCategoryId()); } // 产地筛选 if (StringUtils.hasText(dto.getOriginPlace())) { wrapper.like(Goods::getOriginPlace, dto.getOriginPlace()); } // 只查上架商品 wrapper.eq(Goods::getStatus, 1); // 排序默认按销量排序也可以按价格或时间 wrapper.orderByDesc(Goods::getSales); return goodsMapper.selectPage(new Page(pageNum, pageSize), wrapper); }LambdaQueryWrapper的好处是编译期就能检查字段名是否正确不会出现手写字符串拼错导致运行时才报错的问题。分页直接交给MyBatis-Plus的Page对象前端传pageNum和pageSize返回的数据里带上total总数前端就能做分页组件了。3.3 购物车与订单核心流程购物车和订单是电商系统里逻辑最密集的部分。购物车接口相对简单加入购物车用户未登录则提示先登录、查看购物车列表、修改数量、删除购物车项、清空购物车。订单流程是重头戏我按状态机的方式实现每个状态有明确的操作入口状态含义可执行操作0待付款用户取消订单、去支付1待发货用户申请退款、卖家发货2待收货用户确认收货、查看物流3已完成用户评价、申请售后4已取消无提交订单的事务逻辑是毕设答辩必问的点。我这里用Transactional保证一组数据库操作要么全部成功要么全部回滚Transactional(rollbackFor Exception.class) public OrderVO submitOrder(SubmitOrderDTO dto) { // 1. 校验收货地址 Address address addressMapper.selectById(dto.getAddressId()); if (address null || !address.getUserId().equals(currentUserId())) { throw new BizException(收货地址不存在); } // 2. 生成订单主记录 Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(currentUserId()); order.setTotalAmount(calcTotalAmount(dto.getItems())); order.setStatus(0); // 3. 生成订单项快照 ListOrderItem items buildOrderItems(dto.getItems()); // 4. 扣减库存关键逻辑见3.4 // 5. 清空购物车对应商品 // 6. 保存所有记录 orderMapper.insert(order); items.forEach(item - { item.setOrderId(order.getId()); orderItemMapper.insert(item); }); return buildOrderVO(order, items); }这里有个细节需要注意Transactional要放在public方法上且不能通过this调用要通过注入的Service对象调用否则事务不生效。很多同学把事务注解写在Controller上或者同类内部调用结果数据库操作执行到一半报错却不会回滚这是生产环境容易埋雷、答辩很容易被问到的地方。3.4 库存扣减与超时关单库存扣减是电商系统的经典问题。简单写法是先查库存判断是否足够再update这个写法在高并发下有超卖风险。毕设虽然不会有高并发压测但答辩老师一定会问你怎么解决并发情况下的超卖问题。推荐方案是乐观锁在SQL层面做条件校验UPDATE goods SET stock stock - #{count}, version version 1 WHERE id #{goodsId} AND stock #{count}利用MySQL行锁机制stock count这个条件保证不会扣成负数。如果影响行数为0说明库存不足直接返回库存不足提示用户。这个方案简单、可靠、不需要引入分布式锁面试和答辩都够用了。超时关单的问题也要考虑。用户提交订单后如果一直不付款订单不能永远挂着。我用Redis的过期键来做提交订单时把orderNo写入Redis设置30分钟过期。用一个定时任务或者Redis键过期回调把超时未支付的订单状态改为已取消同时回补库存。这里有一个很实用的经验如果你不想引入Redis也可以在订单表里加一个expire_time字段用Spring的Scheduled定时扫描每30秒扫一次待付款且已过期的订单批量取消。两种方案各有优劣Redis方案实时性好、代码更优雅纯数据库方案依赖少、适合零基础。你根据自己的掌握程度选一种就行答辩时能把原理讲清楚就合格了。4. 后台管理与贵州地域特色功能4.1 后台管理模块设计后台管理界面用Vue2 Element UI实现左侧菜单、右侧内容区的经典布局。管理模块按功能拆分成几个独立页面用户管理、商品管理、分类管理、订单管理、数据统计、入驻审核。商品管理这个页面应该细看。管理员能看到所有卖家的商品支持按状态筛选待审核、已上架、已下架点击审核按钮可以选择通过或驳回驳回时填写原因系统自动通知卖家。这里后台审核机制是我后期加上的因为这能体现你对农产品质量安全的思考——不是谁发布什么都能直接展示得有审核环节。数据统计页面用ECharts画图。我做了三个图近7天销售额折线图、商品分类销售占比饼图、热销商品TOP10柱状图。对应的SQL需要用到聚合查询和日期分组。比如近7天销售额这个图SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM orders WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND status IN (1, 2, 3) GROUP BY DATE(create_time) ORDER BY day统计页的作用不只是展示你答辩时可以直接指着折线图说平台上线后某地区特产销量持续增长用数据支撑你的系统设计合理性这比空口介绍功能有说服力得多。4.2 贵州农产品特色功能怎么做出亮点选贵州农产品这个主题如果功能做成跟淘宝一模一样就浪费了这个选题的价值。我建议加三个体现地域特色的功能点工作量不大但答辩时长脸。一是产地标签和地域主页。商品除了有分类还带产地标签比如毕节-威宁黔南-荔波。平台首页做一个贵州产地地图区块用户点击某个地区就进入该地区的商品列表页。数据实现其实很简单就是按area_tag和origin_place字段筛选但对用户来说体感完全不一样——好像在逛一个线上贵州农产品集市。二是应季农产品推荐。做一个当季鲜味模块根据当前月份推荐应季农产品。9月推荐修文猕猴桃4月推荐春茶这个功能可以在后端写一个简单的逻辑根据当前月份从season_tag字段匹配商品。注意前端不要写死时间用后端接口动态返回这样以后维护起来方便。三是配送区域校验。生鲜类商品不是全国都能发的。商品表里有一个配送区域字段我设计成多选全国配送/仅省内配送/仅本地配送。下单时后端做校验超出配送范围直接拦截下单并提示用户该商品暂不支持配送至所选地区。这个设计很接地气说明你真的考虑过农产品电商和普通电商的区别。4.3 文件上传与图片处理农产品很吃外观图片展示质量直接影响购买意愿。图片上传这块我用本地存储方案接口接收MultipartFile保存到服务器的指定目录同时把访问路径存到数据库。这里有两个关键配置。一是把上传目录设置成绝对路径比如D:/upload或者/usr/local/agro/images不要用相对路径因为jar包启动后的当前目录经常和你预期的不一样。二是需要配置虚拟路径映射让SpringBoot把http://localhost:8080/images/xxx.jpg映射到本地磁盘目录Configuration public class WebMvcConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceHandler(file: uploadPath /); } }图片不是越大越好。我建议后端做一个压缩处理用Thumbnator工具把上传的图片统一压缩到宽度不超过800px质量0.8。压缩后图片一般50KB到200KB页面加载速度快很多用户看详情页体验也好。不做压缩的话手机拍的图一张4MB前端加载卡成幻灯片体验分直接扣光。5. 实操过程与核心环节实现5.1 登录鉴权从Session到JWT后端登录鉴权我推荐JWT方案它是无状态的前后端分离项目里非常流行。核心思路是用户登录成功后后端生成一个token返回给前端前端把它存到localStorage里每次请求在请求头带上Authorization: Bearer 后端通过拦截器解析token识别用户身份。JWT生成代码大致是这样的public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(new Date()) // token有效期我设置为24小时 .setExpiration(new Date(System.currentTimeMillis() 86400000L)) .signWith(secretKey, SignatureAlgorithm.HS256) .compact(); }拦截器的任务放行登录接口、注册接口、商品列表接口等公开接口校验必须登录的接口下单、购物车校验管理员接口后台管理。我有一个建议写一个自定义注解RequireRole(admin)标在需要权限的Controller方法上拦截器里解析注解做权限判断比硬编码URL更优雅也更好扩展。这里提醒一个坑拦截器里解析完token之后把userId放进Request Attribute里后续Controller和Service从request中获取当前用户不要每次都重新解析token。否则你的代码会到处重复解析逻辑而且Service层拿不到用户ID会很别扭。5.2 支付宝沙箱支付对接支付功能是电商项目的加分区。我建议直接对接支付宝沙箱环境不需要真实商户资质用支付宝开放平台的沙箱账号就能测试完整流程。申请沙箱流程不细说了重点说一下核心对接步骤。引入支付宝SDK依赖之后配置文件中要写appId、支付宝网关地址沙箱环境是openapi.alipaydev.com、应用私钥、支付宝公钥。下单时后端调用alipay.trade.page.pay接口生成支付表单返回给前端前端把表单渲染出来跳转到支付宝收银台页面。支付成功后的回调是这个环节的关键。支付宝会发送一个异步通知到你的回调接口notify_url你需要做三件事验签防止伪造通知、校验订单总金额与appId、更新订单状态为待发货。一定要用异步通知更新订单状态不要依赖前端跳转同步页面因为用户可能支付完成后直接关掉浏览器。沙箱环境有一个很实用的技巧支付宝沙箱APP是独立的客户端里面有很多测试买家账号和测试商家账号每个账号预充了金额。调试回调接口时可以同时打开后端日志直接看到验签、业务处理、返回success的全过程。第一次跑通的成就感还是很强的。5.3 前端页面开发与接口联调前端用Vue2 Element UI axios Vue Router Vuex。页面大概有这些首页、商品列表页、商品详情页、购物车页、订单确认页、支付页、个人中心订单列表、收货地址管理、卖家后台商品管理、订单管理、管理员后台。联调时推荐用axios的拦截器统一处理token注入和响应错误码。响应格式统一用{code: 200, message: success, data: {...}}这样前端处理逻辑非常统一。我专门在公司项目里被这种问题坑过——后端返回数据格式五花八门前端每个页面都得单独处理错误非常折磨。5.4 项目打包与服务器部署整个项目跑通后就可以打包部署了。后端在IDEA里用Maven执行package命令生成jar包。部署时用nohup命令后台启动nohup java -jar agro-platform.jar --server.port8080 agro.log 21 前端在项目目录执行npm run build生成dist目录用Nginx托管静态文件。Nginx需要配置两个关键点静态文件代理和API反向代理。所有/api开头的请求转发到后端8080端口location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }部署顺序建议先在本地Windows跑通全流程再上Linux服务器。我第一次在Linux部署时遇到一个典型的坑jar包启动成功但外部访问不到排查半天发现是云服务器的安全组没开放端口。这个坑在本地不会出现但一上服务器就必踩提前有个心理准备。6. 常见问题与排查技巧实录6.1 环境与启动类问题问题原因分析解决方案Maven依赖下载失败默认中央仓库访问慢settings.xml配阿里云镜像端口被占用之前启动的服务没关换端口或在任务管理器杀掉Java进程MySQL连接报Access denied密码错误或root账号不允许远程确认密码创建指定用户并授权启动报NoActiveProfile没有配置环境检查application.yml的名字和位置前端npm install报错网络问题或node版本不兼容配置淘宝镜像源升级node到14以上这类问题的核心排查方法是从日志里找线索不要东一下西一下乱试。SpringBoot启动日志非常详细仔细读最后几行一般都能定位到问题。6.2 业务代码的典型坑第一个坑循环依赖。ServiceA注入ServiceBServiceB又注入ServiceASpring启动时直接报错。解决办法是重新设计业务边界把公共逻辑抽到第三个Service中或者用Lazy懒加载临时处理。做毕设时老老实实设计好依赖方向别图省事互相注入。第二个坑JSON序列化循环引用。商品实体里关联了分类实体分类实体里又关联了商品列表返回给前端时Jackson会无限递归。解决办法是在关联字段上用JsonIgnoreProperties注解忽略反向引用。这个坑在第一次写分类下面有哪些商品的接口时必踩提前加注解能省一小时。第三个坑updateById把字段更新成null。MyBatis-Plus的updateById默认只更新非空字段这本是好事但如果你真的想把某个字段置为null比如清空商品描述你会发现怎么都更新不进去。这是MyBatis-Plus的默认策略导致的用UpdateWrapper的set方法显式指定字段更新即可。6.3 答辩常见问题与回答思路答辩老师围绕这个项目大概率会问这几个问题我提前给你打一版回答思路。为什么选SpringBoot而不是SSH——回答方向SpringBoot基于约定优于配置思想内嵌Web容器、简化依赖管理、提供自动配置机制大幅提升开发效率适合快速交付业务项目。可以再补一句SpringBoot只是脚手架底层依然是Spring的IOC和AOP核心原理没有变。商品表里的version字段是做什么的——回答方向用于乐观锁解决并发扣减库存时的超卖问题。update时通过stock count和version版本号做原子校验影响行数为0说明库存不足。这说明你考虑过并发场景的数据一致性。订单超时未支付怎么处理——回答方向两种方案。Redis过期键加监听或者定时任务扫描过期订单。无论选哪种都要说明关单之后要恢复库存。系统的安全性怎么考虑——回答方向用户密码MD5加盐加密、JWT token鉴权、管理员接口做角色校验、SQL采用参数化查询防止注入、前端做输入校验和后端二次校验。这五个问题每一个都要能展开讲三到五分钟语言组织清楚。你可以提前写一份答辩稿把核心名词乐观锁、JWT、事务回滚提前准备好临场就不会慌。6.4 时间规划建议最后说点实在的。毕设项目最常见的翻车原因就是前面磨蹭太久后面赶工。我建议按这个节奏推进前两周搞定需求分析、数据库设计和原型图第三周到第六周完成后端全部接口第七周到第八周完成后端管理功能和页面联调第九周部署上线加测试最后两周写论文做PPT准备答辩。每周末做一次进度检查这一周完成的功能能不能跑通数据库表有没有要改的接口文档是不是最新的我见过太多人数据库表改了四五次代码里写死的字段名和数据库对不上最后改得昏天黑地。前两周把数据库设计想清楚后面能省一半功夫。做项目的过程也是一种学习。这个农产品销售平台麻雀虽小五脏俱全电商的核心链路都能覆盖到。你认真做完一遍SpringBoot、MyBatis-Plus、事务、JWT、缓存、部署这些东西就都串起来了。答辩的时候能自信地说这是我写的系统每个功能我都亲手调试过分数自然不会差。这个项目如果想继续扩展可以在现有代码基础上加一个小程序端或者对接微信支付再或者增加一个订单物流轨迹功能。路是走出来的先把主体的闭环跑稳再想加法。祝你的毕设顺利落地。