企业官网建设流程全解析

“基于微信小程序的农产品销售系统”是计算机毕业设计里一个非常经典的选题。这个题目之所以年年有人做，是因为它踩中了两个关键点：一是微信小程序生态成熟，前端展示效果直观，答辩时演示成本低；二是农产品销售这个业务场景足够清晰，供需两端的需求都容易调研，功能边界好划定，不会做着做着就失控。

但同时，这个题目也是“烂大街”重灾区。如果你只是把商品列表、购物车、订单管理这些通用电商功能换个农产品皮肤，那答辩时老师一眼就能看穿，分数基本就在及格线附近徘徊。这篇文档我不会给你贴一整份源码，而是把整个项目从选题定位、技术选型、数据库设计，到核心功能实现、坑点规避、答辩准备的完整链路拆开来讲。目标是让拿到这套东西的人，不仅能把系统跑起来，还能讲清楚每一个设计决策背后的理由。

1. 选题定位：别只做一个“换了皮”的电商系统

毕业设计的评分逻辑，从来不是“功能越多越好”，而是“问题定义是否清晰、技术方案是否匹配、工作量是否饱满、结果是否可验证”。农产品销售系统想拿高分，第一步就是在需求分析阶段把“农产品”这三个字的特殊性挖出来，而不是套用通用电商模板。

1.1 农产品销售和普通电商的核心差异

普通电商系统（比如卖衣服、卖数码产品）的核心模型是SPU/SKU、库存、物流追踪，但农产品不一样：

• 非标准化商品：同一种苹果，产地不同、规格不同、成熟度不同，价格就完全不同。数据库里不能只存一个“苹果”商品，必须有产地、等级、规格（5斤装/10斤装）、采摘日期这些属性。
• 强时效性：叶菜放三天就黄了，草莓隔夜就软了。所以系统必须支持“预售”和“当日达/次日达”这类配送时段概念，而不是简单的下单后三到五天发货。
• 信任成本高：用户看不到实物，最担心的是“你寄来的东西跟图片上是不是一回事”。所以系统需要比普通电商更重视溯源信息——产地实拍、检测报告、农户信息，这些东西要能在商品详情页直接展示。
• 价格波动大：农产品价格受天气、批发市场行情影响很大，后台需要支持快速调价，而且最好能记录调价历史，方便后续统计。

1.2 你的系统边界应该划在哪里

基于上面的分析，这套系统的功能边界我建议这样划：

• 前端（微信小程序端）：用户注册登录、商品分类浏览与搜索、商品详情（含溯源信息）、购物车、下单结算（含配送时段选择）、订单列表与详情、售后申请（退款/退货）、个人中心（地址管理、优惠券、收藏）。
• 后端（管理端）：商品管理（上下架、规格、库存、调价）、订单管理（发货、取消、售后处理）、用户管理、 banner 管理、数据看板（销售额、订单量、热销商品）。

不要去做分销、拼团、直播带货这类花哨功能。毕业设计的工作量讲究“完整闭环”，把上面这条链路做到每个环节都经得起追问，比铺开十个半成品模块强得多。

1.3 这类题目的查重与原创性策略

很多学生担心题目太大众，查重过不去。这里有个思路可以让你脱颖而出：给系统加一个“社区团购 + 产地直发”的差异化定位。比如设计成小区团长代收模式——用户在小程序下单，商品先配送到团长自提点，用户再来自提。这个模式在技术上只需要增加“自提点管理”和“订单配送状态多一级流转”，但业务逻辑的完整度和真实感立刻就不一样了。答辩的时候你就可以说：“我的系统不仅仅是B2C，还包含了社区团购的S2B2C模式。”这句话拿出来，评分维度直接不一样。

2. 技术选型：用最稳妥的组合撑起完整闭环

技术选型的原则很简单：不求最前沿，但求最稳、最熟、最能讲清楚。你选的技术必须是你自己能驾驭的，因为答辩时老师会盯着你选型里的每一个组件问到底。

2.1 前端：原生小程序 vs uni-app

我推荐用原生小程序（WXML + WXSS + JS + 微信云开发或独立后端）。

理由有三点：第一，原生小程序是微信生态的第一方方案，文档最全，出问题容易搜到答案；第二，答辩时老师极大概率会问“你这个页面是怎么实现的”，原生小程序的组件生命周期、setData 数据绑定这些知识点你更容易讲透；第三，如果用了 uni-app，老师一句“那你说说 uni-app 里条件编译的原理”，很多人就卡住了。

