这个项目我从立项到交付前后大概折腾了三周。基于微信小程序的购物平台说直白一点就是一套前后端分离的商城系统小程序端负责用户看得见的商品浏览、搜索、购物车、下单、支付、订单查询这些页面后端负责账号、商品、库存、订单、配送这些核心数据的管理。最终交付物里面包含了完整的前端源码、后端源码、数据库初始化脚本以及配套的设计文档标题里那串 69715 是我归档时的项目版本号。如果你正考虑拿这类题目做计算机毕设或者想快速搭一个小程序商城原型这篇内容应该能帮你少走不少弯路。购物平台这个题目看起来简单真正动手之后才发现大部分时间不是花在写页面而是耗在登录态、支付回调、并发扣库存这些又碎又关键的环节上。我下面会按照实际做项目的顺序从技术选型开始逐步讲到数据库设计、核心接口、页面实现、常见坑和答辩准备全程以能复现为目标。1. 项目整体设计与技术选型1.1 为什么最终选择微信小程序做购物平台摆在眼前的选择其实有不少原生 AppAndroid、iOS、鸿蒙、H5 商城、跨端框架以及微信小程序。我最终选了微信小程序核心原因是这个场景下它的“触达成本”最低。用户不用下载安装微信里扫个码或者搜索一下就能进店毕设答辩的时候考官拿手机扫一下就能看到完整效果演示环节会非常顺畅。从开发成本上看小程序也有明显优势。原生 App 要同时考虑 Android、iOS 以及新版鸿蒙的适配光打包签名、各渠道发布就是一堆事H5 商城虽然开发快但很多设备能力和支付体验不如小程序顺滑而且无法直接调用微信登录和微信支付等于砍掉了购物场景里两条最核心的链路。小程序依托微信生态登录、支付、分享这些能力都是现成的能把精力集中在业务逻辑上。需要说明的是也有不少同学喜欢用 uni-app 来做一套 Vue 代码编译到多端这个方案本身没问题优点是可以低成本扩展到 App 和 H5缺点是多学一层框架封装遇到底层问题时排查链路更长。我这个项目用的是小程序原生开发一是为了减少依赖让源码更容易看懂二是在毕设评审时讲清楚 WXML、WXSS、JavaScript 的基础内容本身就属于课程要求的范畴整体更“对口”。1.2 技术栈与总体架构购物平台采用前后端分离结构。后端我用的是 Spring Boot 2.7 MyBatis Plus MySQL 8 Redis小程序端用原生小程序框架配合 Vant Weapp 组件库。选 Vant 的主要原因是它的商品、按钮、弹层组件比较完整能省掉大量自定义样式的时间而且长期维护文档靠谱遇到问题容易搜到解决方案。文件存储这块商品图片没有放在服务器本地而是放在对象存储里。理由很现实小程序打包大小有 2MB 上限图片不可能塞进代码包后端服务器磁盘空间有限图片多起来后静态资源会拖垮应用吞吐。对象存储通过临时签名的方式让小程序直接上传图片服务器只保存图片 URL磁盘和流量压力都能控制住。实测下来图片走 CDN 之后详情页首屏加载速度比从服务器拉图快一倍还不止。支付环节接的是微信支付。需要提醒的是正经的微信支付需要商户号个体户或公司才能申请学生个人通常没有。毕设项目一般可以先用沙箱或模拟支付流程代替后面我会单独讲这套模拟方案怎么设计得让考官挑不出毛病。整个工程的请求链路是小程序端通过wx.request发起请求到后端网关层网关校验 JWT然后请求进入业务模块数据写入 MySQL热点数据缓存到 Redis。登录态用 JWT 存 tokenRedis 用来放验证码、购物车临时数据和分布式锁。1.3 功能模块怎么拆购物平台按角色可以拆成三端。用户端登录注册、首页推荐、分类浏览、关键词搜索、商品详情、购物车管理、下单结算、支付、订单列表、订单详情、取消订单、确认收货、收货地址管理、优惠券领取与使用。管理端后台商品分类管理、商品上架下架、库存调整、订单列表、订单发货、退款处理、用户列表、数据看板。数据看板至少要有今日订单数、交易额、热销商品 Top10 这几个核心指标。后端接口侧每个模块对应一组 RESTful 接口统一走/api/user、/api/product、/api/cart、/api/order、/api/admin这样的前缀。接口返回统一封装为{ code, message, data }前端在封装层统一解析业务异常不手写try-catch减少重复代码。模块拆分的思路是“高内聚、低耦合”商品模块不依赖订单模块订单模块通过商品模块查询商品快照购物车和优惠券模块互相独立最后在下单时聚合计算。这样拆完之后每个模块都能单独测试也更容易给答辩评委讲清楚模块边界。这里补一句经验不要在项目初期就把优惠券、秒杀、积分商城这些“加分项”全部加进去。先把商品、购物车、订单、支付这条主链路跑通再加增值功能会从容得多。我第一版就是被优惠券规则拖了两个星期回头想想完全没有必要。2. 数据库设计与核心业务逻辑2.1 数据表设计与字段说明购物平台数据库我设计了 10 张核心表对应如下。表名用途关键字段user用户表id, openid, nickname, avatar, phone, statuscategory分类表id, name, parent_id, sortproduct商品表id, category_id, title, price, stock, main_image, statusproduct_sku规格表id, product_id, name, price, stock, imagecart购物车表id, user_id, sku_id, quantity, checkedaddress收货地址表id, user_id, name, phone, province, city, detailorder订单表id, order_no, user_id, total_amount, pay_amount, status, create_timeorder_item订单明细表id, order_id, product_id, sku_id, title, image, price, quantitycoupon优惠券定义表id, name, type, amount, threshold, total_countuser_coupon用户优惠券表id, user_id, coupon_id, status, expire_time字段命名统一用下划线风格日期字段统一用datetime金额字段用decimal不要用float否则对账的时候会被精度坑到怀疑人生。订单号我采用“前缀 日期 随机数”的方式生成例如ORD202506071234567方便按时间维度检索也为唯一索引提供了基础。order 表里故意存了total_amount和pay_amount两个字段前者是商品原价合计后者是优惠后实际支付金额这样设计是为了后面做订单对账和营销统计时能直观看到每单减免了多少。另一个容易忽略的设计是order_item里冗余了title、image、price这是订单快照。商品标题和价格可以随时修改但订单里的快照必须定格在下单瞬间否则用户历史订单里显示的价格和商品信息会跟着变这是购物系统初稿最常见的错误之一。2.2 订单状态机怎么设计订单管理是购物平台里逻辑最复杂的部分。我一开始用字符串字段硬编码状态改了几版之后自己都分不清当前状态后来重新梳理成状态机模型可读性一下子好了很多。订单状态枚举public enum OrderStatus { PENDING_PAYMENT(0, 待付款), PAID(1, 已付款待发货), SHIPPED(2, 已发货待收货), COMPLETED(3, 已完成), CANCELLED(4, 已取消), REFUNDING(5, 退款中), REFUNDED(6, 已退款); }状态流转规则要写清楚待付款可以取消也可以支付进入待发货待发货可以由商家发货进入待收货待收货可以确认收货进入已完成待付款和待发货阶段可以申请退款进入退款中退款成功后变成已退款已取消和已完成属于终态不允许再变更。后端在更新订单状态时SQL 要带状态条件比如UPDATE order SET status 1 WHERE order_no ? AND status 0这样能防止并发场景下重复支付、重复发货导致状态跳变。代码层面再配合 Redis 分布式锁不管用户点击多快订单状态都不会乱跳。我实测过不加状态条件的版本在支付回调延迟时会出现“已支付订单被取消”的问题加了条件后彻底解决。2.3 购物车、下单和库存扣减购物车表的结构比较简单一个用户对应多条记录字段里设置了user_id sku_id唯一索引防止同一商品被重复插入。前端传增减数量时后端先查询再更新避免整行重写。下单环节的核心事务包含四步校验地址、校验并扣减库存、计算价格、生成订单和明细。库存扣减我用的不是先读后写而是带条件更新UPDATE product_sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}这条 SQL 利用数据库自身对库存数量的限制如果影响行数为 0说明库存不足直接返回“库存不足”。这个方案比“先 select 后判断再 update”的方案好因为它把并发控制下沉到了数据库行锁层面不会出现超卖。价格计算流程是商品总价等于遍历购物车选中项取每个 SKU 当前价格乘以数量再累加优惠金额等于判断用户选中的优惠券是否满足门槛满足才减免支付金额等于商品总价减去优惠金额。所有金额统一使用分来存储和计算展示时再除以 100 转成元避免浮点问题。下单完成后删除购物车中对应的选中项如果支付超时后端定时任务会自动取消订单并归还库存。库存归还的时机也有讲究用户下单后 15 分钟未支付订单自动取消并释放库存但用户已经支付的情况库存已经扣减不应该自动释放。这里我通过一个延迟任务扫描PENDING_PAYMENT状态超过 15 分钟的订单来处理规则简单且不易误伤。3. 前端页面搭建与接口对接3.1 小程序目录结构与页面划分小程序端页面我按照业务拆成 5 个 tab 页面加上若干子页面整体目录如下miniprogram/ ├── api/ │ ├── request.js │ ├── product.js │ ├── cart.js │ └── order.js ├── pages/ │ ├── index/ # 首页商品推荐位 │ ├── category/ # 分类页 │ ├── cart/ # 购物车 │ ├── order/ # 订单列表 │ └── mine/ # 个人中心 │ ├── product-detail/ # 商品详情 │ ├── checkout/ # 结算页 │ └── address-add/ # 新增地址 ├── components/ │ ├── product-card/ # 商品卡片组件 │ ├── empty-state/ # 空状态组件 │ └── price/ # 价格展示组件 └── utils/ ├── format.js # 格式化工具 └── auth.js # 登录态管理首页我放了搜索框、分类快捷入口、推荐商品瀑布流。分类页是左右两栏布局左侧一级分类列表右侧二级分类和商品。购物车页面需要支持多选、全选、数量增减、金额实时计算。订单列表按状态做 tab 切换支持下拉刷新。个人中心放头像、昵称、订单入口、地址管理和优惠券。实现上的关键是复用组件。商品卡片在首页、分类页、搜索结果页、猜你喜欢里都用到了所以单独抽成product-card组件接收一个商品对象作为属性内部完成价格格式化和图片懒加载。这样改 UI 只需要改一个组件不用四个页面各改一遍维护成本低很多。3.2 请求封装与登录态管理小程序里所有接口请求我统一封装在api/request.js里核心就做三件事携带 token、统一错误处理、解析统一响应结构。const request (path, method GET, data {}, needAuth true) { return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${path}, method, data, header: { Content-Type: application/json, ...(needAuth wx.getStorageSync(token) ? { Authorization: Bearer ${wx.getStorageSync(token)} } : {}) }, success: (res) { if (res.statusCode 401) { handleLoginExpired() reject(new Error(登录已过期请重新打开小程序)) return } if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) return } wx.showToast({ title: res.data.message || 请求失败, icon: none }) reject(new Error(res.data.message)) }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }登录态这里有个容易被忽略的细节wx.login拿到的code是一次性的后端拿它换openid和session_key后要立刻丢弃。因为我没用微信云开发而是自建后端所以用户表里存openid作为唯一标识后端签发出 JWT 给小程序端。JWT 有效期我设置 7 天过期后前端请求返回 401这时候再调wx.login换新 token用户无感知续期。很多项目在登录态上翻车是因为把wx.login当成常规登录手段每次进页面都调甚至放到app.js的onLaunch里。实际上wx.login有频率限制乱调用会导致session_key频繁更新还会拖慢启动速度。静默登录应该只在三种时机触发首次进入、token 不存在、请求返回 401。封装好的 request 里已经处理了 401页面里正常调用 api 函数即可不用每页自己判断登录状态。3.3 商品列表分页与加载优化商品列表不能一次性把全部分类商品返回数据量大之后接口响应会明显变慢小程序端滚动也会卡。我统一采用“分页 下拉刷新 上拉加载”的方案接口参数固定为page和pageSize返回内容里附带total和hasMore。// 搜索或分类商品 async function fetchProducts(page) { const res await getProductList({ categoryId, keyword, page, pageSize: 10 }) this.setData({ products: page 1 ? res.list : this.data.products.concat(res.list), hasMore: res.hasMore, page }) }页面要配合onReachBottom触发加载更多判断条件是hasMore !loading避免用户快速上拉时发出重复请求。我在实际测试中发现如果不在底部做wx:if控制列表经常会出现空白或重复数据所以专门加了一个loading状态和empty状态组件数据为空时显示“暂时没有更多商品”不会一直转菊花。图片懒加载我用的是小程序自带的image组件的lazy-load属性配合 CDN 缩略图参数列表页首屏加载速度提升明显。这个优化做与不做在真机上差别很大特别是商品图多的情况建议在答辩演示之前优先处理。3.4 支付流程对接与模拟方案真实微信支付流程是小程序端请求后端创建订单后端调用微信支付统一下单接口拿到支付参数timeStamp、nonceStr、package、signType、paySign返回给小程序端小程序端调wx.requestPayment拉起支付面板支付结果通过后端回调接口通知。由于个人开发者在毕设阶段往往没有商户号我用了一套不影响演示效果的模拟支付方案支付按钮点击后弹出确认弹窗输入任意模拟密码前端调用“模拟支付”接口后端直接把订单状态从待付款改成已付款待发货同时打印一条日志模拟回调。为了让答辩更有说服力我把流程设计成两段第一段是模拟前端支付第二段是模拟后端回调。两个接口独立可以清楚展示“前端支付成功后后端回调确认订单”的逻辑和真实微信支付的结构完全对应。async function mockPay(orderNo) { const res await payOrder({ orderNo }) if (res.code 0) { wx.showToast({ title: 支付成功, icon: success }) wx.redirectTo({ url: /pages/order/order?status1 }) } }如果以后申请下商户号只需要把payOrder接口里的内部逻辑替换成真实的统一下单和回调验签页面层基本不用改动。这个设计在答辩时本身就是个亮点能体现对“解耦”的理解。4. 实操中躲不开的坑与调试记录4.1 登录态过期用户突然变访客第一次联调的时候遇到一个迷之现象用户在小程序里逛得好好的突然购物车数据全没了页面身份也变成了未登录访客。定位之后发现是 JWT 过期前端拿到 401 后把本地 token 清掉了但没有重新走一遍wx.login静默登录流程。正确做法是在请求层里做一个“单飞”的登录刷新逻辑收到 401 时记录当前请求调用wx.login拿到新 code后端换新 token然后重放请求同时避免多个并发请求同时触发wx.login我用一个isRefreshing标志位加 Promise 队列来处理。实测下来最稳定的是把登录接口和业务接口拆分让 401 时统一走handleLoginExpired()页面完全无感知。另一件容易踩的事是不要在小程序启动时无条件调用wx.login否则每次打开小程序都会刷新session_key后端session_key更新的同时原来缓存的解密数据就可能失效。正确做法是只在确有需要时才调例如用户打开个人中心、准备下单或支付前。4.2 并发下单库存变负数有段时间压测时发现商品库存变成了 -5。原因很简单下单库存扣减用的是“先查询库存再在内存里判断然后 update”三段式逻辑高并发下两个请求同时读到 stock3都判断够用然后都执行 update最终库存变成负值。修复方案就是前面讲的条件更新 SQLstock stock - #{quantity} WHERE stock #{quantity}。库存扣减这个动作绝不能靠应用层判断一定要用数据库条件更新。如果商品支持多 SKU还需要注意同一商品多 SKU 之间的库存联动防止“SKU A 库存充足但该商品整体库存已不足”这种数据错乱。处理完库存后还要补一个兜底逻辑订单超时未支付被自动取消时归还库存的 SQL 也必须用条件更新。否则在高并发或任务重复执行的情况下同一个订单可能被取消两次库存被归还两次导致库存虚增。我在定时任务里加了任务幂等标记规定每个订单只能被处理一次同时用数据库唯一索引防重双保险之后库存数据才算稳定。4.3 文件上传与 OSS 签名过期商品图片上传我最初是在后端先把图片接收下来再转发到对象存储结果小程序上传大图时经常超时而且后端带宽被打满。后来改成“后端生成临时签名小程序直传对象存储”上传过程不经过后端速度快了很多。这里有一个签名有效期的问题小程序端拿到签名后如果用户停留在选图页面太久签名过期再上传就会报 403。处理办法是把签名有效期设长一点比如 30 分钟同时上传失败时重新请求签名。另外图片上传前要在前端统一做压缩小程序wx.compressImage可以把 2MB 以上的图片压到 200KB 以内既省流量也加快上传速度。4.4 常见问题速查表问题典型现象排查思路最终处理登录态失效页面数据全部消失用户变访客看网络请求是否 401请求层静默续期重放请求库存变负并发下单后库存为负数查看 SQL 是否条件更新update ... where stock n图片上传 403选图后直传报权限错误检查签名是否过期前端压缩失败重取签名页面栈超限连续跳转 10 层后无响应navigateTo层数超限用redirectTo或reLaunch替代支付回调延迟用户已支付但订单仍待付款回调接口未及时更新状态支付后前端轮询 回调幂等真机上 onReachBottom 不触发上拉加载无反应页面高度或滚动容器问题检查是否使用自定义scroll-view排查这些问题时我强烈建议把后端接口的详细请求日志打开日志里至少要包含时间、用户标识、接口路径、入参、返回值。小程序端的报错和真机调试面板信息也要关联起来看很多时候问题不在小程序代码而在后端接口返回的数据结构不合预期。5. 打包部署、演示与答辩要点5.1 小程序提交审核与上线小程序开发完成之后在微信开发者工具里上传版本然后在管理后台提交审核。审核需要注意几个点类目要选“电商平台”或“购物”需要提供相关资质小程序里不能出现“测试数据”字样不能有虚拟支付隐私协议弹窗必须配置尤其涉及用户手机号、收货地址的场景。我见过不少项目功能都做完了结果卡在隐私协议审核上返工一次至少一周。如果只是毕设演示不走正式上线流程也需要在成员管理里把自己添加为体验成员。添加之后手机微信扫码就能打开体验版功能与正式版完全一致足够支撑答辩现场的完整演示。这个小配置很容易被忽略我建议在答辩前一周就处理好避免临场发现二维码失效、成员权限不对手忙脚乱重新上传版本。5.2 真机调试与域名配置运行时权限、上传、支付这些能力在开发者工具里模拟和在真机上差别非常大。我建议至少在答辩前一周开始用真机调试重点看网络请求是否走通了 HTTPS域名是否已经在后台配置合法。小程序正式环境要求所有请求域名必须是 HTTPS 且已经备案本地开发可以使用开发者工具的“不校验合法域名”选项但体验版和正式版不能依赖这个开关。后端部署我用的云服务器项目打成 jar 包配合 systemd 守护进程运行MySQL 和 Redis 单独跑在 Docker 容器里。如果学生党没有云服务器也可以用一个简单方案后端跑在本地局域网用内网穿透工具把回调地址映射到公网小程序开发版把请求地址指向穿透地址。注意免费穿透工具稳定性一般答辩现场容易出状况有条件还是尽量用正式域名加云服务器。5.3 答辩讲解思路答辩时间通常只有 10 到 15 分钟不要按代码逐行讲。我建议按这条主线讲选题背景与意义 → 系统总体架构 → 数据库设计挑订单表讲状态机 → 核心流程挑下单和支付讲事务 → 系统测试与演示。中间穿插两个亮点即可比如订单状态机的条件更新防超卖或者小程序直传对象存储的性能优化。真正打动评委的不是页面多好看而是你在某个点上能讲清楚“为什么这么设计”。我自己准备答辩时重点准备了三个问题一是为什么订单表单独做快照字段二是并发扣库存为什么不用应用层锁三是登录态为什么用 JWT 而不是 session。这三个问题只要答得流畅基本就能覆盖大部分追问。5.4 源码使用建议与注意事项拿到这套源码之后第一件事不是急着跑起来而是先配置文件。后端要改 MySQL 连接信息、Redis 连接信息、对象存储的 AccessKey 和 SecretKey小程序端要改BASE_URL为你的后端地址。数据库初始化脚本执行后建议先用自带的管理员账号添加分类和商品再切到小程序端看数据是否正常展示。代码里凡是用到微信支付、对象存储、短信服务的地方如果对应资源都没有可以先走模拟模式。注释里已经标了这些开关的位置搜索mock或local关键字就能找到。有一点提醒源码能跑起来只是第一步答辩时一定要能讲清楚每一块业务代码在做什么不然评委随便问一个模块的字段含义就会露馅。建议动手把订单、购物车、库存这三个模块的代码自己重写一遍这个理解程度比盯一天屏幕有效得多。到这里整个购物平台的实现主线就完整了。我个人在实际开发中最深的感觉是购物平台这个题目非常“稳”它覆盖了前端交互、数据库设计、接口设计、并发控制和第三方服务对接几乎找不到比它更均衡的毕设选题。源码拿到手之后动手跑通主流程再自己改一两个模块比任何细节都重要。最后再补一句实操体会答辩前一定要真机跑一遍完整下单流程从加购物车到订单列表确认状态每一步都截图存档演示时哪怕网络抖动也能靠截图把流程讲完整。