企业官网建设流程全解析

简介：本资源是一套完整的云浮市特色农产品交易微信小程序毕业设计项目，面向计算机专业本科生、自学开发者及工程实训学习者，解决农产品线上交易系统从需求分析到部署落地的全流程实践问题。压缩包共含可运行源码、SQL建表脚本与配套文档三类核心文件，总大小38.34MB；其中Spring Boot后端（JDK8+Tomcat7+MySQL5.7）提供RESTful接口，UniApp+Vue前端实现跨平台小程序界面与交互逻辑，代码经调试可直接运行。已有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组件支持HLS（m3u8）播放，所以产地果园的实时监控或宣传视频，如果服务端能输出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是原生组件，层级高于普通组件，页面里的弹窗、下拉框、悬浮按钮都会被地图盖住。安卓机上尤其明显，地图直接遮挡住商品详情页的价格栏。

解决方案有三个方向：

1. 用cover-view和cover-image覆盖在map上层。但cover-view的样式支持有限，复杂布局很难实现。
2. 在新版本基础库中，map组件的同层渲染能力有所改善，但不是所有机型都稳定。
3. 放弃内置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 Result<T> { private Integer code; private String msg; private T data; // getter/setter 省略 }

成功返回code=200，业务失败返回code=400，未登录返回code=401，服务器异常返回code=500。controller层不直接返回Map或裸数据，全部包装成Result。

配合全局异常处理器，把参数校验异常、业务异常、未知异常统一拦截，这样前端只需要看code字段就能知道请求状态，不需要每个接口单独判断。

接口文档我用的是Knife4j（Swagger的增强版）。生成接口文档后，小程序端和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和sign，sign = 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?useUnicode=true&characterEncoding=utf8mb4&useSSL=false username: ${DB_USERNAME} password: ${DB_PASSWORD}

启动命令是经典的：

nohup java -jar yunfu-shop-0.0.1.jar --spring.profiles.active=prod > app.log 2>&1 &

前端这边，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，最大的区别就在这里。技术栈只是工具，真正考验的是对业务场景的理解。把云浮特产的季节性问题、库存单位问题、产地信任问题想清楚了，系统自然就有灵魂。希望这篇记录能帮你少走点弯路。

本文还有配套的精品资源，点击获取