如果你要适配 App 端，那另说，可以选 uni-app。但这里明确是做“微信小程序”，就用原生微信开发者工具。

2.2 后端：Spring Boot 是主流，但别忽略“轻量级”选项

如果你所在的学校主流是 Java 技术栈，那就用 Spring Boot + MyBatis Plus。理由不重复了，市面上 90% 的毕业设计都这么干，资料多，出问题好搜。想显得有点技术含量，可以在项目里加上 Spring Security 做登录鉴权，或者引入 Redis 缓存热门商品，但注意控制复杂度——每多一个组件，你就要多准备一份“为什么引入它”的答辩说辞。

如果你们学校更偏软件工程而非 Java 体系，也可以用 Node.js（Express 或 Egg.js）或者 Python（Flask 或 FastAPI）——对于中小型电商系统，这种轻量级后端开发效率更高。但前提是你对这门语言的并发模型、ORM 库有把握。我不建议在毕业设计里同时学一门新语言 + 一个新框架，风险太高。

另外要重点考虑一个方案：微信云开发（云函数 + 云数据库 + 云存储）。这个方案的好处是——不用自己买服务器、不用配域名备案、不用处理 HTTPS 证书，学生党零成本部署，而且开发效率极高。云函数天然就是 Node.js 环境，你用 JS 就能写后端逻辑。数据库是文档型的，对农产品商品这类“属性不固定”的数据非常友好。缺点是 NoSQL 对复杂事务支持弱，但毕业设计级别的订单流程完全够用。

我的建议是：如果后端基础一般，果断用微信云开发；如果后端有把握，就上 Spring Boot 写 REST API，小程序端用 wx.request 对接。两个方案都成立，关键是别中途摇摆。

2.3 数据库设计：农产品属性的核心建模

不管用 MySQL 还是云数据库，表结构的设计决定了系统能走多远。我直接给你一套比较完整的表设计思路：

用户表（user）

• id、openid（微信唯一标识）、昵称、头像、手机号、注册时间
• 这里加一个字段：user_type（普通用户/团长/管理员），为社区团购模式预留

商品表（product）

• id、名称、主图、详情图（多图用 JSON 数组存）、分类 id、产地、规格、单位（斤/份）、原价、现价、库存、销量、上架状态、创建时间
• 关键点：规格信息不要用字符串一把梭，至少拆成规格名（如“5斤装”）和规格值（如“净重5斤±0.2斤”）

溯源信息表（traceability）

• id、商品 id、采摘/生产日期、产地实拍图、质检报告图、农户简介
• 这是你的差异化卖点，前面 1.1 节说了“信任成本高”，这块表就是解决信任问题的

购物车表（cart）

• id、用户 id、商品 id、数量、选中状态

订单表（order）

• id、订单号、用户 id、团长 id（可为空）、商品总金额、配送费、优惠金额、实付金额、配送方式（快递/自提）、自提点 id、收货人姓名、电话、地址、配送时段、订单状态、创建时间、支付时间、发货时间、完成时间

订单明细表（order_item）

• id、订单 id、商品 id、商品快照（名称、图片、单价）、数量、小计金额
• 注意：这里一定要做“商品快照”，因为商品价格和名称后续可能变动，但订单里的历史信息不能跟着变

自提点表（pickup_point）

• id、名称、地址、团长 id、营业时间

售后表（after_sale）

• id、订单 id、用户 id、申请类型（退款/退货退款）、申请原因、金额、状态、处理时间

这套表不是凭空臆造的，每一张都对应一个真实业务动作。答辩的时候老师问“为什么订单表和订单明细表要分开”，你可以理直气壮地回答：“因为一个订单会包含多种商品，如果放在一张表里，那订单的地址、金额这些公共信息就要重复存储多份，会产生数据冗余和更新异常。”

3. 功能模块拆解：从登录到售后的完整主链路

系统设计的核心逻辑，就是“把用户从进入小程序到完成购买、再到处理售后的每一步都走通”。下面按用户视角逐个模块拆。

3.1 微信登录与会话保持

小程序端用 wx.login() 获取 code，然后传给后端（或云函数），后端调用微信的 code2Session 接口换取 openid 和 session_key。这个 openid 就是用户的唯一标识。

