简介本资源是一套完整的云浮市特色农产品交易微信小程序毕业设计项目面向计算机专业本科生、自学开发者及工程实训学习者解决农产品线上交易系统从需求分析到部署落地的全流程实践问题。压缩包共含可运行源码、SQL建表脚本与配套文档三类核心文件总大小38.34MB其中Spring Boot后端JDK8Tomcat7MySQL5.7提供RESTful接口UniAppVue前端实现跨平台小程序界面与交互逻辑代码经调试可直接运行。已有80人学习下载适合作为课程设计、大作业或毕设基础框架支持二次开发与功能扩展。资源结构清晰包含完整前后端分离架构、数据库初始化脚本及部署说明便于理解电商类系统的技术选型与模块划分特别适合掌握Java全栈开发与小程序跨端实践的学习者快速上手。 说实话看到“基于微信小程序的云浮市特色农产品交易”这个题目时我第一反应是这不就是一个农产品版的电商小程序吗SpringBoot做后端、Vue做管理后台、uniapp做小程序端三件套一搭页面一比划功能一填这事就成了。但真动手做下来才发现这类项目表面上是把几个框架串起来实际上破事比想象中多得多。我是把它当成一个真正要上线的云浮特产电商平台来做的。云浮的特产——罗定稻米、新兴凉果、郁南无核黄皮、砂糖橘——都是有地域标签的农产品不是工业流水线上的标准品这就决定了它在商品管理、库存单位、订单履约上都和普通的电商模板有差别。这篇文章把整个项目的设计思路和实现过程完整理一遍包括为什么选uniapp而不是原生小程序、三端之间的数据流怎么设计、数据库里的订单状态机怎么流转、以及真机联调时那些让人抓狂的坑希望能给正在做同类项目的朋友一些实际参考。1. 从“三端分离”看技术选型uniapp、SpringBoot、Vue各自解决什么问题1.1 为什么不是原生微信小程序而是uniapp这个项目虽然标题是“基于微信小程序”但我最终选择用uniapp来做小程序端。原因很简单uniapp写一套代码能同时编译成微信小程序、H5和Android/iOS的App。云浮特产这种项目通常做完小程序之后下一步就是想要一个给农户用的App端或者想在公众号里嵌一个H5商城。如果一开始用原生微信小程序后面这些扩展都得重新写一遍用uniapp大部分代码可以复用。但这不代表uniapp没有代价。最明显的就是uniapp编译到微信小程序时它是在运行时套了一层框架部分原生组件、基础库API的行为会有差异。比如微信原生的wx.getMenuButtonBoundingClientRect在uniapp里得用条件编译#ifdef MP-WEIXIN包一层才能拿到胶囊按钮的位置。这类跨端适配问题后面章节会详细说。1.2 SpringBoot后端不是“写接口”那么简单SpringBoot在这个项目里是纯后端API服务但它的职责比“提供几个增删改查接口”要重得多。农产品交易平台涉及小程序端用户、农户/商家端、平台管理员三类角色登录态怎么维持、订单状态怎么流转、支付回调怎么处理、文件上传怎么管理全都要在后端做统一设计。技术栈上我选了SpringBoot 2.7.x MyBatis-Plus MySQL。这里有个很实际的版本陷阱SpringBoot 3.x要求JDK17很多教程和旧版依赖比如某些版本的MyBatis-Plus、Druid连接池不兼容启动直接报错。我做项目时吃过这个亏后来老老实实回到2.7.x资料多网上的坑基本都有答案对于交付周期短的项目来说稳定比新版本重要。1.3 Vue管理后台工作量不比小程序少很多人觉得管理后台就是几个表格页面随便写写就行。实际上这个项目里管理后台是运营的核心工具商品审核、上下架、订单发货、退款处理、数据统计全在后台完成。Vue端遇到的高频问题反而不是框架本身而是和业务相关的状态管理、权限控制、跨域联调。管理后台采用Vue3 Vite Element Plus。如果参考的课程设计资料都是Vue2 Element UI的老教程也可以选Vue2.7不建议两头摇摆。管理端页面功能相对固定能否跑通业务闭环比技术栈新旧重要得多。2. 农产品交易系统的业务模型设计不是普通电商的缩小版2.1 用户角色与核心业务流云浮特色农产品交易平台的核心角色分三类普通消费者、农户/商家、平台管理员。普通消费者在小程序端逛商品、下单、支付、评价农户在小程序端或后台维护商品、处理订单、发货管理员在Vue后台审核商品、管理用户、看数据。这三类角色的功能差异直接在菜单和接口权限上体现出来。小程序端给消费者用不做商家入驻功能商家管理功能放在管理后台的独立模块里管理员拥有全部权限。角色权限用SpringBoot拦截器 JWT实现Vue端再用路由守卫控制页面访问两层都要做不能只靠前端隐藏菜单。核心业务流是浏览商品 → 加入购物车 → 提交订单 → 支付 → 商家发货 → 确认收货 → 评价。农产品交易比普通电商多一个“发货时效”问题因为生鲜类商品对物流要求高所以订单在“待发货”状态要显示发货倒计时超时后用户可申请平台介入这是农产品平台的常见需求。2.2 数据库表设计的几个关键决策数据库设计是整个项目的地基。核心表包括用户表、商品表、商品分类表、购物车表、订单表、订单明细表、收货地址表、轮播图表、公告表、评价表。有几个关键点值得单独说。第一个是库存单位。农产品的库存单位不是统一的“件”而是斤、箱、份、袋。比如罗定稻米按袋卖郁南无核黄皮按斤卖新兴凉果按盒卖。如果商品表只存一个stock字段下单时很难判断“5斤黄皮”和“1箱凉果”哪个库存充足。我的做法是在商品表加一个unit字段下单数量统一在业务层做换算前端商品详情页根据单位展示价格和购买数量。第二个是订单状态机。订单状态不能只用几个字符串字段随意改要在后端定义明确的状态流转规则。我用的状态枚举是待支付(0) → 已支付/待发货(1) → 已发货(2) → 已完成(3)加上已取消(4)和退款中(5)。每个状态的可达状态在代码里写死比如“待支付”只能转“已支付”或“已取消”“已发货”不能直接改成“已完成”而不走“确认收货”。这样能避免很多脏数据。当前状态允许跳转状态触发动作待支付已支付、已取消支付成功回调 / 用户取消或超时已支付已发货商家发货已发货已完成用户确认收货已完成无不可逆已取消无不可逆第三个是收货地址冗余。小程序端可以用微信的收货地址能力获取用户地址但正式下单时要把省市区和详细地址冗余存储到订单表里。为什么因为用户后续修改默认地址时历史订单的收货信息不应该跟着变。如果订单表只存address_id一旦用户改地址历史订单的发货地址全乱了。这是做电商项目非常容易忽略的坑。第四个是商品图片。农产品需要多图展示比如果实特写、产地实拍、包装图。我的方案是商品表存一个主图URL字段另外建一张product_image表存多图列表。也可以用JSON字段直接存URL数组但后期如果要做图片懒加载、缩略图裁剪还是独立表更灵活。3. 小程序端实现细节页面骨架、视频播放、地图选型和分享逻辑3.1 tabBar页面结构与顶部导航栏适配小程序端页面结构是这样规划的底部tabBar四个页面——“首页”“分类”“购物车”“我的”其余页面如商品详情、搜索、结算、订单列表全部作为普通页面跳转。页面结构定了先做的是导航栏适配。微信小程序的导航栏分为默认导航和自定义导航两种。如果想让首页更美观把搜索框和轮播图做得更有设计感就需要自定义导航栏这时候必须处理一个经典问题顶部导航栏高度。自定义导航栏时navigationStyle设为custom之后要在页面里手动留出状态栏和导航栏高度。计算方式如下// #ifdef MP-WEIXIN const info uni.getSystemInfoSync() const menu wx.getMenuButtonBoundingClientRect() // 状态栏高度 const statusBarHeight info.statusBarHeight // 导航栏高度 (胶囊顶部 - 状态栏高度) * 2 胶囊高度 const navHeight (menu.top - statusBarHeight) * 2 menu.height // #endif这个公式很多人不理解简单解释微信胶囊按钮的垂直位置和导航栏高度不是简单的“上下留白”。状态栏到胶囊按钮顶部的距离等于胶囊按钮底部到导航栏底部的距离所以导航栏高度 胶囊按钮高度 上下两个等距留白。我在iPhone 14和某些安卓机上实测过这个公式计算出来的高度基本是准的。真机上还有底部安全区问题尤其iPhone的Home Indicator。页面底部留白要加padding-bottom: env(safe-area-inset-bottom)否则“提交订单”按钮会被手势条挡住。3.2 商品详情页的图片、视频与PDF预览农产品详情页的信息密度比普通商品高除了主图、价格、规格、库存还要展示产地实拍、果树生长过程、检测报告。这里会涉及到三类文件的预览。图片预览最简单uniapp里用uni.previewImage传一个图片URL数组支持左右滑动查看大图不用自己写缩放逻辑。视频这块要特别注意。微信小程序的video组件支持HLSm3u8播放所以产地果园的实时监控或宣传视频如果服务端能输出m3u8流小程序端可以直接播放。但rtsp流不行微信小程序没有原生rtsp播放能力。我做项目时试过直接用video组件播rtsp的地址结果在开发者工具里就有兼容性提示真机上完全黑屏。解决方案是后端用ffmpeg把rtsp流转成hls切片ffmpeg -i rtsp://your_camera_stream -c:v copy -c:a copy -f hls -hls_time 4 -hls_list_size 10 stream.m3u8如果只是做演示不用实时监控那就更简单直接把.mp4文件传到服务器video组件就能播。PDF预览是另一个高频需求农产品的农药残留检测报告、绿色食品认证一般都导出成PDF。小程序端不能用iframe直接嵌网页我用的方案是uni.downloadFile下载PDF到临时目录再用uni.openDocument打开。注意uni.openDocument只支持打开本地文件路径不能直接传远程URL。3.3 地图组件内置map、腾讯地图SDK还是天地图这个项目的商品详情和自提点页面需要地图展示比如展示产地位置、配送范围。我一开始直接用微信小程序内置的map组件在开发者工具里一切正常但真机上问题来了map是原生组件层级高于普通组件页面里的弹窗、下拉框、悬浮按钮都会被地图盖住。安卓机上尤其明显地图直接遮挡住商品详情页的价格栏。解决方案有三个方向用cover-view和cover-image覆盖在map上层。但cover-view的样式支持有限复杂布局很难实现。在新版本基础库中map组件的同层渲染能力有所改善但不是所有机型都稳定。放弃内置map改用地图服务商的小程序SDK。比如腾讯位置服务的小程序SDK它提供的是普通组件不存在原生组件层级遮挡问题能直接渲染到页面上样式控制也更自由。关于天地图确实有用户问“微信小程序可以使用天地图画地图组件吗”。天地图主要提供Web端API微信小程序没有内置天地图组件。想用的话一般是通过web-view嵌入天地图的Web页面但这样和原生页面交互不方便而且web-view里的地图图层是网页渲染性能和体验都打折。实际做项目展示产地位置、配送范围这类轻量需求我更推荐腾讯地图或高德地图的小程序SDK。华为鸿蒙端的兼容性也要提前看部分地图SDK的鸿蒙适配晚于安卓开发前要确认版本。3.4 分包加载、自定义分享与社交裂变场景小程序主包体积限制是2MB超过就必须分包。这个项目把商品详情、商品搜索、结算页面、订单列表放到了分包里主包只保留tabBar页面和公共组件。如果用到分包异步化——也就是在某个分包中的自定义组件被另一个分包引用时异步加载——要注意基础库版本要求是2.20.2以上。开发者工具里看着没问题真机上如果基础库版本过低分包异步化的组件会加载失败页面直接白屏。分享功能对农产品电商特别重要。云浮特产有很强的社交属性用户买到好吃的黄皮大概率会分享给朋友。自定义分享可以用onShareAppMessage实现返回标题、图片路径、跳转路径。我在跳转路径里带了一个inviterId参数用户从分享链接进入小程序后后端能识别推荐人做“好友助力”“拼团优惠”这类裂变玩法。这个设计在答辩时是很加分的亮点。4. SpringBoot后端接口设计、登录态、文件上传与部署问题4.1 统一响应体和全局异常搭一个能长期维护的接口框架三端联调时接口返回格式不统一是大坑。小程序端、Vue后台、还有可能对接的第三方物流接口如果每个接口返回结构都不一样前端解析逻辑会写得非常痛苦。我的做法是定义统一响应体public class ResultT { private Integer code; private String msg; private T data; // getter/setter 省略 }成功返回code200业务失败返回code400未登录返回code401服务器异常返回code500。controller层不直接返回Map或裸数据全部包装成Result。配合全局异常处理器把参数校验异常、业务异常、未知异常统一拦截这样前端只需要看code字段就能知道请求状态不需要每个接口单独判断。接口文档我用的是Knife4jSwagger的增强版。生成接口文档后小程序端和Vue端可以并行开发不用等后端写完再联调。这里有个经验接口文档不仅给团队看等答辩或写文档时把接口截图放进说明书里能省很多事。4.2 登录态与接口安全JWT到底怎么用小程序端登录不能直接用账号密码微信生态的标准流程是小程序端wx.login拿到code后端用appid和secret去微信的code2session接口换取openid再用openid生成本系统的token返回给前端。后续请求在请求头里带上token后端拦截器校验。token我这里用的是JWT而不是传统session原因是管理后台和小程序端都可能要用JWT无状态适合接口分离架构。JWT里只放userId和角色信息不存敏感信息过期时间设置7天。拦截器做一个白名单配置登录接口、商品浏览接口、轮播图接口放行其他接口全部校验token。管理后台的登录是独立的一套账号密码体系登录成功后同样签发JWT。Vue端用路由守卫判断本地有没有token没有就跳登录页。这里提醒一句前端路由守卫只是用户体验层面的控制真正的权限校验必须在后端做否则别人直接调接口绕过页面限制数据就裸奔了。接口安全还有一个场景如果平台要和第三方物流系统或支付系统对接可以用API Key 时间戳 签名的机制。每次请求带上appKey、timestamp和signsign HMAC-MD5(appKey timestamp secret)。服务端用同样的算法算一次签名比对一致才放行。签名里必须带时间戳并校验过期时间防重放攻击。4.3 农产品图片上传、PDF的XSS风险与搜索分词商品图片上传是基础功能。上传到本地服务器时要注意三点一是在application.yml里配置静态资源映射否则上传后访问不到文件二是限制上传大小和文件类型图片只允许jpg、png、webp三是对文件名做重命名避免用户上传的文件名包含特殊字符。PDF预览功能涉及XSS风险。如果后台允许上传PDF并且前端用web-view直接预览恶意PDF里可以嵌入JavaScript脚本。在这个项目里我的做法是上传PDF时校验文件类型和魔数存储时给PDF文件设置独立的访问目录并配置Content-Disposition: attachment让浏览器优先下载而不是在页面内渲染。预览时用uni.openDocument独立打开不嵌入业务页面。搜索功能如果只用SQL的LIKE %黄皮%用户搜索“无核黄皮”时能匹配但搜索“黄皮果”可能就匹配不到。要提升搜索体验可以集成HanLP分词库。在SpringBoot里引入hanlp依赖后对商品名称做分词把分词结果存到一个搜索索引字段用户搜索时先分词再匹配。当然这个项目如果数据量不大LIKE模糊查询基本够用分词功能属于进阶优化。4.4 Linux部署从jar包到Nginx反向代理开发环境和部署环境是两码事。开发时用的application-dev.yml可以直连本地数据库但部署到Linux服务器时要用application-prod.yml区分环境。数据库密码不能明文写死在配置文件里用环境变量注入spring: datasource: url: jdbc:mysql://${DB_HOST}:3306/yunfu_shop?useUnicodetruecharacterEncodingutf8mb4useSSLfalse username: ${DB_USERNAME} password: ${DB_PASSWORD}启动命令是经典的nohup java -jar yunfu-shop-0.0.1.jar --spring.profiles.activeprod app.log 21 前端这边Vue后台构建后生成dist目录放到Nginx的html目录下。Nginx配置两个关键点一个是try_files处理Vue路由的history模式否则刷新页面会404另一个是接口反向代理将/api前缀的请求转发到SpringBoot端口server { listen 443 ssl; server_name yourdomain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }日志排查方面SpringBoot用logback按天滚动日志每次接口报错先看app.log里有没有堆栈。做一次完整部署比看十篇部署教程都管用。5. Vue管理后台商品、订单和农户数据的可视化管理5.1 Vue3和Vue2怎么选管理后台的技术选型我的建议很简单如果你熟悉组合式API和现代前端生态用Vue3 Vite Element Plus如果你参考的老教程、老项目都是Vue2 Element UI直接用Vue2.7不要为了追新而两头踩坑。为什么管理后台的核心价值是业务功能完整不是技术栈新。你花两天时间在Vue3的生态适配问题上不如把这两天用来把商品管理、订单流程做扎实。我在项目里用Vue3主要原因是Element Plus的组件质量和后续维护性更好而且和Vite的构建速度搭配很舒服。5.2 管理端核心页面拆解管理后台的主要页面按重要程度排序商品管理。商品列表、上下架、编辑、审核。列表页要支持按商品名称、分类、状态筛选表格里能直接改库存和价格。商品上架前有审核流程审核通过才在小程序端展示。订单管理。订单列表、订单详情、发货操作、退款处理。列表要按状态Tab切换方便运营快速看到待发货订单。发货操作需要填写物流公司、物流单号。用户管理。区分普通用户和农户。普通用户列表展示注册信息、订单数量农户列表展示入驻状态、在售商品数。管理员可以对违规用户禁用账号。数据统计。一个Dashboard页面展示今日订单数、交易金额、商品销量Top10、订单趋势折线图。这个页面是答辩时的视觉亮点建议用ECharts实现。5.3 computed与watch的正确姿势一个价格计算的实例Vue端一个很经典的业务场景运营在后台设置农产品活动价要同时填写原价、折扣率、实际售价三个字段。用户改原价或折扣率后实际售价自动计算如果实际售价低于成本价要给出提示。这个场景正好能用computed和watch的对比来说明。实际售价应该用computed计算因为它是由原价和折扣率派生出来的状态computed有缓存依赖的原价或折扣率变化时才重新计算。而watch适合用来处理“价格低于成本价时弹出警告”这种副作用场景// price为一个响应式对象 const finalPrice computed(() { return (price.original * price.discount / 10).toFixed(2) }) watch(() price.original, (newVal) { if (newVal price.costPrice) { ElMessage.warning(原价不能低于成本价) } })这个例子在面试和答辩时很好用因为很多人说不清楚computed和watch的区别。一句话总结computed根据已有的响应式数据派生出新值watch监听已有数据的变化再去做一件事。6. 跨端联调与部署的高频坑点白屏、手势返回、地图遮挡和抓包调试6.1 同样一套代码为什么开发者工具和真机表现不一样我在做这个项目的过程中遇到过“uniapp在手机上预览没问题但在微信开发者工具里白屏”的情况。注意这里和常见的“真机白屏”相反但同样值得排查。开发者工具白屏最常见的原因是这两个第一个是基础库版本不一致。开发者工具默认使用较新版本的基础库但如果你给某个页面配置了低版本兼容或者使用了高版本才支持的API工具里可能直接渲染失败。这时候先在“详情-本地设置”里切换基础库版本找到能正常显示的那个版本。第二个是配置文件编译问题。uniapp项目在开发者工具里白屏很多情况下是pages.json的页面路径配置有误或者某个页面文件里引入了不存在的组件。开发者工具的编译错误日志不一定显眼但打开控制台看运行时错误基本能找到线索。真机白屏的常见原因则不同90%是因为小程序后台的request合法域名没配置。开发者工具有“不校验合法域名”的开关所以工具里能请求接口真机上请求直接被拦截页面数据拿不到看起来就是白屏。6.2 安卓手势返回导致应用退出的排查链路这是另一个让我印象深刻的坑uniapp编译成App后在部分安卓手机上从二级页面手势返回时应用直接退出了。用户重新打开再手势返回又退出反复几次后页面才恢复正常。这个问题的根因在于uniapp在小程序端维护自己的页面栈但编译成App后安卓系统的手势返回会和页面栈的pop行为产生冲突。如果二级页面是直接用uni.redirectTo跳转的页面栈里没有留下可返回的页面系统手势返回时找不到上一页就触发了应用级退出。解决办法是统一页面跳转规范页面跳转尽量用uni.navigateTo不要用uni.redirectTo除非确实不需要返回。对tabBar页面监听onBackPress生命周期拦截返回操作。在manifest.json的App模块配置里检查Android的返回行为设置。排查这个问题的过程也让我理解了为什么uniapp官方文档反复强调生命周期管理。页面栈概念听起来抽象但实际踩坑时就是“为什么返回按钮能退出应用”这种直白的问题。6.3 地图组件遮挡从内置map到地图SDK的迁移前面提到过内置map组件在真机上会遮挡页面其他元素。这个坑的具体表现是商品详情页有地图展示地图下方有个“立即购买”的悬浮按钮安卓真机上按钮被地图盖住点击无响应。排查过程是这样的先怀疑是层级问题把按钮的z-index调到9999没用把按钮改成cover-view能点了但样式和普通view有差异圆角、投影效果都受限。最终方案是换用腾讯位置服务的小程序SDK。SDK提供的是正常渲染的普通组件没有原生组件层级问题悬浮按钮、弹窗都能正常显示。这个坑提醒我在项目初期做技术选型时如果页面有地图需求就要预判到原生组件的层级限制。不管是腾讯地图还是高德地图优先用SDK组件而不是内置map。6.4 抓包调试的合规思路看清自己应用的接口流向联调阶段最需要的就是抓包。微信小程序开发中抓包的主要方式有两种一是直接在微信开发者工具的Network面板看请求二是把手机或工具的代理指向本地的抓包工具比如Reqable、Charles抓取HTTPS请求时需要安装对应的CA证书。这里必须强调合规边界。抓包调试只应该针对自己开发的应用、自己的测试环境。小程序发布后线上版本有完整的安全校验机制不要尝试对他人线上应用做越权分析也不要使用抓包工具绕过任何验证逻辑。做开发时在小程序后台开启“调试模式”配合代理工具排查自己接口的请求参数和响应数据是完全正当的。我在实际排查接口问题时通常先在开发者工具里看请求头、请求体和响应体确认是前端参数传错还是后端逻辑错误。如果开发者工具里请求正常真机上不行就检查域名白名单和TLS证书配置。这种排查链路比盲改代码高效得多。7. 项目交付前必须处理的合规与发布事项7.1 软著申请的材料准备如果项目要上架应用市场或参与评审软件著作权登记是绕不开的。软著申请需要的材料主要有软件著作权登记申请表源代码文档通常要求前后各30页或40页每页50行左右PDF格式用户操作手册或设计说明书包含系统首页、功能截图、操作说明身份证明文件源代码文档有个容易忽略的细节代码页要有页码并且要包含完整的项目名称、版本号信息。记得在提交前建一个docs目录把答辩用的演示PPT、设计说明书、源代码文档、数据库SQL脚本统一归档。软著审批周期通常需要1-2个月如果项目要急着上架提前规划申请时间。7.2 小程序和安卓应用市场上架的检查清单小程序上架前有一堆细节列个自查清单小程序类目要选对。如果做农产品销售涉及食品类目一般需要营业执照和食品经营许可证。纯毕设项目如果没证可以先用“工具-信息查询”类目演示或者只做开发版预览。所有网络请求必须使用HTTPS并在小程序后台配置request合法域名。设置隐私政策说明用户信息收集范围和使用方式。小程序名称和logo不能侵权。如果要把uniapp代码编译成安卓App上架应用市场还需要软著证书、隐私政策、应用签名文件。上架前要在manifest.json里配置App图标、启动图、包名、版本号。上架华为、小米、OPPO、vivo、应用宝等应用市场时各个市场的审核标准略有差异最好先准备一份通用的隐私政策和用户协议。7.3 演示和答辩中如何把“云浮特色”讲出亮点同样是农产品电商项目很多组做出来千篇一律。想要让答辩老师或评审觉得有特色关键不在于展示了多少页面而在于能否把“云浮特色农产品”这个地域标签真正融入功能设计。我的经验是准备三条演示主线第一条完整下单链路。从首页进入时令推荐专区选择郁南无核黄皮查看产地溯源信息加入购物车提交订单模拟支付订单状态流转。这条链路展示了核心业务闭环。第二条管理后台运营流。管理员审核农户提交的商品设置活动价商家发货填物流单号用户确认收货后评价。这条链路展示了角色协同。第三条技术亮点讲解。JWT登录态、订单状态机、地图配送范围展示、自定义分享带推荐人参数、uniapp一套代码编译多端。每讲一个亮点对应说明解决了什么问题。我发现演示时最打动人心的不是花哨的动画而是“你注意到了别人没注意的业务细节”。比如你能解释清楚为什么历史订单要冗余收货地址、为什么生鲜商品的订单状态机里有发货倒计时这比一句“我用了SpringBoot Vue”强得多。做一个农产品交易项目和做一个纯技术Demo最大的区别就在这里。技术栈只是工具真正考验的是对业务场景的理解。把云浮特产的季节性问题、库存单位问题、产地信任问题想清楚了系统自然就有灵魂。希望这篇记录能帮你少走点弯路。本文还有配套的精品资源点击获取 基于SpringBoot+uniapp的云浮特产农产品交易小程序开发实践
简介本资源是一套完整的云浮市特色农产品交易微信小程序毕业设计项目面向计算机专业本科生、自学开发者及工程实训学习者解决农产品线上交易系统从需求分析到部署落地的全流程实践问题。压缩包共含可运行源码、SQL建表脚本与配套文档三类核心文件总大小38.34MB其中Spring Boot后端JDK8Tomcat7MySQL5.7提供RESTful接口UniAppVue前端实现跨平台小程序界面与交互逻辑代码经调试可直接运行。已有80人学习下载适合作为课程设计、大作业或毕设基础框架支持二次开发与功能扩展。资源结构清晰包含完整前后端分离架构、数据库初始化脚本及部署说明便于理解电商类系统的技术选型与模块划分特别适合掌握Java全栈开发与小程序跨端实践的学习者快速上手。 说实话看到“基于微信小程序的云浮市特色农产品交易”这个题目时我第一反应是这不就是一个农产品版的电商小程序吗SpringBoot做后端、Vue做管理后台、uniapp做小程序端三件套一搭页面一比划功能一填这事就成了。但真动手做下来才发现这类项目表面上是把几个框架串起来实际上破事比想象中多得多。我是把它当成一个真正要上线的云浮特产电商平台来做的。云浮的特产——罗定稻米、新兴凉果、郁南无核黄皮、砂糖橘——都是有地域标签的农产品不是工业流水线上的标准品这就决定了它在商品管理、库存单位、订单履约上都和普通的电商模板有差别。这篇文章把整个项目的设计思路和实现过程完整理一遍包括为什么选uniapp而不是原生小程序、三端之间的数据流怎么设计、数据库里的订单状态机怎么流转、以及真机联调时那些让人抓狂的坑希望能给正在做同类项目的朋友一些实际参考。1. 从“三端分离”看技术选型uniapp、SpringBoot、Vue各自解决什么问题1.1 为什么不是原生微信小程序而是uniapp这个项目虽然标题是“基于微信小程序”但我最终选择用uniapp来做小程序端。原因很简单uniapp写一套代码能同时编译成微信小程序、H5和Android/iOS的App。云浮特产这种项目通常做完小程序之后下一步就是想要一个给农户用的App端或者想在公众号里嵌一个H5商城。如果一开始用原生微信小程序后面这些扩展都得重新写一遍用uniapp大部分代码可以复用。但这不代表uniapp没有代价。最明显的就是uniapp编译到微信小程序时它是在运行时套了一层框架部分原生组件、基础库API的行为会有差异。比如微信原生的wx.getMenuButtonBoundingClientRect在uniapp里得用条件编译#ifdef MP-WEIXIN包一层才能拿到胶囊按钮的位置。这类跨端适配问题后面章节会详细说。1.2 SpringBoot后端不是“写接口”那么简单SpringBoot在这个项目里是纯后端API服务但它的职责比“提供几个增删改查接口”要重得多。农产品交易平台涉及小程序端用户、农户/商家端、平台管理员三类角色登录态怎么维持、订单状态怎么流转、支付回调怎么处理、文件上传怎么管理全都要在后端做统一设计。技术栈上我选了SpringBoot 2.7.x MyBatis-Plus MySQL。这里有个很实际的版本陷阱SpringBoot 3.x要求JDK17很多教程和旧版依赖比如某些版本的MyBatis-Plus、Druid连接池不兼容启动直接报错。我做项目时吃过这个亏后来老老实实回到2.7.x资料多网上的坑基本都有答案对于交付周期短的项目来说稳定比新版本重要。1.3 Vue管理后台工作量不比小程序少很多人觉得管理后台就是几个表格页面随便写写就行。实际上这个项目里管理后台是运营的核心工具商品审核、上下架、订单发货、退款处理、数据统计全在后台完成。Vue端遇到的高频问题反而不是框架本身而是和业务相关的状态管理、权限控制、跨域联调。管理后台采用Vue3 Vite Element Plus。如果参考的课程设计资料都是Vue2 Element UI的老教程也可以选Vue2.7不建议两头摇摆。管理端页面功能相对固定能否跑通业务闭环比技术栈新旧重要得多。2. 农产品交易系统的业务模型设计不是普通电商的缩小版2.1 用户角色与核心业务流云浮特色农产品交易平台的核心角色分三类普通消费者、农户/商家、平台管理员。普通消费者在小程序端逛商品、下单、支付、评价农户在小程序端或后台维护商品、处理订单、发货管理员在Vue后台审核商品、管理用户、看数据。这三类角色的功能差异直接在菜单和接口权限上体现出来。小程序端给消费者用不做商家入驻功能商家管理功能放在管理后台的独立模块里管理员拥有全部权限。角色权限用SpringBoot拦截器 JWT实现Vue端再用路由守卫控制页面访问两层都要做不能只靠前端隐藏菜单。核心业务流是浏览商品 → 加入购物车 → 提交订单 → 支付 → 商家发货 → 确认收货 → 评价。农产品交易比普通电商多一个“发货时效”问题因为生鲜类商品对物流要求高所以订单在“待发货”状态要显示发货倒计时超时后用户可申请平台介入这是农产品平台的常见需求。2.2 数据库表设计的几个关键决策数据库设计是整个项目的地基。核心表包括用户表、商品表、商品分类表、购物车表、订单表、订单明细表、收货地址表、轮播图表、公告表、评价表。有几个关键点值得单独说。第一个是库存单位。农产品的库存单位不是统一的“件”而是斤、箱、份、袋。比如罗定稻米按袋卖郁南无核黄皮按斤卖新兴凉果按盒卖。如果商品表只存一个stock字段下单时很难判断“5斤黄皮”和“1箱凉果”哪个库存充足。我的做法是在商品表加一个unit字段下单数量统一在业务层做换算前端商品详情页根据单位展示价格和购买数量。第二个是订单状态机。订单状态不能只用几个字符串字段随意改要在后端定义明确的状态流转规则。我用的状态枚举是待支付(0) → 已支付/待发货(1) → 已发货(2) → 已完成(3)加上已取消(4)和退款中(5)。每个状态的可达状态在代码里写死比如“待支付”只能转“已支付”或“已取消”“已发货”不能直接改成“已完成”而不走“确认收货”。这样能避免很多脏数据。当前状态允许跳转状态触发动作待支付已支付、已取消支付成功回调 / 用户取消或超时已支付已发货商家发货已发货已完成用户确认收货已完成无不可逆已取消无不可逆第三个是收货地址冗余。小程序端可以用微信的收货地址能力获取用户地址但正式下单时要把省市区和详细地址冗余存储到订单表里。为什么因为用户后续修改默认地址时历史订单的收货信息不应该跟着变。如果订单表只存address_id一旦用户改地址历史订单的发货地址全乱了。这是做电商项目非常容易忽略的坑。第四个是商品图片。农产品需要多图展示比如果实特写、产地实拍、包装图。我的方案是商品表存一个主图URL字段另外建一张product_image表存多图列表。也可以用JSON字段直接存URL数组但后期如果要做图片懒加载、缩略图裁剪还是独立表更灵活。3. 小程序端实现细节页面骨架、视频播放、地图选型和分享逻辑3.1 tabBar页面结构与顶部导航栏适配小程序端页面结构是这样规划的底部tabBar四个页面——“首页”“分类”“购物车”“我的”其余页面如商品详情、搜索、结算、订单列表全部作为普通页面跳转。页面结构定了先做的是导航栏适配。微信小程序的导航栏分为默认导航和自定义导航两种。如果想让首页更美观把搜索框和轮播图做得更有设计感就需要自定义导航栏这时候必须处理一个经典问题顶部导航栏高度。自定义导航栏时navigationStyle设为custom之后要在页面里手动留出状态栏和导航栏高度。计算方式如下// #ifdef MP-WEIXIN const info uni.getSystemInfoSync() const menu wx.getMenuButtonBoundingClientRect() // 状态栏高度 const statusBarHeight info.statusBarHeight // 导航栏高度 (胶囊顶部 - 状态栏高度) * 2 胶囊高度 const navHeight (menu.top - statusBarHeight) * 2 menu.height // #endif这个公式很多人不理解简单解释微信胶囊按钮的垂直位置和导航栏高度不是简单的“上下留白”。状态栏到胶囊按钮顶部的距离等于胶囊按钮底部到导航栏底部的距离所以导航栏高度 胶囊按钮高度 上下两个等距留白。我在iPhone 14和某些安卓机上实测过这个公式计算出来的高度基本是准的。真机上还有底部安全区问题尤其iPhone的Home Indicator。页面底部留白要加padding-bottom: env(safe-area-inset-bottom)否则“提交订单”按钮会被手势条挡住。3.2 商品详情页的图片、视频与PDF预览农产品详情页的信息密度比普通商品高除了主图、价格、规格、库存还要展示产地实拍、果树生长过程、检测报告。这里会涉及到三类文件的预览。图片预览最简单uniapp里用uni.previewImage传一个图片URL数组支持左右滑动查看大图不用自己写缩放逻辑。视频这块要特别注意。微信小程序的video组件支持HLSm3u8播放所以产地果园的实时监控或宣传视频如果服务端能输出m3u8流小程序端可以直接播放。但rtsp流不行微信小程序没有原生rtsp播放能力。我做项目时试过直接用video组件播rtsp的地址结果在开发者工具里就有兼容性提示真机上完全黑屏。解决方案是后端用ffmpeg把rtsp流转成hls切片ffmpeg -i rtsp://your_camera_stream -c:v copy -c:a copy -f hls -hls_time 4 -hls_list_size 10 stream.m3u8如果只是做演示不用实时监控那就更简单直接把.mp4文件传到服务器video组件就能播。PDF预览是另一个高频需求农产品的农药残留检测报告、绿色食品认证一般都导出成PDF。小程序端不能用iframe直接嵌网页我用的方案是uni.downloadFile下载PDF到临时目录再用uni.openDocument打开。注意uni.openDocument只支持打开本地文件路径不能直接传远程URL。3.3 地图组件内置map、腾讯地图SDK还是天地图这个项目的商品详情和自提点页面需要地图展示比如展示产地位置、配送范围。我一开始直接用微信小程序内置的map组件在开发者工具里一切正常但真机上问题来了map是原生组件层级高于普通组件页面里的弹窗、下拉框、悬浮按钮都会被地图盖住。安卓机上尤其明显地图直接遮挡住商品详情页的价格栏。解决方案有三个方向用cover-view和cover-image覆盖在map上层。但cover-view的样式支持有限复杂布局很难实现。在新版本基础库中map组件的同层渲染能力有所改善但不是所有机型都稳定。放弃内置map改用地图服务商的小程序SDK。比如腾讯位置服务的小程序SDK它提供的是普通组件不存在原生组件层级遮挡问题能直接渲染到页面上样式控制也更自由。关于天地图确实有用户问“微信小程序可以使用天地图画地图组件吗”。天地图主要提供Web端API微信小程序没有内置天地图组件。想用的话一般是通过web-view嵌入天地图的Web页面但这样和原生页面交互不方便而且web-view里的地图图层是网页渲染性能和体验都打折。实际做项目展示产地位置、配送范围这类轻量需求我更推荐腾讯地图或高德地图的小程序SDK。华为鸿蒙端的兼容性也要提前看部分地图SDK的鸿蒙适配晚于安卓开发前要确认版本。3.4 分包加载、自定义分享与社交裂变场景小程序主包体积限制是2MB超过就必须分包。这个项目把商品详情、商品搜索、结算页面、订单列表放到了分包里主包只保留tabBar页面和公共组件。如果用到分包异步化——也就是在某个分包中的自定义组件被另一个分包引用时异步加载——要注意基础库版本要求是2.20.2以上。开发者工具里看着没问题真机上如果基础库版本过低分包异步化的组件会加载失败页面直接白屏。分享功能对农产品电商特别重要。云浮特产有很强的社交属性用户买到好吃的黄皮大概率会分享给朋友。自定义分享可以用onShareAppMessage实现返回标题、图片路径、跳转路径。我在跳转路径里带了一个inviterId参数用户从分享链接进入小程序后后端能识别推荐人做“好友助力”“拼团优惠”这类裂变玩法。这个设计在答辩时是很加分的亮点。4. SpringBoot后端接口设计、登录态、文件上传与部署问题4.1 统一响应体和全局异常搭一个能长期维护的接口框架三端联调时接口返回格式不统一是大坑。小程序端、Vue后台、还有可能对接的第三方物流接口如果每个接口返回结构都不一样前端解析逻辑会写得非常痛苦。我的做法是定义统一响应体public class ResultT { private Integer code; private String msg; private T data; // getter/setter 省略 }成功返回code200业务失败返回code400未登录返回code401服务器异常返回code500。controller层不直接返回Map或裸数据全部包装成Result。配合全局异常处理器把参数校验异常、业务异常、未知异常统一拦截这样前端只需要看code字段就能知道请求状态不需要每个接口单独判断。接口文档我用的是Knife4jSwagger的增强版。生成接口文档后小程序端和Vue端可以并行开发不用等后端写完再联调。这里有个经验接口文档不仅给团队看等答辩或写文档时把接口截图放进说明书里能省很多事。4.2 登录态与接口安全JWT到底怎么用小程序端登录不能直接用账号密码微信生态的标准流程是小程序端wx.login拿到code后端用appid和secret去微信的code2session接口换取openid再用openid生成本系统的token返回给前端。后续请求在请求头里带上token后端拦截器校验。token我这里用的是JWT而不是传统session原因是管理后台和小程序端都可能要用JWT无状态适合接口分离架构。JWT里只放userId和角色信息不存敏感信息过期时间设置7天。拦截器做一个白名单配置登录接口、商品浏览接口、轮播图接口放行其他接口全部校验token。管理后台的登录是独立的一套账号密码体系登录成功后同样签发JWT。Vue端用路由守卫判断本地有没有token没有就跳登录页。这里提醒一句前端路由守卫只是用户体验层面的控制真正的权限校验必须在后端做否则别人直接调接口绕过页面限制数据就裸奔了。接口安全还有一个场景如果平台要和第三方物流系统或支付系统对接可以用API Key 时间戳 签名的机制。每次请求带上appKey、timestamp和signsign HMAC-MD5(appKey timestamp secret)。服务端用同样的算法算一次签名比对一致才放行。签名里必须带时间戳并校验过期时间防重放攻击。4.3 农产品图片上传、PDF的XSS风险与搜索分词商品图片上传是基础功能。上传到本地服务器时要注意三点一是在application.yml里配置静态资源映射否则上传后访问不到文件二是限制上传大小和文件类型图片只允许jpg、png、webp三是对文件名做重命名避免用户上传的文件名包含特殊字符。PDF预览功能涉及XSS风险。如果后台允许上传PDF并且前端用web-view直接预览恶意PDF里可以嵌入JavaScript脚本。在这个项目里我的做法是上传PDF时校验文件类型和魔数存储时给PDF文件设置独立的访问目录并配置Content-Disposition: attachment让浏览器优先下载而不是在页面内渲染。预览时用uni.openDocument独立打开不嵌入业务页面。搜索功能如果只用SQL的LIKE %黄皮%用户搜索“无核黄皮”时能匹配但搜索“黄皮果”可能就匹配不到。要提升搜索体验可以集成HanLP分词库。在SpringBoot里引入hanlp依赖后对商品名称做分词把分词结果存到一个搜索索引字段用户搜索时先分词再匹配。当然这个项目如果数据量不大LIKE模糊查询基本够用分词功能属于进阶优化。4.4 Linux部署从jar包到Nginx反向代理开发环境和部署环境是两码事。开发时用的application-dev.yml可以直连本地数据库但部署到Linux服务器时要用application-prod.yml区分环境。数据库密码不能明文写死在配置文件里用环境变量注入spring: datasource: url: jdbc:mysql://${DB_HOST}:3306/yunfu_shop?useUnicodetruecharacterEncodingutf8mb4useSSLfalse username: ${DB_USERNAME} password: ${DB_PASSWORD}启动命令是经典的nohup java -jar yunfu-shop-0.0.1.jar --spring.profiles.activeprod app.log 21 前端这边Vue后台构建后生成dist目录放到Nginx的html目录下。Nginx配置两个关键点一个是try_files处理Vue路由的history模式否则刷新页面会404另一个是接口反向代理将/api前缀的请求转发到SpringBoot端口server { listen 443 ssl; server_name yourdomain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }日志排查方面SpringBoot用logback按天滚动日志每次接口报错先看app.log里有没有堆栈。做一次完整部署比看十篇部署教程都管用。5. Vue管理后台商品、订单和农户数据的可视化管理5.1 Vue3和Vue2怎么选管理后台的技术选型我的建议很简单如果你熟悉组合式API和现代前端生态用Vue3 Vite Element Plus如果你参考的老教程、老项目都是Vue2 Element UI直接用Vue2.7不要为了追新而两头踩坑。为什么管理后台的核心价值是业务功能完整不是技术栈新。你花两天时间在Vue3的生态适配问题上不如把这两天用来把商品管理、订单流程做扎实。我在项目里用Vue3主要原因是Element Plus的组件质量和后续维护性更好而且和Vite的构建速度搭配很舒服。5.2 管理端核心页面拆解管理后台的主要页面按重要程度排序商品管理。商品列表、上下架、编辑、审核。列表页要支持按商品名称、分类、状态筛选表格里能直接改库存和价格。商品上架前有审核流程审核通过才在小程序端展示。订单管理。订单列表、订单详情、发货操作、退款处理。列表要按状态Tab切换方便运营快速看到待发货订单。发货操作需要填写物流公司、物流单号。用户管理。区分普通用户和农户。普通用户列表展示注册信息、订单数量农户列表展示入驻状态、在售商品数。管理员可以对违规用户禁用账号。数据统计。一个Dashboard页面展示今日订单数、交易金额、商品销量Top10、订单趋势折线图。这个页面是答辩时的视觉亮点建议用ECharts实现。5.3 computed与watch的正确姿势一个价格计算的实例Vue端一个很经典的业务场景运营在后台设置农产品活动价要同时填写原价、折扣率、实际售价三个字段。用户改原价或折扣率后实际售价自动计算如果实际售价低于成本价要给出提示。这个场景正好能用computed和watch的对比来说明。实际售价应该用computed计算因为它是由原价和折扣率派生出来的状态computed有缓存依赖的原价或折扣率变化时才重新计算。而watch适合用来处理“价格低于成本价时弹出警告”这种副作用场景// price为一个响应式对象 const finalPrice computed(() { return (price.original * price.discount / 10).toFixed(2) }) watch(() price.original, (newVal) { if (newVal price.costPrice) { ElMessage.warning(原价不能低于成本价) } })这个例子在面试和答辩时很好用因为很多人说不清楚computed和watch的区别。一句话总结computed根据已有的响应式数据派生出新值watch监听已有数据的变化再去做一件事。6. 跨端联调与部署的高频坑点白屏、手势返回、地图遮挡和抓包调试6.1 同样一套代码为什么开发者工具和真机表现不一样我在做这个项目的过程中遇到过“uniapp在手机上预览没问题但在微信开发者工具里白屏”的情况。注意这里和常见的“真机白屏”相反但同样值得排查。开发者工具白屏最常见的原因是这两个第一个是基础库版本不一致。开发者工具默认使用较新版本的基础库但如果你给某个页面配置了低版本兼容或者使用了高版本才支持的API工具里可能直接渲染失败。这时候先在“详情-本地设置”里切换基础库版本找到能正常显示的那个版本。第二个是配置文件编译问题。uniapp项目在开发者工具里白屏很多情况下是pages.json的页面路径配置有误或者某个页面文件里引入了不存在的组件。开发者工具的编译错误日志不一定显眼但打开控制台看运行时错误基本能找到线索。真机白屏的常见原因则不同90%是因为小程序后台的request合法域名没配置。开发者工具有“不校验合法域名”的开关所以工具里能请求接口真机上请求直接被拦截页面数据拿不到看起来就是白屏。6.2 安卓手势返回导致应用退出的排查链路这是另一个让我印象深刻的坑uniapp编译成App后在部分安卓手机上从二级页面手势返回时应用直接退出了。用户重新打开再手势返回又退出反复几次后页面才恢复正常。这个问题的根因在于uniapp在小程序端维护自己的页面栈但编译成App后安卓系统的手势返回会和页面栈的pop行为产生冲突。如果二级页面是直接用uni.redirectTo跳转的页面栈里没有留下可返回的页面系统手势返回时找不到上一页就触发了应用级退出。解决办法是统一页面跳转规范页面跳转尽量用uni.navigateTo不要用uni.redirectTo除非确实不需要返回。对tabBar页面监听onBackPress生命周期拦截返回操作。在manifest.json的App模块配置里检查Android的返回行为设置。排查这个问题的过程也让我理解了为什么uniapp官方文档反复强调生命周期管理。页面栈概念听起来抽象但实际踩坑时就是“为什么返回按钮能退出应用”这种直白的问题。6.3 地图组件遮挡从内置map到地图SDK的迁移前面提到过内置map组件在真机上会遮挡页面其他元素。这个坑的具体表现是商品详情页有地图展示地图下方有个“立即购买”的悬浮按钮安卓真机上按钮被地图盖住点击无响应。排查过程是这样的先怀疑是层级问题把按钮的z-index调到9999没用把按钮改成cover-view能点了但样式和普通view有差异圆角、投影效果都受限。最终方案是换用腾讯位置服务的小程序SDK。SDK提供的是正常渲染的普通组件没有原生组件层级问题悬浮按钮、弹窗都能正常显示。这个坑提醒我在项目初期做技术选型时如果页面有地图需求就要预判到原生组件的层级限制。不管是腾讯地图还是高德地图优先用SDK组件而不是内置map。6.4 抓包调试的合规思路看清自己应用的接口流向联调阶段最需要的就是抓包。微信小程序开发中抓包的主要方式有两种一是直接在微信开发者工具的Network面板看请求二是把手机或工具的代理指向本地的抓包工具比如Reqable、Charles抓取HTTPS请求时需要安装对应的CA证书。这里必须强调合规边界。抓包调试只应该针对自己开发的应用、自己的测试环境。小程序发布后线上版本有完整的安全校验机制不要尝试对他人线上应用做越权分析也不要使用抓包工具绕过任何验证逻辑。做开发时在小程序后台开启“调试模式”配合代理工具排查自己接口的请求参数和响应数据是完全正当的。我在实际排查接口问题时通常先在开发者工具里看请求头、请求体和响应体确认是前端参数传错还是后端逻辑错误。如果开发者工具里请求正常真机上不行就检查域名白名单和TLS证书配置。这种排查链路比盲改代码高效得多。7. 项目交付前必须处理的合规与发布事项7.1 软著申请的材料准备如果项目要上架应用市场或参与评审软件著作权登记是绕不开的。软著申请需要的材料主要有软件著作权登记申请表源代码文档通常要求前后各30页或40页每页50行左右PDF格式用户操作手册或设计说明书包含系统首页、功能截图、操作说明身份证明文件源代码文档有个容易忽略的细节代码页要有页码并且要包含完整的项目名称、版本号信息。记得在提交前建一个docs目录把答辩用的演示PPT、设计说明书、源代码文档、数据库SQL脚本统一归档。软著审批周期通常需要1-2个月如果项目要急着上架提前规划申请时间。7.2 小程序和安卓应用市场上架的检查清单小程序上架前有一堆细节列个自查清单小程序类目要选对。如果做农产品销售涉及食品类目一般需要营业执照和食品经营许可证。纯毕设项目如果没证可以先用“工具-信息查询”类目演示或者只做开发版预览。所有网络请求必须使用HTTPS并在小程序后台配置request合法域名。设置隐私政策说明用户信息收集范围和使用方式。小程序名称和logo不能侵权。如果要把uniapp代码编译成安卓App上架应用市场还需要软著证书、隐私政策、应用签名文件。上架前要在manifest.json里配置App图标、启动图、包名、版本号。上架华为、小米、OPPO、vivo、应用宝等应用市场时各个市场的审核标准略有差异最好先准备一份通用的隐私政策和用户协议。7.3 演示和答辩中如何把“云浮特色”讲出亮点同样是农产品电商项目很多组做出来千篇一律。想要让答辩老师或评审觉得有特色关键不在于展示了多少页面而在于能否把“云浮特色农产品”这个地域标签真正融入功能设计。我的经验是准备三条演示主线第一条完整下单链路。从首页进入时令推荐专区选择郁南无核黄皮查看产地溯源信息加入购物车提交订单模拟支付订单状态流转。这条链路展示了核心业务闭环。第二条管理后台运营流。管理员审核农户提交的商品设置活动价商家发货填物流单号用户确认收货后评价。这条链路展示了角色协同。第三条技术亮点讲解。JWT登录态、订单状态机、地图配送范围展示、自定义分享带推荐人参数、uniapp一套代码编译多端。每讲一个亮点对应说明解决了什么问题。我发现演示时最打动人心的不是花哨的动画而是“你注意到了别人没注意的业务细节”。比如你能解释清楚为什么历史订单要冗余收货地址、为什么生鲜商品的订单状态机里有发货倒计时这比一句“我用了SpringBoot Vue”强得多。做一个农产品交易项目和做一个纯技术Demo最大的区别就在这里。技术栈只是工具真正考验的是对业务场景的理解。把云浮特产的季节性问题、库存单位问题、产地信任问题想清楚了系统自然就有灵魂。希望这篇记录能帮你少走点弯路。本文还有配套的精品资源点击获取