南瓜丶奇迹师不少学弟学妹在选题阶段都会盯着基于Spring Boot的农产品销售小程序这种题目，觉得有Spring Boot、有小程序、有商城，技术栈够主流，工作量也适中。但真正拿到手之后，很多人第一反应是不知道从哪里下手：论文怎么写、PPT怎么搭、源代码交付到什么程度、演示视频录什么内容，更别说后端和小程序联调时遇到的一堆奇怪问题。这篇内容我就结合带毕设和实际开发的经验，把这个题目从需求分析、技术架构、代码落地，到论文、PPT、演示视频、答辩，整个链路捋一遍。目标很直接：让你拿到题目后能按图索骥，少熬夜，少踩坑，顺顺利利把毕设交上去。
1. 拿到这个毕设题，第一件事不是写代码，而是拆需求
很多人一看到题目里有"Spring Boot"和"小程序"，就急着去搭环境、复制商城demo，结果项目跑起来了，论文却憋不出来。实际上毕设题目背后真正考核的是你"能不能围绕一个具体业务做完整的系统设计与实现"，代码只是其中一部分。农产品销售小程序，重点不是"商城"，而是"农产品"这个业务域。
1.1 农产品销售小程序的真实业务场景
农产品和小商品商城最大的区别在于商品属性差异大：有按斤卖的蔬菜、按箱卖的水果、按份卖的土鸡蛋，还有预售的时令产品。用户端需要能按分类浏览、搜索、查看产地和规格；农户端需要上架商品、管理库存、处理订单；平台管理员需要审核商品、管理用户、查看销售统计。这些场景不是普通商城模板能直接套用的。
所以拿到题目后，先画业务流程图。简单说就是三类角色：消费者、农户（商家）、管理员。消费者从首页进入小程序，看推荐、逛分类、加入购物车、下单付款、查看订单状态；农户在小程序内或后台管理端完成商品发布、库存修改、订单发货；管理员在后台做数据看板、商品审核、用户管理。把这三个角色的操作路径画出来，你后面的数据库设计和接口设计就清晰了。
1.2 从题目关键词反推技术选型
题目已经非常明确：后端用Spring Boot，前端用小程序。朋友圈里常见的做法是后端Spring Boot + MyBatis-Plus + MySQL，小程序端用微信官方原生框架，或者用uniapp实现跨端打包。如果你想省事，选原生小程序就行，毕竟只需要跑微信端。但如果你未来想同时上支付宝小程序，或者你已经熟悉Vue，那uniapp会更顺手。
这里我多说一句：Spring Boot版本尽量选稳定版，比如2.7.x或3.x中的某个小版本，不要一上来就追最新的4.x。有些教程用的版本太高，第三方依赖跟不上，会出现Jakarta命名空间变化、配置类变更，反而给自己挖坑。
数据库选MySQL，ORM用MyBatis-Plus，这个组合在毕设圈子里几乎成了标配。原因很简单：MyBatis-Plus提供代码生成器，根据表结构一键生成实体、Mapper、Service、Controller，省下大量模板代码，而且它的分页插件写起来也非常直接。如果你的论文里需要体现"技术选型分析"，就用这一套，答辩老师基本不会挑毛病。
另一个容易忽略的是接口文档。前后端分离开发时，小程序同学和后端同学（其实都是你）之间最容易出现字段名对不上、返回结构不统一的问题。建议用SpringDoc或者Knife4j生成OpenAPI接口文档，小程序端调试时直接看Swagger地址，比在代码里翻Controller快得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端Spring Boot怎么搭？四层架构和核心模块设计
Spring Boot项目的代码结构是有讲究的。2025年了，网上随便搜"Spring Boot四层架构"，答案基本都是Controller、Service、Mapper、实体。但我想提醒你，论文里写四层架构没问题，代码里却不能只建四个包糊弄。
2.1 四层架构在代码里到底怎么落
我见过不少学生项目：Controller里写了一大堆业务SQL，Service层空壳，Mapper全是动态SQL，实体类字段跟数据库字段完全对应。这种代码跑起来没事，但是答辩老师一看就知道你不太会分层。
常规做法是：
controller：只做参数接收、返回统一结果封装、异常处理。service：写业务逻辑，比如下单时扣库存、订单超时自动取消、统计报表计算。mapper：只做数据库访问，避免业务判断写在SQL里。entity：数据库映射对象。dto/vo：接收前端参数和返回前端数据的对象，这个很多人会漏。
举个例子，用户下单时，前端传一个OrderCreateDTO，包含商品ID列表、数量、收货地址ID、备注。Controller先做参数校验，然后调OrderService.createOrder(dto)。Service内部需要验证用户信息、查商品价格、计算总金额、生成订单号、扣减库存、创建订单主表和明细表，最后返回OrderVO给前端。这一套逻辑拆到对应层，代码可读性和维护性完全不一样。
2.2 数据库表设计与核心关系
农产品销售系统建议至少设计这些表：用户表、农户表（或者商家表，也可以合并成角色区分）、商品分类表、商品表、购物车表、订单主表、订单明细表、收货地址表、公告表或轮播图表、管理员表。
我挑几个关键点说。商品表里除了常规的name、price、stock，一定得加unit（单位，比如斤/箱/份）、origin（产地）、status（上架/下架/审核中）这几个字段。农产品价格波动快，还要加一个update_time，方便做"最近更新"排序。
订单主表和明细表必须分开。一个订单包含多个商品时，如果都塞在主表的一个字段里，后面统计销售额、对账、退款都非常痛苦。订单状态可以用0待支付、1已支付待发货、2已发货、3已收货、4已完成、5已取消，这个数字字典要写进论文数据字典。
购物车表建议用"用户ID + 商品ID + 数量 + 选中状态"，别用JSON字段存一堆商品。数据库设计的核心是第三范式，但是为了性能可以适当冗余，比如在订单明细里冗余一个商品快照名称和价格，防止商品删除后订单里查不到历史信息。
2.3 接口设计：小程序端需要什么样的数据
小程序端和后端交互的接口分成两类：公开接口和需要登录的接口。公开接口包括：首页轮播图、商品分类列表、商品列表（分页）、商品详情、搜索。登录后的接口包括：获取微信用户信息（通过wx.login拿code换openid）、购物车增删改查、订单创建、订单列表、订单详情、修改收货地址、个人中心信息。
返回格式强烈建议统一。我会在项目里写一个R<T>类，包含code、message、data三个字段。比如R.success(data)和R.error("商品库存不足")。小程序端只要封装一个request.js，对code做统一判断，弹提示、跳登录页，就都处理了。这个东西看起来简单，但很多新手项目都是每个接口返回格式各写各的，前端拿到数据后还得猜，联调效率极低。
接口路径的命名也尽量规范，比如用/api/order/create、/api/cart/list，别用/order/addOrder这种。好的接口命名不仅是给小程序用的，更是给论文里的"系统设计"章节增光添彩的。
3. 小程序端开发：页面逻辑和联调避坑
小程序端是整个项目里最容易出"看起来简单但做起来烦"问题的部分。页面数量不多，但牵扯微信登录、分页、下拉刷新、购物车计算、支付（如果接）等交互，每个点都值得单独打磨。
3.1 用原生小程序还是uniapp
我的建议是，如果只是单平台交付，原生小程序就够了。WXML、WXSS、JS、JSON四件套不难，官方文档也齐全。如果你已经会Vue，用uniapp也行，它的组件体系和Vue接近，还能HBuilderX一键运行到微信开发者工具。但要注意，uniapp引入了编译层，遇到原生组件、第三方SDK时反而要多一层调试。
我实测下来，原生小程序在真机预览的稳定性更好，分包加载和性能优化也更直接。对于毕设演示，原生小程序完全能满足。我在代码里用的是原生语法，配了weui样式库，页面看起来干净，不用自己写一堆按钮和表单样式。
3.2 核心页面从零到能用的关键细节
首页：顶部搜索框，下面放轮播图，然后是分类导航（蔬菜、水果、禽蛋、粮油干货等），再往下是"今日推荐"商品列表。数据来源就是后端的公开接口。我建议用onPullDownRefresh实现下拉刷新，用户更换推荐商品时会比较直观。
商品列表页：需要考虑分页加载。用onReachBottom触底加载下一页，每次请求传current和size，后端返回total。记得用一个isLoading标志防止重复请求。页面里商品的图片用懒加载lazy-load，避免一次加载过多图片导致卡顿。
商品详情页：除了展示轮播图、价格、库存、产地，还要有"加入购物车"和"立即购买"两个按钮。加入购物车调POST /api/cart/add，立即购买直接跳到确认订单页并把商品信息通过Storage传递。注意这里要处理"用户未登录但点了购买"的情况，跳转到登录授权页。
购物车页：这是最容易出逻辑问题的页面。每件商品前面的复选框选中状态、全选、总价计算、批量删除、数量增减，这些状态如果管理不好，页面会疯狂重渲染。我的经验是把购物车数据在data里保持一个二维结构：cartList，里面每一项包含selected属性，所有操作都走一个computeTotal方法重新计算总价，不要在前端到处改值。
订单确认页：显示收货地址、商品明细、配送方式、实付金额。这里要注意价格运算用分做单位，避免前端浮点数精度问题。比如后端返回price单位是"分"，前端展示时再除以100，计算总价时用整数加法，能少掉很多bug。
个人中心页：展示用户头像昵称、订单状态入口（待付款/待发货/待收货/已完成）、收货地址管理、联系客服、关于等。用户信息在小程序登录后存到本地，每次进入页面从后端刷新一次。
3.3 联调时的常见坑，帮你省下几个小时
最常见的问题就是"当前不会命中断点"。你在开发者工具里给小程序JS打断点，发现断点不生效，先看看是不是开启了"ES6转ES5"或者"压缩"模式，真机调试时通常不支持断点，要用console.log和vConsole调试。
第二是请求接口报http://无法请求。微信小程序的要求是，开发阶段要在开发者工具里勾选"不校验合法域名"，真机上要在公众平台配置request合法域名，而且必须是HTTPS。所以你的后端如果没有云服务器，尽量直接用本机局域网IP加端口调试，让手机和电脑连同一个WiFi，本地也可以用ngrok这类内网穿透工具，但要注意免费版不稳定，演示时建议提前录好视频。
第三是登录时不返回openid。wx.login拿到的code只有5分钟有效，后端调用微信的code2Session接口换openid，如果返回errcode，先检查小程序AppID和AppSecret是否匹配。很多人把测试号里的AppSecret和正式小程序的弄混，会一直提示"invalid code"。
4. 毕业论文怎么写得像样：结构、图表和查重的心得
论文是毕设评分的重中之重。代码跑得再漂亮，论文写得像流水账，分数也不会高。农产品销售小程序这个题目，论文的难点不在技术，而在你怎么把"一个常规业务系统"描述得有层次、有细节。
4.1 论文结构按这个顺序写，逻辑最顺
标准格式一般是：绪论（背景意义、国内外现状、研究内容）、相关技术介绍、系统分析（可行性分析、需求分析、用例图）、系统设计（总体架构、功能模块、数据库设计、接口设计）、系统实现（每个模块的页面和关键代码说明）、系统测试（功能测试用例、测试结果）、总结与展望。
我特别想提醒的是"相关技术介绍"别抄书。Spring Boot、微信小程序、MySQL是什么，这些概念简要写清楚就好，重点是写"为什么要选它"以及"它在项目中承担什么角色"。比如Spring Boot的自动配置如何减少项目配置，小程序端如何利用微信生态快速获取用户。这些结合项目的话，比大段官方定义有分量得多。
4.2 系统设计部分怎么画出专业级别的图
答辩老师看论文，最关注的图有四张：功能结构图、业务流程图、E-R图、架构图。很多学生用Visio画得歪歪扭扭，或者用在线工具生成一堆直线，看着就不太专业。
功能结构图建议用层次结构：顶上是"农产品销售小程序"，下面分"用户端（首页、分类、购物车、订单、我的）"和"管理端（商品管理、订单管理、用户管理、数据统计）"。业务流程图至少画两张：用户购买流程图和农户上架商品流程图。E-R图要能体现用户、商品、订单、订单明细、购物车之间的主外键关系。架构图画成分层：展示层（小程序）、业务层（SpringBoot）、数据层（MySQL），中间用箭头标出请求走向。
图不在多，而在于清晰。每张图在论文里需要有文字说明，不要只放图不给解释。很多同学不知道，论文里表格也很有用，比如数据库表结构表、接口列表、测试用例表，这些比大段文字直观得多。
4.3 查重和降重的实操经验
查重率要控制在学校要求线以下，一般20%或30%。技巧是：技术介绍部分不要原文照搬官方文档，用自己的话把概念讲出来。比如"MyBatis-Plus是MyBatis的增强工具，可以简化CRUD操作"这种句子，我一般会改写为"项目中持久层选择MyBatis-Plus，它在MyBatis的基础上提供条件构造器和代码生成器，使开发人员可以避免重复编写基础增删改查方法"。
需求分析里的功能列表和系统设计里的接口描述，尽量用表格形式，表格内容查重率通常低一些。但注意不要为了降重把核心内容删掉，答辩前最好自己通读一遍，确保内容通顺。
5. PPT、演示视频和源代码的标准化交付
题目里带了PPT和演示视频，这类附件分值不高，但能直接影响答辩时的第一印象。我见过太多人PPT里全是字，视频画质模糊，源代码解压后连README都没有，这些细节扣的都是印象分。
5.1 PPT内容排版：重点突出你做的工作
PPT建议控制在12-15页。第一页是题目、姓名、学号、指导教师。接着一页讲背景和意义，一页讲开发环境，两三页讲需求分析和系统功能，三四页讲系统设计与数据库，三四页放系统实现界面截图（每个页面配一两句功能说明），最后是测试与总结。别把大段文字粘贴上去，每页三到五个要点即可。
界面截图在小程序开发者工具里用Ctrl+S截取模拟器窗口，或者按Cmd+Shift+4截取选择区域，图片比手机拍照清晰。如果有管理端页面，用浏览器无痕模式打开，避免登录信息导致截图不干净。
5.2 演示视频录制：先写脚本再操作
演示视频一般要求5-10分钟，需要包含：系统启动、小程序登录、浏览首页、查看商品详情、加入购物车、下单、后台管理端操作等。我习惯用OBS录屏，先开OBS再开小程序开发者工具，视频分辨率至少1080P。
录制时千万不要开着一个有用户敏感信息的页面，比如真实手机号或者测试数据。我一般把数据库里的测试数据改成"张三""李四"，地址也写成虚拟地址。视频里如果跳出了"网络异常"或"登录过期"，不要慌，按流程重新操作一遍，但录之前一定要先跑通全流程，避免录到一半系统崩了。
5.3 源代码交付时的工程组织
交付源代码时，我建议提供两个文件夹：backend和miniprogram，如果有管理端前端再加一个admin。每个目录下必须有README.md，写明项目环境要求、MySQL版本、数据库脚本导入方法、启动步骤、测试账号。数据库脚本要单独放在sql目录里，包含建库建表语句和基础数据，不要让人自己手动建表。
代码注释是加分项，但不需要每行都加。我一般只在核心业务方法和复杂SQL上加中文注释，比如"根据订单状态统计销售额""生成唯一订单号"等。另外，项目中的配置文件要删掉真实密码和密钥，改成application.yml.example，把数据库用户名密码换成root/123456，微信AppSecret留空并注明"需自行填写"。这样既避免信息泄露，也给老师留下"工程规范"的好印象。
6. 答辩现场最容易翻车的几个问题及应对思路
别以为代码写完就万事大吉。答辩环节老师会围绕项目问很多"为什么"，不提前准备，很容易卡壳。我根据自己的经历和多年的经验，整理出五个高频问题，每个都有对应的思路。
6.1 老师问"哪些功能是你自己实现的"怎么答
别模糊，直接说哪部分是你独立完成，哪部分参考了网上的开源的。比如可以说"商品上架、购物车计算、订单生成和库存扣减是我自己写的，微信登录参考官方的登录流程文档"。同时点明难点，比如"订单生成过程中需要处理事务，防止扣了库存但订单创建失败"。
6.2 被问"你的系统有什么亮点"怎么答
农产品的亮点可以打在业务细节上：商品规格单位自定义、产地溯源展示、库存预警、销量统计排行。即使这些功能你只是简单做了，也要把设计思路讲出来。比如"我设计了商品浏览量字段，小程序端点击商品详情时，后端异步增加浏览数，首页可以按浏览量推荐热门商品"，这个表述就很具体。
6.3 被问"数据库为什么这么设计"怎么答
从业务出发解释。订单表和订单明细表拆分是为了"一个订单对应多个商品"；商品表冗余了一个分类名而不是直接存分类ID，是为了减少查询时联表；在订单明细表里冗余商品快照，是为了防止商品删除后订单历史仍可追溯。这些理由比"老师上课这么教的"有力得多。
6.4 被问"安全性怎么考虑"怎么答
主要说三点：第一，小程序端请求通过JWT或Token校验身份，后端统一有拦截器；第二，SQL使用MyBatis-Plus的参数预编译，防止SQL注入；第三，管理员接口与普通用户接口做了角色权限控制。另外顺便提一句，生产环境要关闭Spring Boot Actuator的端点暴露，避免未授权访问。这一句会让老师觉得你注意到真实部署的坑。
6.5 演示过程中系统崩了怎么办
这个必须有预案。录好的演示视频就是干这个用的——如果现场网络慢或者真机打不开，就说"请让我使用演示视频展示完整流程"，然后播视频。千万不要当场改代码，也不要说"我之前跑得好好的"。所以我一直建议，演示视频不是可选项，而是必选项。
整套流程走下来，你会发现这个毕设题目其实是很好的练手项目：后端、前端、数据库、论文写作、工具使用，一个完整的生命周期都覆盖了。把上面这些点逐一落实，不管是时间安排还是答辩表现，你都会比大多数同学更有把握。预祝一次通过。