这里有一个容易踩的坑：不要每次打开小程序都走 wx.login()。正确做法是：首次登录时后端返回一个自定义登录态（比如 token 或 JWT），小程序把 token 存到 Storage 里，后续请求带着 token 走。原因很简单——微信的 code2Session 接口有调用频率限制，而且每次换取都会刷新 session_key，频繁调用既不安全，也没必要。

我在云开发方案里习惯的处理方式是：小程序端 wx.login() 拿到 code，云函数里调用 openapi 换取 openid，然后在 user 集合里查一下有没有这个 openid，有就直接返回用户信息，没有就自动注册一条新用户记录，同时生成一个自定义的 loginToken 返回给前端。

3.2 商品浏览与搜索

商品首页建议做成“分类 tab（顶部或侧边）+ 商品瀑布流”。农产品行业有个特殊性：用户往往不是带着明确购买意图来的，而是“看着看着就想买了”。所以首页要营造“逛”的感觉——轮播图放产地实拍和活动海报，下面接“今日推荐”“时令水果”“安心溯源”几个板块。

搜索功能要支持模糊搜索（搜“苹果”、“红富士”、“5斤”都能出来，这靠 SQL 的 LIKE 或者云开发的 db.RegExp 就能实现，不用上 elasticsearch）。

商品列表的加载方式，移动端普遍用“上拉加载更多，下拉刷新”，也就是触底分页。小程序里实现方法是在页面 json 里开启 enablePullDownRefresh，然后在 onReachBottom 里触发下一页的加载。分页参数用 page 和 pageSize，后端返回 total 和 list。这里有个性能优化点：用云开发的朋友，列表页只查商品表的必要字段（名称、主图、价格、销量），详情大图、溯源信息这些重字段等用户点击进详情页再查。

3.3 购物车与下单逻辑

购物车是老生常谈，不细说，但要说三个容易出错的点：

1. 库存校验必须放在下单接口后端做，不能只在前端判断。否则用户开两个窗口，前端看到库存 5 件，买了 5 件后又买 3 件，后端必须能拦住超卖。
2. 下单时锁定库存，支付超时后释放。这个机制叫“预扣库存”。订单创建后，给订单加一个状态——待支付，同时设置一个过期时间（比如 30 分钟）。当用户超过 30 分钟未支付，系统自动把订单取消，库存加回来。实现方式：Spring Boot 可以用延迟队列（RabbitMQ 的 TTL + 死信队列），云开发可以用定时触发器每分钟扫一次超时订单。
3. 运费计算：农产品客单价不高，运费直接影响转化。建议做阶梯运费——满 X 元包邮，不满收 Y 元。这个逻辑不要写在前端，后端算好金额返回给前端展示。

下单成功后的页面要清晰展示：订单号、实付金额、预计送达时间（如果选了配送时段）。在这个页面加一个明显的按钮：“微信支付”。微信支付需要小程序账号是企业主体或个体工商户，个人主体的小程序无法开通支付，这是一个硬门槛。如果确实没有支付资质，就做一个“货到付款”或“模拟支付”按钮，但在文档里要诚实说明这是模拟支付，后续可以替换成微信支付的原生流程。

3.4 订单状态机：不要让订单状态像一团乱麻

电商系统最核心的逻辑就是订单状态流转，这个状态机必须提前设计清楚，否则代码写到最后肯定乱套。我用的状态定义是：

• 待支付（已下单、未付款）
• 待发货（已付款、未发货）
• 待收货（已发货、快递配送中，或已到店待自提）
• 已完成（用户确认收货）
• 已取消（用户取消 / 超时未支付自动取消 / 商家取消）
• 售后中（用户发起退款退货）

状态机流转的核心约束是用一个统一的方法来更新状态，而且只允许特定路径的跳转，比如“待发货”可以直接跳到“已取消”，但“已完成”不能跳回“待发货”。在我的代码里，这个逻辑一般放在 service 层的changeOrderStatus(orderId, fromStatus, toStatus)里，每次更新都校验当前状态和期望状态是否一致，避免并发下的状态错乱。

3.5 售后流程：一个小小的差异化加分项

很多学生的系统里“售后申请”按钮是摆设。但如果你把售后流程做成闭环，答辩的完整度会显著提升。流程很简单：用户发起售后（退款/退货） → 商家查看 → 同意/拒绝 → 退款（模拟）或驳回 → 状态变更。后端只需要维护一张售后表和订单状态里的“售后中”标记，工作量不大，但体现的是“你想过这个问题”。

4. 关键代码落地：登录封装、购物车、动态数据和云开发

这部分直接上核心代码。我不会贴完整项目，而是把最容易被问到的几个关键链路的代码骨架给你，你拿到后结合自己的项目把上下文补齐。

4.1 小程序端 request 请求封装（工具类）

不管后端是 Spring Boot 还是云函数，小程序里对 wx.request 做一层 Promise 封装，是代码显得“工程化”的第一步。以下是我的封装习惯：

// utils/request.js const request = (url, method = 'GET', data = {}) => { return new Promise((resolve, reject) => { wx.request({ url: `${BASE_URL}${url}`, method, data, header: { 'Content-Type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else if (res.statusCode === 401) { wx.navigateTo({ url: '/pages/login/login' }); } else { reject(res); } }, fail: (err) => reject(err) }); }); }; module.exports = { request };

这段代码为什么这样写？因为第一，Promise 让页面里的调用变成 async/await，避免回调地狱；第二，统一在 header 里带 token，不用每次手动加；第三，401 统一处理跳登录页，方便后期维护。这三点答辩时值得主动讲出来。

4.2 云开发版：云函数实现“获取用户信息并注册”

如果你用云开发，登录逻辑做成一个云函数是最优雅的：

// cloudfunctions/login/index.js const cloud = require('wx-server-sdk'); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db = cloud.database(); exports.main = async (event, context) => { const { OPENID } = cloud.getWXContext(); const userCollection = db.collection('user'); const existing = await userCollection.where({ openid: OPENID }).get(); if (existing.data.length > 0) { return { code: 0, user: existing.data[0] }; } // 新用户自动注册 const newUser = { openid: OPENID, nickname: '微信用户', avatar: '', phone: '', user_type: 'normal', create_time: db.serverDate() }; const res = await userCollection.add({ data: newUser }); return { code: 0, user: { id: res._id, ...newUser } }; };

这个云函数的妙处在于：openid 通过cloud.getWXContext()直接从微信上下文拿，你根本不需要自己处理 code2Session 那套逻辑。云开发把微信鉴权这一步变成了“免费赠送”。

4.3 商品列表触底加载更多（页面逻辑）

小程序列表最常见的“上拉加载更多”，我直接给你们一套代码骨架。先看页面 js：

// pages/product/list.js const { request } = require('../../utils/request'); Page({ data: { products: [], page: 1, pageSize: 10, hasMore: true, loading: false, }, onLoad(options) { this.loadProducts(true); }, onReachBottom() { if (this.data.hasMore && !this.data.loading) { this.loadProducts(false); } }, onPullDownRefresh() { this.loadProducts(true).then(() => wx.stopPullDownRefresh()); }, loadProducts(reset) { const page = reset ? 1 : this.data.page + 1; this.setData({ loading: true }); return request(`/product/list?page=${page}&pageSize=${this.data.pageSize}`) .then((res) => { const list = res.data.list; const hasMore = list.length === this.data.pageSize; this.setData({ products: reset ? list : [...this.data.products, ...list], page, hasMore, loading: false, }); }) .catch(() => { this.setData({ loading: false }); }); }, });

这段代码里我用hasMore判断当前页返回的数量是否等于 pageSize，相等说明下一页可能还有，否则就停了。注意loading这个变量——它的作用是在接口还没返回时，阻止 onReachBottom 再次触发，否则用户快速上拉会发出去五六个重复请求。

4.4 Spring Boot 后端的分页接口写法（如果走独立后端）

如果后端是 Spring Boot，Controller 里这样写分页查询就不容易出错：

@GetMapping("/product/list") public Result Page<ProductVO> list(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) String keyword, @RequestParam(required = false) Long categoryId) { Page<Product> pageParam = new Page<>(page, pageSize); LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), Product::getName, keyword) .eq(categoryId != null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getSales); Page<Product> productPage = productService.page(pageParam, wrapper); // 将 Product 转成 ProductVO 返回，隐藏 internal 字段 return Result.success(productPage); }

注意两个细节：一是我没有把数据库实体直接返回给前端，而是转成了 VO（View Object），这样商品的 createTime、updateTime、status 这些内部字段就不会暴露；二是用了 LambdaQueryWrapper 的条件构造器，where 条件按需拼接，关键字为空时不会生成LIKE '%%'这种无效查询，避免全表扫描。

4.5 购物车“选中状态 + 总价计算”是一个标准坑

购物车最容易被问到的逻辑是：勾选商品、反选、全选，然后总价实时变化。这个只要坚持一个原则就好：data 里永远存购物车列表，总价永远通过一个计算方法在页面渲染时实时推导，不要单独存一个 total 变量。因为只要单独存 total，你就一定会遇到“某个商品勾选状态变了但 total 忘了更新”的 bug。

实现上按钮勾选用 bindtap 或者 checkbox 的 change 事件，每次变化重新调用一次this.calcTotal()，遍历一下所有 check 的商品，把 price * num 累加。

5. 系统上线与演示：避开那些“演示时当场翻车”的坑

很多人的项目代码没问题，但演示时因为环境准备不充分而翻车。以下几条是我认为最重要的演示前自检项。

5.1 数据库与云环境的环境隔离

如果你是独立后端 + MySQL 方案，演示时一定用本地数据库，并且要注意本地 MySQL 服务是否自启动。如果你在服务上部署，跨网络访问数据库会很慢，演示现场网络一波动就白准备了。

如果你是云开发方案，最关键的一点：区分开发环境和生产环境。云开发默认有两个环境，能创建两个环境的话最好——开发环境存测试数据，生产环境存演示数据。千万不要在演示现场才发现测试数据把演示页面的数据搞乱了。

5.2 图片资源与网络加载

商品图片不要全用网络 URL（比如自己电脑上跑接口返回的本地图片地址）。微信小程序最大的坑是：真机调试时 localhost 指向的是手机自己，不是你电脑。正确做法是，把图片传到云存储（云开发方案）或用 OSS 对象存储，然后存文件 URL。如果只在本机开发工具里预览，用 localhost 无所谓；一旦你要用手机预览和演示，必须保证所有图片资源走公网 URL。

5.3 微信开发者工具的“不校验合法域名”选项

如果你用独立后端 + HTTP（不是 HTTPS），开发工具会报域名校验失败。小程序正式上线之前必须配置 HTTPS 安全域名，但开发阶段可以在详情面板里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”——这句话几乎每个做小程序的人都要用一次，但是很多人忘了演示前确认这个勾选是否还在。真机预览时，这个小勾必须是在“开发版”模式下才能关闭，体验版和正式版线上资源不受此选项影响。

5.4 理清小程序三种版本的区别

这个小程序项目里最容易混的概念就是预览版、体验版、正式版。我帮你理一理：

• 预览版（开发版）：在开发者工具中点击预览，在手机上生成一个临时二维码，这个版本仅供你自己的微信使用，码有效期较短。适合开发自测。
• 体验版：从开发者工具后台“上传”代码后，在 mp 后台里把上传的开发版本设为体验版。体验版可以让项目成员（最多不超过一定数量）扫码打开。适合给同学、舍友模拟试用。
• 正式版（发布版）：后台提交审核，审核通过后用户才能搜索到。个人主体的可在部分场景下省略支付等受限功能后提交审核。

毕业设计演示，用体验版就足够了——先在手机上打开体验版，你就不用一直抱着电脑转向观众，评委可以亲手点一点。提前让两三个同学扫码试试，看有没有奇怪的兼容性问题，这是最有效的一种排雷方式。

5.5 演示时候的“剧本”

演示不要一上来就打开商品列表刷来刷去，那会让评委觉得乏味。我建议按这个节奏来：

1. 三十秒讲业务背景：“农产品零售存在信息不对称、信任感缺失的问题，所以我做了一个社区团购+产地直发的平台，用户可以查看产地溯源信息，也可以选择配送到家或来自提点自提。”
2. 演示核心链路：浏览 → 看溯源信息 → 加入购物车 → 下单 → 模拟支付 → 查看订单状态。
3. 展示管理端：在电脑上打开后台管理界面，演示“发货”操作，然后回到小程序端刷新订单状态，让评委看到一个完整的闭环。
4. 展示数据库设计：翻出你的 ER 图，简单讲几张核心表的关系。多数老师喜欢在此时打断提问，这是你展示基本功的机会。

6. 答辩准备：把“提问环节”变成你的加分项

答辩确实没有什么特别的技巧，主要就看你对项目的理解深度。我把自己被问过、以及帮学生模拟时经常被问到的题目列几个，你在准备期间一一对着自查：

6.1 必问题：为什么选微信小程序而不是 APP？

回答思路不要只说“成本低、开发快”，要做对比分析：小程序获客成本低，即用即走，适合农产品这种低频、刚需、以社区为单位的消费场景；APP 需要下载安装，对中老年用户不友好。同时小程序能直接使用微信支付和微信地址本。这样回答既讲商业逻辑又讲技术逻辑，比一句“因为方便”丰富得多。

6.2 高频题：你的系统如何保证数据一致性？

这里考察的是订单和库存、订单和支付之间的关系。你可以说：下单时用数据库事务（Spring 里 @Transactional / 云数据库的db.runTransaction）保证扣库存和创建订单记录在一个原子操作里完成；订单创建与支付之间的状态同步通过定时任务补偿。不需要讲得很深，但必须让老师知道你想过这个问题。

6.3 深度题：商品下架了，但用户购物车里还有怎么办？

这个坑很多项目都有，但你提前想好就成加分点。我的处理：购物车列表每次查询时，当场校验商品状态；如果商品已下架，在返回列表里加一个字段invalid: true，前端置灰显示，结算时拦截；如果库存不足，提示“库存不足，请调整数量”。这个思路并不难，但绝大多数毕业设计不会处理，你做了就超过一半的人。

6.4 送分题（但很多人真的答不上来）：微信小程序如何获取用户手机号？

现在小程序获取手机号必须通过按钮开放能力<button open-type="getPhoneNumber">，并且在后台配置合法调用接口权限。个人开发者的小程序没有这个权限，学校院内演示不受影响，但你要能说清楚门道。千万别回答“前端直接调一个 API 拿手机号”——微信早就把这条路堵死了。

6.5 思维题：如果是你，下一步打算怎么扩展？

我推荐的回答：一是引入“预售 + 定时配送”模型；二是用生成分享海报的方式做社区裂变；三是接入微信订阅消息，在订单状态变化时给用户推送提醒（这个技术上是小程序订阅消息 template message，能说上这个名词，说明你了解过真实的接口能力）。

7. 源码、文档和作品集的整理策略

最后的这一步，直接影响你这套东西能不能成为作品集里拿得出手的一页。

源码的目录结构一定要清爽。建议按前端、后端、数据库脚本、文档四层来组织。别再散落一地的final_final_v3压缩包。Git 仓库是一个好选择，加上清晰的 README，把启动步骤写清楚（怎么启动后端、怎么导入数据库、怎么在开发者工具里打开小程序）。如果你用云开发，前端目录可以直接放到miniprogram/子目录，云函数放cloudfunctions/子目录，这是官方推荐的结构，答辩时评委一看就懂。

文档方面，按照一般学校毕设的要求，至少要有开题报告、需求分析、系统设计、测试报告这几部分。这里我给一个很多人容易忽略但很看重的部分：测试报告不要只写功能测试，加几条边界测试和异常流程的用例。比如“用户下单时库存只剩 1 件，另外两个账号同时下单会怎样”这种用例，能显著提高报告的可靠性。

作品集展示页面同理：几张关键的页面截图 + 一句业务定位 + 你最有技术含量的两个点（比如“基于事务的预扣库存机制”“基于云函数的免鉴权登录方案”）。这不是凑字数，而是简明扼要地把作品的记忆点刻给看到的人。

这个题目做完，你会对小程序生命周期、前后端交互、电商状态机、数据库事务这些真实工程问题有切实的体感。这些经验是那些在教程里敲一百个 demo 都换不来的。我个人在带毕业设计项目时最大的体会就是：分数高低不在功能多，而在于你有没有真正把业务想明白。农产品销售系统这个题目本身不新，但只要你把“农产品”这个业务的特殊性做出来，把溯源、社区自提、预售这些点讲透，你的项目就是有辨识度的。

最后分享一个技术之外的小建议：答辩前一天，把手机调成飞行模式再打开一次你的小程序体验版。如果页面该出的数据都出了，说明你的系统没有强依赖本地后端服务。万一现场网络出幺蛾子，你至少有一个兜底方案——提前把关键页面截图存在相册里。别问我是怎么知道这个坑的。