简介面向微信小程序课程设计与毕业设计场景的商城项目源码包适合需要完成商城类小程序作业、答辩演示或二次开发练习的学生与初学者。内容围绕商品展示、分类发现、购物车、支付、消息与个人中心等常见模块组织页面结构完整代码附带注释便于理解小程序端的页面、样式与逻辑协作方式。压缩包共68个文件约3.31MB主要由png、jpg等界面素材js业务脚本wxss样式wxml结构与json配置组成另含txt使用说明便于按目录快速定位页面和资源。已有1243人学习说明该选题与实现方式具有一定参考价值。读者可据此梳理商城小程序的目录组织、页面跳转、数据绑定与静态资源管理并结合数据库脚本、部署说明完成环境搭建和运行调试也可作为课程设计模板进行功能扩展与界面调整。1. 从一份能跑通的商城说起这套方案要解决的三个交付问题微信小程序商城的毕业设计最常翻车的不是功能写不出来而是收尾时发现手里只有一堆页面数据库建表脚本没有后台接口是写死的假数据教程只有一句「自己看代码」。这套基于微信小程序的商城方案把源码、数据库脚本和一份能跟着操作的教程放在一起解决的就是「跑得起来、说得清楚、答得上来」这三件事。它适合正在做小程序方向毕业设计或课程资源整理的学生也适合想拿一套完整电商闭环做参考的开发者——商品、购物车、订单、支付、后台管理这条主线是贯通的不是只有一个首页好看的空壳。下面按「需求怎么定、架构怎么切、模块怎么写、哪里会炸、怎么验收」的顺序把这份方案拆开讲一遍。2. 需求拆解与技术选型三类角色、两个端、一条主线做商城类毕业设计第一个要做的动作不是打开编辑器建工程而是把功能清单按角色切开、按优先级排一遍。切不清角色的后果是页面写了三十个答辩时老师说「你这个后台在哪」你只能说「后台没做重点在前端」。2.1 三类角色的功能边界买家端做闭环管理端做管控数据端做客诉买家端的验收标准只有一条——能从头走到尾。首页轮播与推荐位 → 分类页 → 商品列表 → 商品详情 → 加入购物车 → 确认订单选地址、算运费、用备注→ 支付 → 订单列表 → 确认收货 → 评价。这条主线上任何一环断了演示就得靠切页面硬撑过去很容易被追问到答不上来。支线功能包括搜索、收藏、收货地址管理、个人中心、售后申请这些属于「有更好、没有也能及格」的部分。管理端不是摆设它承担了整个系统里唯一能改动数据状态的入口。商品的新增、编辑、上下架、改库存订单的查看、发货、备注分类与轮播图的维护再加一个简单的数据看板今日订单数、成交额、待发货数量。管理端通常用一套 Web 页面实现不需要做得漂亮但必须能改数据——答辩时老师让你「把这个商品下架看看前台什么样」你得当场点得出来。数据端说的是数据库这一层要能自证。表结构、字段注释、索引、初始化数据这四样在交付物里必须是独立的、可执行的脚本。我一般会把建表语句和十几条测试数据放在同一个 SQL 文件里导入就能跑省得答辩现场还在那儿一条条 insert。功能取舍上有一条血泪经验八到十二周的周期里砍掉优惠券、拼团、秒杀、分销这类营销模块把订单状态机和库存扣减做扎实比堆十个花哨功能更容易拿分。营销模块的逻辑往往是「算一笔账」讲起来热闹但真正的工程难度在并发下的数据一致性而后者才是能撑起答辩内容的东西。2.2 技术栈取舍原生小程序配自建服务端还是云开发一把梭小程序端有四种常见选择各自的代价差别很大选之前先想清楚你要在答辩上「讲什么」。方案上手成本后端工作量可讲述性真机踩坑密度适合的场景原生小程序 自建服务端中高事务、索引、接口分层都能讲中想拿中高分、愿意花时间写后端原生小程序 云开发低低后端被平台藏起来了低周期紧、只求跑通跨端框架 自建服务端中高高高编译产物出问题难排查需要同时出 H5 或 App纯静态 假数据极低无极低不建议答辩很难过关这份方案走的是第一条路小程序端用原生 WXML/WXSS/JS服务端用一套常规的 MVC 后端Java 系或 Node 系都行结构是通用的数据库用 MySQL。理由很直接——毕业设计的评分表里「工作量」和「技术深度」是两项硬指标云开发把后端藏进平台里了老师问「库存是怎么扣的、并发下会不会超卖」你只能回答「平台帮我处理了」这句话在答辩现场基本等同于没做。小程序端有几个绕不开的点选型阶段就要认下来。主包体积有上限商品详情页的富文本和图片多通常要做分包把订单、个人中心这类二级页面拆到子包里。图片不能放本地得走对象存储或者图床而且域名要配到小程序的合法域名列表里否则真机上一个图都加载不出来。网络请求要统一封装不能每个页面写一遍wx.request否则后面加 token、加错误提示、加 loading 就是三十个文件挨个改。服务端这边接口按「控制器 → 服务 → 数据访问」三层组织就够了不需要上微服务那套。毕业设计的体量一个人维护的代码分层太细反而是负担。真正需要认真对待的是三件事统一响应格式、事务边界、以及幂等处理这三样后面会单独展开。2.3 数据表与状态机设计订单状态是全系统的主线商城系统的表不多核心八张用户、分类、商品、购物车、收货地址、订单、订单明细、轮播图。其中订单相关的两张表是重点因为几乎所有跨表操作最后都汇聚到订单状态上。先看商品表。这里最容易犯的错是用FLOAT或DOUBLE存金额算一次运费就多出个 0.0000001最后对不上账。金额字段一律用DECIMAL(10,2)这是硬规矩。-- 商品表展示字段与库存字段放在一起后台改价改库存后前台立即可见 CREATE TABLE goods ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 商品主键, cat_id BIGINT NOT NULL COMMENT 所属分类 ID, title VARCHAR(120) NOT NULL COMMENT 商品标题, cover VARCHAR(255) NOT NULL COMMENT 封面图 URL必须是 https, price DECIMAL(10,2) NOT NULL COMMENT 售价禁用 FLOAT, origin_price DECIMAL(10,2) DEFAULT NULL COMMENT 划线价可为空, stock INT NOT NULL DEFAULT 0 COMMENT 可售库存, sales INT NOT NULL DEFAULT 0 COMMENT 销量仅用于展示排序, detail MEDIUMTEXT COMMENT 富文本详情存 HTML, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 上架 0 下架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_cat_status (cat_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;索引idx_cat_status对应的是「按分类查上架商品」这个最高频的查询商品列表页每翻一页都要走它。不加这个索引几百条数据看不出差别数据量一上去就明显卡顿——虽然毕业设计的数据量通常不至于但答辩时被问到「你建了哪些索引、为什么建」能答出这条就够用了。订单表的关键是状态字段。我一般把状态定义成固定的几个值并且写死在代码里的枚举中绝不在业务代码里到处写数字状态值含义允许的下一步0待付款1 待发货、4 已取消1待发货2 待收货、5 退款中2待收货3 已完成、5 退款中3已完成无终态4已取消无终态5退款中6 已退款6已退款无终态-- 订单主表状态推进必须带「前置状态」条件更新防止状态倒退 CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号对外暴露用这个, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT 服务端重算后的应付金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 见订单状态表, receiver_name VARCHAR(30) NOT NULL COMMENT 收货人下单时快照, receiver_phone VARCHAR(20) NOT NULL, receiver_addr VARCHAR(200) NOT NULL, idempotent_key VARCHAR(64) NOT NULL COMMENT 前端生成的幂等键, pay_time DATETIME DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), UNIQUE KEY uk_user_idem (user_id, idempotent_key), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这里有两个设计点值得单独说。一个是收货信息做快照用户改了自己默认地址之后历史订单里的收货地址不能跟着变所以订单表里存一份拷贝而不是存地址表的 ID 去关联。另一个是uk_user_idem这个唯一索引它是防重复下单的最后一道防线业务层查不到重复时,数据库还能兜住。订单明细表存每个商品的快照——商品标题、下单时的单价、数量。不要只存 goods_id 然后查询时去 join 商品表因为商品可能被改价甚至被删除历史订单必须能独立呈现。提示所有涉及状态变更的 UPDATE都把旧状态写进 WHERE 条件里UPDATE orders SET status 1 WHERE order_no ? AND status 0。影响行数为 0 就说明状态已经被别的请求改过了这时候不要重试直接返回。3. 总体架构与模块划分页面层、接口层、数据层怎么切架构这一章在大纲里看着虚落到交付物上其实很具体前端目录怎么放、后端分几层、接口长什么样、一次下单请求要穿过哪些模块。这些东西定下来之后剩下就是往格子里填代码不会出现「写到一半发现要重构」的情况。3.1 目录结构与模块边界前端按页面拆后端按域拆小程序端的目录我习惯按「页面 公共能力」两分。pages目录按业务域再分子目录components放商品卡片、数量步进器、空状态这类可复用组件utils放请求封装、金额格式化、时间格式化api目录单独一层把每个接口封成函数页面里只调函数不写 URL。这一层的价值在于接口地址改了、加了公共参数、换了鉴权方式只改api目录和utils/request.js两个地方。// utils/request.js —— 全局唯一的请求出口 const BASE_URL https://your-domain.com/api; function request(path, { method GET, data {}, loading true } {}) { if (loading) wx.showLoading({ title: 加载中, mask: true }); return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { content-type: application/json, // token 从本地存储取登录后写入过期由服务端返回 401 触发重登 Authorization: wx.getStorageSync(token) || }, success(res) { const body res.data; if (body.code 0) { resolve(body.data); } else if (body.code 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(body); } else { wx.showToast({ title: body.msg || 请求失败, icon: none }); reject(body); } }, fail(err) { // 真机断网、域名未配置合法域名都会走到这里 wx.showToast({ title: 网络异常, icon: none }); reject(err); }, complete() { if (loading) wx.hideLoading(); } }); }); } module.exports { request };这段封装里code 0是成功约定401 单独拎出来做登录态失效处理其他错误统一 toast。loading参数的作用是让某些静默请求比如轮询订单状态不弹遮罩不然页面上会一直转圈。最后一个细节在fail回调——真机上图片裂了、接口 404、域名没加白名单全都走这里给它一句明确的提示比让用户对着白屏发呆强。服务端的模块按业务域划分用户域登录、授权、地址、商品域分类、商品、搜索、交易域购物车、订单、支付回调、管理域后台的商品与订单操作。每个域内部再分控制器、服务、数据访问三层。这样切的好处是订单相关的所有逻辑都在交易域里不会出现「库存扣减写在商品服务里、订单状态改在控制器里」这种散落各处的情况。3.2 接口约定统一响应体、分页参数与错误码接口不规范是毕设项目里最常见的隐性债务。前后端一个人写的时候感觉不到等你写完三十个页面回头改一个字段名就知道痛了。约定三件事就够了响应体统一、分页参数统一、错误码分段。{ code: 0, msg: ok, data: { list: [], total: 128, page: 1, pageSize: 10 } }code的分段我一般这样定0 成功1xxx 参数错误2xxx 业务规则不通过库存不足、订单状态不允许4xxx 鉴权失败401 未登录、403 无权限5xxx 服务端异常。分页请求统一用page和pageSize两个参数服务端返回total让前端判断有没有下一页。这套东西定下来之后列表页的代码几乎是复制粘贴改个路径写起来非常快。接口文档不需要多正式一份 Markdown 表格就够路径、方法、入参、出参示例、备注。答辩时把它打进附录比口头描述有说服力得多。3.3 关键链路拆解从加购到收货的六次状态变更把主链路画成文字版的时序写代码前先在纸上过一遍能省掉大量返工。一次完整的购物流程数据在四个地方流转小程序的本地存储、服务端的购物车表、订单表、商品表。第一次状态变更发生在加购。如果用户没登录购物车数据先写本地存储登录后触发一次合并把本地条目同步到服务端购物车表。这一步的坑在于「同一个商品加了两次」合并时按 goods_id 累加数量而不是插两条。第二次是进入确认订单页。前端把选中的购物车条目 ID 传给服务端服务端重新查一遍商品的价格和库存算出租金、优惠如果有、总计返回给前端做展示。这一步的金额只是「预览值」不落库。第三次是提交订单也就是下单。服务端在一个事务里做四件事校验幂等键、逐条扣库存、写订单主表、写订单明细。任何一步失败整个事务回滚库存也不会被扣掉。第四次是支付回调。微信支付成功后支付平台会回调你的服务端服务端把订单从「待付款」推到「待发货」。这一步是整个系统里最容易出问题的地方后面单独讲。第五次是后台点发货订单从「待发货」到「待收货」。第六次是用户点确认收货订单到「已完成」同时可以把商品销量加上去。触发动作前置状态后置状态触发方是否需要事务提交订单无待付款小程序是扣库存 写两表支付成功回执待付款待发货支付平台是更新状态 记流水超时未付待付款已取消定时任务是回滚库存后台发货待发货待收货管理端否确认收货待收货已完成小程序是更新状态 加销量申请退款待发货/待收货退款中小程序否这张表建议直接放进论文的「系统设计」章节配上文字说明老师一眼就能看出你把状态管住了。4. 核心模块落地实现商品、购物车、订单、支付四个抓手到这一层思路已经清楚了缺的是能直接抄的代码骨架。下面四块是这套方案里最值得细看的地方每一块都给出关键片段和设计说明参数怎么改、失败时看什么都写在说明里。4.1 商品列表与详情分页加载、图片懒加载与富文本兜底列表页的第一个问题是分页。小程序没有内置的分页组件onReachBottom触发加载下一页时最容易出现的 bug 是「用户在上一页还没返回时又滑到底」导致同一页请求发两次、列表里出现重复数据。// pages/goods/list.js const { request } require(../../utils/request); Page({ data: { list: [], page: 1, pageSize: 10, total: 0, loading: false // 请求锁防止重复触发 }, onLoad(query) { this.catId query.catId || 0; this.loadPage(1); }, onReachBottom() { const { list, total, page } this.data; // 已加载数量 总数或者正在请求都不再触发 if (list.length total || this.data.loading) return; this.loadPage(page 1); }, async loadPage(page) { this.setData({ loading: true }); try { const res await request(/goods/list, { data: { catId: this.catId, page, pageSize: this.data.pageSize } }); this.setData({ // 用 concat 而不是 push配合页码去重更安全 list: page 1 ? res.list : this.data.list.concat(res.list), total: res.total, page }); } finally { this.setData({ loading: false }); } } });loading这个字段就是请求锁看着简单但很有必要。onReachBottom在快速滑动时会连续触发好几次没有锁的话就是三个相同的请求同时在飞。另外page 1时用覆盖而不是拼接这样下拉刷新和切换分类可以复用同一个方法不用写两套。商品详情页要处理富文本。后台用富文本编辑器录入的商品详情是一段 HTML小程序里用rich-text组件渲染。这里有个限制rich-text支持的标签是白名单的video、iframe、部分style属性都不生效。我的处理方式是在后台录入时就限制可用标签前端再加一层兜底——如果详情为空显示一段默认文案避免详情页下面一大片空白。图片方面列表页的封面图用modeaspectFill保证不拉伸变形详情页的大图加lazy-load。图片地址必须走 https而且域名要提前配置到小程序后台的「downloadFile 合法域名」里否则真机上全是裂图开发者工具里却一切正常——这个坑后面还会提。4.2 购物车本地态与数据库态的双写策略购物车是整套系统里状态最分裂的模块因为用户可能在未登录状态下加购。我的做法是双轨未登录写本地登录后合并到服务端之后所有操作都以服务端为准。// utils/cart.js —— 未登录时用本地存储登录后走接口 const KEY cart_local; function addLocal(goods) { const cart wx.getStorageSync(KEY) || []; const idx cart.findIndex(i i.goodsId goods.id); if (idx -1) { cart[idx].num goods.num; // 同一商品累加不新增一条 } else { cart.push({ goodsId: goods.id, title: goods.title, cover: goods.cover, price: goods.price, // 价格仅用于展示结算以服务端为准 num: goods.num, checked: true }); } wx.setStorageSync(KEY, cart); } function mergeToServer() { const cart wx.getStorageSync(KEY) || []; if (!cart.length) return Promise.resolve(); // 只上传 goodsId 和 num价格一律由服务端重查 const payload cart.map(i ({ goodsId: i.goodsId, num: i.num })); return request(/cart/merge, { method: POST, data: { items: payload }, loading: false }) .then(() wx.removeStorageSync(KEY)); // 合并成功后清本地避免重复合并 }这段代码有三个设计点。第一本地存的price只用来在购物车页面显示任何时候都不参与结算计算结算金额必须服务端重新算——否则用户改一下本地存储就能一块钱买手机。第二合并接口传的只有商品 ID 和数量服务端要校验商品是否还在售、库存够不够不合格的直接丢弃并返回提示。第三合并成功后立刻清本地存储否则下次登录会再合并一遍数量翻倍。服务端的购物车表用user_id goods_id做唯一索引插入用INSERT ... ON DUPLICATE KEY UPDATE num num ?一条 SQL 搞定「有就累加、没有就新增」不用先查再判断。注意购物车页面显示的价格要在每次进入页面时重新从服务端拉一次。商品降价了但购物车里还是旧价用户下单时看到金额变了会以为系统出错——这个体验问题在实际项目里被投诉的概率很高。4.3 订单创建事务边界、库存扣减与幂等键下单是整个系统的心脏。这一段代码写对了答辩时最容易被问的技术点你都能接住写错了超卖、重复订单、金额对不上一个都跑不掉。先看库存扣减的 SQL。关键在于把判断条件写进 WHERE 里让数据库来保证原子性而不是先 SELECT 查库存再 UPDATE。!-- GoodsMapper.xml带条件的原子扣减 -- update iddeductStock UPDATE goods SET stock stock - #{num}, sales sales #{num} WHERE id #{goodsId} AND status 1 AND stock #{num} /update这条 UPDATE 返回的是影响行数。返回 1 说明扣成功返回 0 说明要么商品下架了要么库存不够了。整个判断在数据库的一次行锁里完成不存在两个请求同时读到「还剩 1 件」然后都扣成功的可能。Service public class OrderService { Resource private GoodsMapper goodsMapper; Resource private OrderMapper orderMapper; Resource private OrderItemMapper itemMapper; /** * param idempotentKey 前端在进入确认页时生成的 UUID一次提交一个 * param items 只信任 goodsId 和 num金额由服务端重算 */ Transactional(rollbackFor Exception.class) public String createOrder(Long userId, String idempotentKey, ListOrderItemDTO items, AddressDTO addr) { // 1. 幂等前置检查同一个用户 同一个键直接返回上次的订单号 Order exist orderMapper.selectByIdempotentKey(userId, idempotentKey); if (exist ! null) { return exist.getOrderNo(); } // 2. 逐条扣库存任何一条失败整个事务回滚 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : items) { int affected goodsMapper.deductStock(item.getGoodsId(), item.getNum()); if (affected 0) { throw new BizException(商品已下架或库存不足); } Goods g goodsMapper.selectById(item.getGoodsId()); // 金额用 BigDecimal 累加保留两位禁止用 double total total.add(g.getPrice() .multiply(BigDecimal.valueOf(item.getNum())) .setScale(2, RoundingMode.HALF_UP)); } // 3. 写订单主表 明细表收货信息做快照 Order order new Order(); order.setOrderNo(generateOrderNo()); // 时间戳 用户尾号 随机数 order.setUserId(userId); order.setTotalAmount(total); order.setStatus(OrderStatus.WAIT_PAY.getCode()); order.setIdempotentKey(idempotentKey); order.setReceiverName(addr.getName()); // 快照不存地址表 ID order.setReceiverPhone(addr.getPhone()); order.setReceiverAddr(addr.getFullAddress()); orderMapper.insert(order); for (OrderItemDTO item : items) { itemMapper.insert(buildItem(order.getId(), item)); } return order.getOrderNo(); } }关于事务边界有一点很容易被忽略Transactional只对 RuntimeException 生效业务里抛的BizException如果是受检异常事务不会回滚。所以要么让BizException继承RuntimeException要么在注解里显式写rollbackFor Exception.class。上面这段用的是后一种保险。幂等键的生成时机也要注意。不能在下单按钮的点击事件里生成否则用户连点五次就是五个不同的键防不住。正确做法是在进入确认订单页时生成一次存在页面的 data 里整个页面生命周期内复用。4.4 支付回调与补单状态机推进的唯一入口微信支付需要企业主体和商户号个人开发者拿不到。毕业设计里通常的替代方案是「模拟支付」前端点支付按钮调一个/pay/mock接口服务端直接把订单推到待发货。这套方案能演示但答辩时容易被问「真实支付怎么对接」所以我在实现的时候会把模拟支付和真实回调写成同一套接口签名模拟接口只做一件事——伪造一次回调调用。这样后面接入真实支付时业务代码一行都不用改。/** * 支付结果处理的唯一入口真实回调与模拟支付都走这里 */ Transactional(rollbackFor Exception.class) public void handlePaySuccess(String orderNo, String tradeNo) { Order order orderMapper.selectByOrderNo(orderNo); if (order null) { return; // 订单不存在直接忽略不抛异常 } // 只允许「待付款 - 待发货」已经推进过的直接返回天然幂等 int affected orderMapper.updateStatus(orderNo, OrderStatus.WAIT_PAY.getCode(), OrderStatus.WAIT_SHIP.getCode()); if (affected 0) { return; // 并发回调被别的请求抢先处理了 } // 只有真正推进成功的那一次才记录支付流水 payLogMapper.insert(orderNo, tradeNo, new Date()); }这段代码的核心思想是「用状态机做幂等」。支付平台的回调可能重复发好几次网络超时重试是常态如果每次回调都去加销量、加积分、发消息数据就乱了。把「前置状态」写进 UPDATE 的 WHERE 条件里只有第一次能把 0 改成 1第二次影响行数为 0 直接返回什么都不做。这比在代码里写if (order.getStatus() 待付款)可靠得多因为那个判断在读和写之间有时间窗口。还有一件必须做的事补单。用户支付成功了但回调没到你服务端网络抖动、服务重启订单会一直挂在待付款。通常的做法是订单列表页点进去时前端带订单号调一次「查询支付结果」的接口服务端主动去支付平台查一遍查到已支付就手动触发一次handlePaySuccess。这套兜底逻辑不复杂但它是「这系统做得挺完整」和「这系统只能演示」的分水岭。超时未支付也要处理。定时任务每五分钟扫一次「创建超过 30 分钟且状态为待付款」的订单把状态改成已取消同时把库存加回去。加库存用stock stock num不需要条件判断因为回滚是纯粹的加法。5. 避坑与排查五处最容易在答辩前一晚炸掉的地方下面这五条每一条都是我见过或者亲自踩过的。共同特征是开发者工具里一切正常真机上、演示时、并发下才出问题而且排查起来很费时间。5.1 真机白屏、图片全裂、接口全 404合法域名没配现象模拟器上跑得好好的扫码到真机上打开页面白屏或者图片全是灰块控制台报「不在以下 request 合法域名列表中」。原因小程序的网络请求和下载文件都有域名白名单限制开发者工具里可以勾选「不校验合法域名」绕过真机没有这个开关。另外域名必须是备案过的 https端口只能是 443。解决在小程序管理后台的「开发设置 → 服务器域名」里把接口域名加到 request 域名把图片和文件域名加到 downloadFile 域名。本地开发阶段如果拿不到备案域名就在开发者工具里勾上「不校验合法域名」做调试但演示前一定要换成真域名并配好白名单同时把工具里的勾去掉再测一遍——这一步不做答辩现场大概率翻车。5.2 登录态丢失code 只能用一次session_key 会过期现象用户第一次进小程序能正常下单过一会儿或者杀掉进程重进就变成未登录订单列表空了。原因wx.login拿到的 code 是一次性的用过就失效换来的session_key也有有效期而且用户长时间不操作会被平台回收。很多实现是把 openid 当 token 直接用前端存起来再也不更新一旦服务端换了会话就得重新登录。解决走「code 换 token」的标准流程。前端wx.login拿 code传给服务端服务端调接口换 openid 和 session_key自己生成一个有过期时间的 token比如 7 天返回给前端前端存本地并在request的 header 里带上。服务端返回 401 时前端清掉本地 token 并静默重新登录一次而不是直接跳登录页——用户正在结算时被弹到登录页体验很差。5.3 金额算错、库存超卖类型选错与判断位置选错现象订单金额偶尔差几分钱两个人同时下单库存 1 件的商品卖出去了 2 件。原因金额用 float 或 double浮点累加必然产生误差库存是先 SELECT 查出来判断够不够再 UPDATE 扣减两条语句之间有空隙两个请求都能通过检查。解决金额字段和 Java 里的变量都用 DECIMAL / BigDecimal运算时显式指定setScale(2, RoundingMode.HALF_UP)。库存扣减必须用一条带条件的 UPDATE靠影响行数判断成败不要先查后改。如果业务上允许少量超卖比如秒杀再另说但普通商城不允许。5.4 支付回调重复、订单状态倒退现象一次支付订单的销量被加了三次或者订单先变成待发货过一会儿又变回待付款。原因支付平台回调是「至少一次」语义网络超时就会重发状态更新没带前置状态条件任何一次回调都能改状态包括延迟到达的旧回调。解决所有状态变更都带前置状态条件影响行数为 0 就认为已经被处理过直接返回成功注意是返回成功不是返回失败否则平台会一直重发。回调处理逻辑要写成幂等的重复执行结果一致。5.5 上拉加载出现重复数据、下单按钮连点生成多单现象列表滑到底部同一个商品出现两三次用户手快点两下生成两个一模一样的订单。原因分页请求没有并发锁快速滑动时同一页请求发了多次下单按钮没有防抖也没有幂等键。解决分页加loading请求锁同时在拼接数据时按主键去重。下单按钮点击后立刻setData({ submitting: true })并把按钮置灰请求结束再恢复服务端用幂等键 唯一索引做最后兜底。前端防抖是体验服务端幂等是正确性两个都要有。6. 验收与答辩用一份清单和 20 分钟演示把系统讲圆交付前一周我会把系统按下面这张清单完整过一遍。清单的好处是它把「我觉得应该没问题」变成「我一条条点过了」。验收项检查方式通过标准数据库可重建删库重新执行建表脚本 初始化数据无报错前台能正常显示商品主链路闭环用一个全新账号下单到确认收货六个状态全部走通订单列表同步库存一致性下单前后对比商品表 stock差值等于订单数量取消后回滚金额准确性下单金额与商品单价 × 数量手工核对分毫不差管理端可用后台改价、下架、发货各操作一次前台立即反映变化真机运行关掉开发者工具的域名校验豁免图片、接口全部正常异常兜底断网、重复点击、未登录访问订单页有明确提示不白屏、不崩溃演示脚本按「一条主线 三个亮点」组织。主线就是刚说的下单全流程用一台手机投屏从首页点进去八分钟走完。三个亮点挑你投入最多的部分库存扣减的原子性、支付回调的幂等处理、管理端改数据后前端的实时反映。每讲一个先说「如果不这么做会出什么问题」再说「我怎么做的」最后说「效果是什么」。这个结构比平铺直叙地念功能列表有效得多因为它证明的是你思考过而不只是你敲过代码。老师常问的三个问题提前准备好答案一是「库存超卖你怎么防的」答带条件的 UPDATE 加影响行数判断二是「支付回调重发怎么办」答状态机幂等加唯一索引三是「订单状态能不能被随意改」答所有变更都带前置状态条件前台没有直接改状态的接口。这三个问题答得出来技术分基本稳了。提示答辩前一晚把数据库导出成一份.sql文件和源码、教程一起放到同一个目录下。现场如果电脑出问题换一台机器导入脚本就能跑这比任何讲解都有说服力。从那以后我每次带项目验收前都强制走一遍「删库重建 真机跑主链路」这两步——因为真正会让你在最后一刻手忙脚乱的从来不是没写完的功能而是那些你以为已经好了的东西。希望帮到你。本文还有配套的精品资源点击获取
简介面向微信小程序课程设计与毕业设计场景的商城项目源码包适合需要完成商城类小程序作业、答辩演示或二次开发练习的学生与初学者。内容围绕商品展示、分类发现、购物车、支付、消息与个人中心等常见模块组织页面结构完整代码附带注释便于理解小程序端的页面、样式与逻辑协作方式。压缩包共68个文件约3.31MB主要由png、jpg等界面素材js业务脚本wxss样式wxml结构与json配置组成另含txt使用说明便于按目录快速定位页面和资源。已有1243人学习说明该选题与实现方式具有一定参考价值。读者可据此梳理商城小程序的目录组织、页面跳转、数据绑定与静态资源管理并结合数据库脚本、部署说明完成环境搭建和运行调试也可作为课程设计模板进行功能扩展与界面调整。1. 从一份能跑通的商城说起这套方案要解决的三个交付问题微信小程序商城的毕业设计最常翻车的不是功能写不出来而是收尾时发现手里只有一堆页面数据库建表脚本没有后台接口是写死的假数据教程只有一句「自己看代码」。这套基于微信小程序的商城方案把源码、数据库脚本和一份能跟着操作的教程放在一起解决的就是「跑得起来、说得清楚、答得上来」这三件事。它适合正在做小程序方向毕业设计或课程资源整理的学生也适合想拿一套完整电商闭环做参考的开发者——商品、购物车、订单、支付、后台管理这条主线是贯通的不是只有一个首页好看的空壳。下面按「需求怎么定、架构怎么切、模块怎么写、哪里会炸、怎么验收」的顺序把这份方案拆开讲一遍。2. 需求拆解与技术选型三类角色、两个端、一条主线做商城类毕业设计第一个要做的动作不是打开编辑器建工程而是把功能清单按角色切开、按优先级排一遍。切不清角色的后果是页面写了三十个答辩时老师说「你这个后台在哪」你只能说「后台没做重点在前端」。2.1 三类角色的功能边界买家端做闭环管理端做管控数据端做客诉买家端的验收标准只有一条——能从头走到尾。首页轮播与推荐位 → 分类页 → 商品列表 → 商品详情 → 加入购物车 → 确认订单选地址、算运费、用备注→ 支付 → 订单列表 → 确认收货 → 评价。这条主线上任何一环断了演示就得靠切页面硬撑过去很容易被追问到答不上来。支线功能包括搜索、收藏、收货地址管理、个人中心、售后申请这些属于「有更好、没有也能及格」的部分。管理端不是摆设它承担了整个系统里唯一能改动数据状态的入口。商品的新增、编辑、上下架、改库存订单的查看、发货、备注分类与轮播图的维护再加一个简单的数据看板今日订单数、成交额、待发货数量。管理端通常用一套 Web 页面实现不需要做得漂亮但必须能改数据——答辩时老师让你「把这个商品下架看看前台什么样」你得当场点得出来。数据端说的是数据库这一层要能自证。表结构、字段注释、索引、初始化数据这四样在交付物里必须是独立的、可执行的脚本。我一般会把建表语句和十几条测试数据放在同一个 SQL 文件里导入就能跑省得答辩现场还在那儿一条条 insert。功能取舍上有一条血泪经验八到十二周的周期里砍掉优惠券、拼团、秒杀、分销这类营销模块把订单状态机和库存扣减做扎实比堆十个花哨功能更容易拿分。营销模块的逻辑往往是「算一笔账」讲起来热闹但真正的工程难度在并发下的数据一致性而后者才是能撑起答辩内容的东西。2.2 技术栈取舍原生小程序配自建服务端还是云开发一把梭小程序端有四种常见选择各自的代价差别很大选之前先想清楚你要在答辩上「讲什么」。方案上手成本后端工作量可讲述性真机踩坑密度适合的场景原生小程序 自建服务端中高事务、索引、接口分层都能讲中想拿中高分、愿意花时间写后端原生小程序 云开发低低后端被平台藏起来了低周期紧、只求跑通跨端框架 自建服务端中高高高编译产物出问题难排查需要同时出 H5 或 App纯静态 假数据极低无极低不建议答辩很难过关这份方案走的是第一条路小程序端用原生 WXML/WXSS/JS服务端用一套常规的 MVC 后端Java 系或 Node 系都行结构是通用的数据库用 MySQL。理由很直接——毕业设计的评分表里「工作量」和「技术深度」是两项硬指标云开发把后端藏进平台里了老师问「库存是怎么扣的、并发下会不会超卖」你只能回答「平台帮我处理了」这句话在答辩现场基本等同于没做。小程序端有几个绕不开的点选型阶段就要认下来。主包体积有上限商品详情页的富文本和图片多通常要做分包把订单、个人中心这类二级页面拆到子包里。图片不能放本地得走对象存储或者图床而且域名要配到小程序的合法域名列表里否则真机上一个图都加载不出来。网络请求要统一封装不能每个页面写一遍wx.request否则后面加 token、加错误提示、加 loading 就是三十个文件挨个改。服务端这边接口按「控制器 → 服务 → 数据访问」三层组织就够了不需要上微服务那套。毕业设计的体量一个人维护的代码分层太细反而是负担。真正需要认真对待的是三件事统一响应格式、事务边界、以及幂等处理这三样后面会单独展开。2.3 数据表与状态机设计订单状态是全系统的主线商城系统的表不多核心八张用户、分类、商品、购物车、收货地址、订单、订单明细、轮播图。其中订单相关的两张表是重点因为几乎所有跨表操作最后都汇聚到订单状态上。先看商品表。这里最容易犯的错是用FLOAT或DOUBLE存金额算一次运费就多出个 0.0000001最后对不上账。金额字段一律用DECIMAL(10,2)这是硬规矩。-- 商品表展示字段与库存字段放在一起后台改价改库存后前台立即可见 CREATE TABLE goods ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 商品主键, cat_id BIGINT NOT NULL COMMENT 所属分类 ID, title VARCHAR(120) NOT NULL COMMENT 商品标题, cover VARCHAR(255) NOT NULL COMMENT 封面图 URL必须是 https, price DECIMAL(10,2) NOT NULL COMMENT 售价禁用 FLOAT, origin_price DECIMAL(10,2) DEFAULT NULL COMMENT 划线价可为空, stock INT NOT NULL DEFAULT 0 COMMENT 可售库存, sales INT NOT NULL DEFAULT 0 COMMENT 销量仅用于展示排序, detail MEDIUMTEXT COMMENT 富文本详情存 HTML, status TINYINT NOT NULL DEFAULT 1 COMMENT 1 上架 0 下架, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_cat_status (cat_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品表;索引idx_cat_status对应的是「按分类查上架商品」这个最高频的查询商品列表页每翻一页都要走它。不加这个索引几百条数据看不出差别数据量一上去就明显卡顿——虽然毕业设计的数据量通常不至于但答辩时被问到「你建了哪些索引、为什么建」能答出这条就够用了。订单表的关键是状态字段。我一般把状态定义成固定的几个值并且写死在代码里的枚举中绝不在业务代码里到处写数字状态值含义允许的下一步0待付款1 待发货、4 已取消1待发货2 待收货、5 退款中2待收货3 已完成、5 退款中3已完成无终态4已取消无终态5退款中6 已退款6已退款无终态-- 订单主表状态推进必须带「前置状态」条件更新防止状态倒退 CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号对外暴露用这个, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT 服务端重算后的应付金额, status TINYINT NOT NULL DEFAULT 0 COMMENT 见订单状态表, receiver_name VARCHAR(30) NOT NULL COMMENT 收货人下单时快照, receiver_phone VARCHAR(20) NOT NULL, receiver_addr VARCHAR(200) NOT NULL, idempotent_key VARCHAR(64) NOT NULL COMMENT 前端生成的幂等键, pay_time DATETIME DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), UNIQUE KEY uk_user_idem (user_id, idempotent_key), KEY idx_user_status (user_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单主表;这里有两个设计点值得单独说。一个是收货信息做快照用户改了自己默认地址之后历史订单里的收货地址不能跟着变所以订单表里存一份拷贝而不是存地址表的 ID 去关联。另一个是uk_user_idem这个唯一索引它是防重复下单的最后一道防线业务层查不到重复时,数据库还能兜住。订单明细表存每个商品的快照——商品标题、下单时的单价、数量。不要只存 goods_id 然后查询时去 join 商品表因为商品可能被改价甚至被删除历史订单必须能独立呈现。提示所有涉及状态变更的 UPDATE都把旧状态写进 WHERE 条件里UPDATE orders SET status 1 WHERE order_no ? AND status 0。影响行数为 0 就说明状态已经被别的请求改过了这时候不要重试直接返回。3. 总体架构与模块划分页面层、接口层、数据层怎么切架构这一章在大纲里看着虚落到交付物上其实很具体前端目录怎么放、后端分几层、接口长什么样、一次下单请求要穿过哪些模块。这些东西定下来之后剩下就是往格子里填代码不会出现「写到一半发现要重构」的情况。3.1 目录结构与模块边界前端按页面拆后端按域拆小程序端的目录我习惯按「页面 公共能力」两分。pages目录按业务域再分子目录components放商品卡片、数量步进器、空状态这类可复用组件utils放请求封装、金额格式化、时间格式化api目录单独一层把每个接口封成函数页面里只调函数不写 URL。这一层的价值在于接口地址改了、加了公共参数、换了鉴权方式只改api目录和utils/request.js两个地方。// utils/request.js —— 全局唯一的请求出口 const BASE_URL https://your-domain.com/api; function request(path, { method GET, data {}, loading true } {}) { if (loading) wx.showLoading({ title: 加载中, mask: true }); return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { content-type: application/json, // token 从本地存储取登录后写入过期由服务端返回 401 触发重登 Authorization: wx.getStorageSync(token) || }, success(res) { const body res.data; if (body.code 0) { resolve(body.data); } else if (body.code 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); reject(body); } else { wx.showToast({ title: body.msg || 请求失败, icon: none }); reject(body); } }, fail(err) { // 真机断网、域名未配置合法域名都会走到这里 wx.showToast({ title: 网络异常, icon: none }); reject(err); }, complete() { if (loading) wx.hideLoading(); } }); }); } module.exports { request };这段封装里code 0是成功约定401 单独拎出来做登录态失效处理其他错误统一 toast。loading参数的作用是让某些静默请求比如轮询订单状态不弹遮罩不然页面上会一直转圈。最后一个细节在fail回调——真机上图片裂了、接口 404、域名没加白名单全都走这里给它一句明确的提示比让用户对着白屏发呆强。服务端的模块按业务域划分用户域登录、授权、地址、商品域分类、商品、搜索、交易域购物车、订单、支付回调、管理域后台的商品与订单操作。每个域内部再分控制器、服务、数据访问三层。这样切的好处是订单相关的所有逻辑都在交易域里不会出现「库存扣减写在商品服务里、订单状态改在控制器里」这种散落各处的情况。3.2 接口约定统一响应体、分页参数与错误码接口不规范是毕设项目里最常见的隐性债务。前后端一个人写的时候感觉不到等你写完三十个页面回头改一个字段名就知道痛了。约定三件事就够了响应体统一、分页参数统一、错误码分段。{ code: 0, msg: ok, data: { list: [], total: 128, page: 1, pageSize: 10 } }code的分段我一般这样定0 成功1xxx 参数错误2xxx 业务规则不通过库存不足、订单状态不允许4xxx 鉴权失败401 未登录、403 无权限5xxx 服务端异常。分页请求统一用page和pageSize两个参数服务端返回total让前端判断有没有下一页。这套东西定下来之后列表页的代码几乎是复制粘贴改个路径写起来非常快。接口文档不需要多正式一份 Markdown 表格就够路径、方法、入参、出参示例、备注。答辩时把它打进附录比口头描述有说服力得多。3.3 关键链路拆解从加购到收货的六次状态变更把主链路画成文字版的时序写代码前先在纸上过一遍能省掉大量返工。一次完整的购物流程数据在四个地方流转小程序的本地存储、服务端的购物车表、订单表、商品表。第一次状态变更发生在加购。如果用户没登录购物车数据先写本地存储登录后触发一次合并把本地条目同步到服务端购物车表。这一步的坑在于「同一个商品加了两次」合并时按 goods_id 累加数量而不是插两条。第二次是进入确认订单页。前端把选中的购物车条目 ID 传给服务端服务端重新查一遍商品的价格和库存算出租金、优惠如果有、总计返回给前端做展示。这一步的金额只是「预览值」不落库。第三次是提交订单也就是下单。服务端在一个事务里做四件事校验幂等键、逐条扣库存、写订单主表、写订单明细。任何一步失败整个事务回滚库存也不会被扣掉。第四次是支付回调。微信支付成功后支付平台会回调你的服务端服务端把订单从「待付款」推到「待发货」。这一步是整个系统里最容易出问题的地方后面单独讲。第五次是后台点发货订单从「待发货」到「待收货」。第六次是用户点确认收货订单到「已完成」同时可以把商品销量加上去。触发动作前置状态后置状态触发方是否需要事务提交订单无待付款小程序是扣库存 写两表支付成功回执待付款待发货支付平台是更新状态 记流水超时未付待付款已取消定时任务是回滚库存后台发货待发货待收货管理端否确认收货待收货已完成小程序是更新状态 加销量申请退款待发货/待收货退款中小程序否这张表建议直接放进论文的「系统设计」章节配上文字说明老师一眼就能看出你把状态管住了。4. 核心模块落地实现商品、购物车、订单、支付四个抓手到这一层思路已经清楚了缺的是能直接抄的代码骨架。下面四块是这套方案里最值得细看的地方每一块都给出关键片段和设计说明参数怎么改、失败时看什么都写在说明里。4.1 商品列表与详情分页加载、图片懒加载与富文本兜底列表页的第一个问题是分页。小程序没有内置的分页组件onReachBottom触发加载下一页时最容易出现的 bug 是「用户在上一页还没返回时又滑到底」导致同一页请求发两次、列表里出现重复数据。// pages/goods/list.js const { request } require(../../utils/request); Page({ data: { list: [], page: 1, pageSize: 10, total: 0, loading: false // 请求锁防止重复触发 }, onLoad(query) { this.catId query.catId || 0; this.loadPage(1); }, onReachBottom() { const { list, total, page } this.data; // 已加载数量 总数或者正在请求都不再触发 if (list.length total || this.data.loading) return; this.loadPage(page 1); }, async loadPage(page) { this.setData({ loading: true }); try { const res await request(/goods/list, { data: { catId: this.catId, page, pageSize: this.data.pageSize } }); this.setData({ // 用 concat 而不是 push配合页码去重更安全 list: page 1 ? res.list : this.data.list.concat(res.list), total: res.total, page }); } finally { this.setData({ loading: false }); } } });loading这个字段就是请求锁看着简单但很有必要。onReachBottom在快速滑动时会连续触发好几次没有锁的话就是三个相同的请求同时在飞。另外page 1时用覆盖而不是拼接这样下拉刷新和切换分类可以复用同一个方法不用写两套。商品详情页要处理富文本。后台用富文本编辑器录入的商品详情是一段 HTML小程序里用rich-text组件渲染。这里有个限制rich-text支持的标签是白名单的video、iframe、部分style属性都不生效。我的处理方式是在后台录入时就限制可用标签前端再加一层兜底——如果详情为空显示一段默认文案避免详情页下面一大片空白。图片方面列表页的封面图用modeaspectFill保证不拉伸变形详情页的大图加lazy-load。图片地址必须走 https而且域名要提前配置到小程序后台的「downloadFile 合法域名」里否则真机上全是裂图开发者工具里却一切正常——这个坑后面还会提。4.2 购物车本地态与数据库态的双写策略购物车是整套系统里状态最分裂的模块因为用户可能在未登录状态下加购。我的做法是双轨未登录写本地登录后合并到服务端之后所有操作都以服务端为准。// utils/cart.js —— 未登录时用本地存储登录后走接口 const KEY cart_local; function addLocal(goods) { const cart wx.getStorageSync(KEY) || []; const idx cart.findIndex(i i.goodsId goods.id); if (idx -1) { cart[idx].num goods.num; // 同一商品累加不新增一条 } else { cart.push({ goodsId: goods.id, title: goods.title, cover: goods.cover, price: goods.price, // 价格仅用于展示结算以服务端为准 num: goods.num, checked: true }); } wx.setStorageSync(KEY, cart); } function mergeToServer() { const cart wx.getStorageSync(KEY) || []; if (!cart.length) return Promise.resolve(); // 只上传 goodsId 和 num价格一律由服务端重查 const payload cart.map(i ({ goodsId: i.goodsId, num: i.num })); return request(/cart/merge, { method: POST, data: { items: payload }, loading: false }) .then(() wx.removeStorageSync(KEY)); // 合并成功后清本地避免重复合并 }这段代码有三个设计点。第一本地存的price只用来在购物车页面显示任何时候都不参与结算计算结算金额必须服务端重新算——否则用户改一下本地存储就能一块钱买手机。第二合并接口传的只有商品 ID 和数量服务端要校验商品是否还在售、库存够不够不合格的直接丢弃并返回提示。第三合并成功后立刻清本地存储否则下次登录会再合并一遍数量翻倍。服务端的购物车表用user_id goods_id做唯一索引插入用INSERT ... ON DUPLICATE KEY UPDATE num num ?一条 SQL 搞定「有就累加、没有就新增」不用先查再判断。注意购物车页面显示的价格要在每次进入页面时重新从服务端拉一次。商品降价了但购物车里还是旧价用户下单时看到金额变了会以为系统出错——这个体验问题在实际项目里被投诉的概率很高。4.3 订单创建事务边界、库存扣减与幂等键下单是整个系统的心脏。这一段代码写对了答辩时最容易被问的技术点你都能接住写错了超卖、重复订单、金额对不上一个都跑不掉。先看库存扣减的 SQL。关键在于把判断条件写进 WHERE 里让数据库来保证原子性而不是先 SELECT 查库存再 UPDATE。!-- GoodsMapper.xml带条件的原子扣减 -- update iddeductStock UPDATE goods SET stock stock - #{num}, sales sales #{num} WHERE id #{goodsId} AND status 1 AND stock #{num} /update这条 UPDATE 返回的是影响行数。返回 1 说明扣成功返回 0 说明要么商品下架了要么库存不够了。整个判断在数据库的一次行锁里完成不存在两个请求同时读到「还剩 1 件」然后都扣成功的可能。Service public class OrderService { Resource private GoodsMapper goodsMapper; Resource private OrderMapper orderMapper; Resource private OrderItemMapper itemMapper; /** * param idempotentKey 前端在进入确认页时生成的 UUID一次提交一个 * param items 只信任 goodsId 和 num金额由服务端重算 */ Transactional(rollbackFor Exception.class) public String createOrder(Long userId, String idempotentKey, ListOrderItemDTO items, AddressDTO addr) { // 1. 幂等前置检查同一个用户 同一个键直接返回上次的订单号 Order exist orderMapper.selectByIdempotentKey(userId, idempotentKey); if (exist ! null) { return exist.getOrderNo(); } // 2. 逐条扣库存任何一条失败整个事务回滚 BigDecimal total BigDecimal.ZERO; for (OrderItemDTO item : items) { int affected goodsMapper.deductStock(item.getGoodsId(), item.getNum()); if (affected 0) { throw new BizException(商品已下架或库存不足); } Goods g goodsMapper.selectById(item.getGoodsId()); // 金额用 BigDecimal 累加保留两位禁止用 double total total.add(g.getPrice() .multiply(BigDecimal.valueOf(item.getNum())) .setScale(2, RoundingMode.HALF_UP)); } // 3. 写订单主表 明细表收货信息做快照 Order order new Order(); order.setOrderNo(generateOrderNo()); // 时间戳 用户尾号 随机数 order.setUserId(userId); order.setTotalAmount(total); order.setStatus(OrderStatus.WAIT_PAY.getCode()); order.setIdempotentKey(idempotentKey); order.setReceiverName(addr.getName()); // 快照不存地址表 ID order.setReceiverPhone(addr.getPhone()); order.setReceiverAddr(addr.getFullAddress()); orderMapper.insert(order); for (OrderItemDTO item : items) { itemMapper.insert(buildItem(order.getId(), item)); } return order.getOrderNo(); } }关于事务边界有一点很容易被忽略Transactional只对 RuntimeException 生效业务里抛的BizException如果是受检异常事务不会回滚。所以要么让BizException继承RuntimeException要么在注解里显式写rollbackFor Exception.class。上面这段用的是后一种保险。幂等键的生成时机也要注意。不能在下单按钮的点击事件里生成否则用户连点五次就是五个不同的键防不住。正确做法是在进入确认订单页时生成一次存在页面的 data 里整个页面生命周期内复用。4.4 支付回调与补单状态机推进的唯一入口微信支付需要企业主体和商户号个人开发者拿不到。毕业设计里通常的替代方案是「模拟支付」前端点支付按钮调一个/pay/mock接口服务端直接把订单推到待发货。这套方案能演示但答辩时容易被问「真实支付怎么对接」所以我在实现的时候会把模拟支付和真实回调写成同一套接口签名模拟接口只做一件事——伪造一次回调调用。这样后面接入真实支付时业务代码一行都不用改。/** * 支付结果处理的唯一入口真实回调与模拟支付都走这里 */ Transactional(rollbackFor Exception.class) public void handlePaySuccess(String orderNo, String tradeNo) { Order order orderMapper.selectByOrderNo(orderNo); if (order null) { return; // 订单不存在直接忽略不抛异常 } // 只允许「待付款 - 待发货」已经推进过的直接返回天然幂等 int affected orderMapper.updateStatus(orderNo, OrderStatus.WAIT_PAY.getCode(), OrderStatus.WAIT_SHIP.getCode()); if (affected 0) { return; // 并发回调被别的请求抢先处理了 } // 只有真正推进成功的那一次才记录支付流水 payLogMapper.insert(orderNo, tradeNo, new Date()); }这段代码的核心思想是「用状态机做幂等」。支付平台的回调可能重复发好几次网络超时重试是常态如果每次回调都去加销量、加积分、发消息数据就乱了。把「前置状态」写进 UPDATE 的 WHERE 条件里只有第一次能把 0 改成 1第二次影响行数为 0 直接返回什么都不做。这比在代码里写if (order.getStatus() 待付款)可靠得多因为那个判断在读和写之间有时间窗口。还有一件必须做的事补单。用户支付成功了但回调没到你服务端网络抖动、服务重启订单会一直挂在待付款。通常的做法是订单列表页点进去时前端带订单号调一次「查询支付结果」的接口服务端主动去支付平台查一遍查到已支付就手动触发一次handlePaySuccess。这套兜底逻辑不复杂但它是「这系统做得挺完整」和「这系统只能演示」的分水岭。超时未支付也要处理。定时任务每五分钟扫一次「创建超过 30 分钟且状态为待付款」的订单把状态改成已取消同时把库存加回去。加库存用stock stock num不需要条件判断因为回滚是纯粹的加法。5. 避坑与排查五处最容易在答辩前一晚炸掉的地方下面这五条每一条都是我见过或者亲自踩过的。共同特征是开发者工具里一切正常真机上、演示时、并发下才出问题而且排查起来很费时间。5.1 真机白屏、图片全裂、接口全 404合法域名没配现象模拟器上跑得好好的扫码到真机上打开页面白屏或者图片全是灰块控制台报「不在以下 request 合法域名列表中」。原因小程序的网络请求和下载文件都有域名白名单限制开发者工具里可以勾选「不校验合法域名」绕过真机没有这个开关。另外域名必须是备案过的 https端口只能是 443。解决在小程序管理后台的「开发设置 → 服务器域名」里把接口域名加到 request 域名把图片和文件域名加到 downloadFile 域名。本地开发阶段如果拿不到备案域名就在开发者工具里勾上「不校验合法域名」做调试但演示前一定要换成真域名并配好白名单同时把工具里的勾去掉再测一遍——这一步不做答辩现场大概率翻车。5.2 登录态丢失code 只能用一次session_key 会过期现象用户第一次进小程序能正常下单过一会儿或者杀掉进程重进就变成未登录订单列表空了。原因wx.login拿到的 code 是一次性的用过就失效换来的session_key也有有效期而且用户长时间不操作会被平台回收。很多实现是把 openid 当 token 直接用前端存起来再也不更新一旦服务端换了会话就得重新登录。解决走「code 换 token」的标准流程。前端wx.login拿 code传给服务端服务端调接口换 openid 和 session_key自己生成一个有过期时间的 token比如 7 天返回给前端前端存本地并在request的 header 里带上。服务端返回 401 时前端清掉本地 token 并静默重新登录一次而不是直接跳登录页——用户正在结算时被弹到登录页体验很差。5.3 金额算错、库存超卖类型选错与判断位置选错现象订单金额偶尔差几分钱两个人同时下单库存 1 件的商品卖出去了 2 件。原因金额用 float 或 double浮点累加必然产生误差库存是先 SELECT 查出来判断够不够再 UPDATE 扣减两条语句之间有空隙两个请求都能通过检查。解决金额字段和 Java 里的变量都用 DECIMAL / BigDecimal运算时显式指定setScale(2, RoundingMode.HALF_UP)。库存扣减必须用一条带条件的 UPDATE靠影响行数判断成败不要先查后改。如果业务上允许少量超卖比如秒杀再另说但普通商城不允许。5.4 支付回调重复、订单状态倒退现象一次支付订单的销量被加了三次或者订单先变成待发货过一会儿又变回待付款。原因支付平台回调是「至少一次」语义网络超时就会重发状态更新没带前置状态条件任何一次回调都能改状态包括延迟到达的旧回调。解决所有状态变更都带前置状态条件影响行数为 0 就认为已经被处理过直接返回成功注意是返回成功不是返回失败否则平台会一直重发。回调处理逻辑要写成幂等的重复执行结果一致。5.5 上拉加载出现重复数据、下单按钮连点生成多单现象列表滑到底部同一个商品出现两三次用户手快点两下生成两个一模一样的订单。原因分页请求没有并发锁快速滑动时同一页请求发了多次下单按钮没有防抖也没有幂等键。解决分页加loading请求锁同时在拼接数据时按主键去重。下单按钮点击后立刻setData({ submitting: true })并把按钮置灰请求结束再恢复服务端用幂等键 唯一索引做最后兜底。前端防抖是体验服务端幂等是正确性两个都要有。6. 验收与答辩用一份清单和 20 分钟演示把系统讲圆交付前一周我会把系统按下面这张清单完整过一遍。清单的好处是它把「我觉得应该没问题」变成「我一条条点过了」。验收项检查方式通过标准数据库可重建删库重新执行建表脚本 初始化数据无报错前台能正常显示商品主链路闭环用一个全新账号下单到确认收货六个状态全部走通订单列表同步库存一致性下单前后对比商品表 stock差值等于订单数量取消后回滚金额准确性下单金额与商品单价 × 数量手工核对分毫不差管理端可用后台改价、下架、发货各操作一次前台立即反映变化真机运行关掉开发者工具的域名校验豁免图片、接口全部正常异常兜底断网、重复点击、未登录访问订单页有明确提示不白屏、不崩溃演示脚本按「一条主线 三个亮点」组织。主线就是刚说的下单全流程用一台手机投屏从首页点进去八分钟走完。三个亮点挑你投入最多的部分库存扣减的原子性、支付回调的幂等处理、管理端改数据后前端的实时反映。每讲一个先说「如果不这么做会出什么问题」再说「我怎么做的」最后说「效果是什么」。这个结构比平铺直叙地念功能列表有效得多因为它证明的是你思考过而不只是你敲过代码。老师常问的三个问题提前准备好答案一是「库存超卖你怎么防的」答带条件的 UPDATE 加影响行数判断二是「支付回调重发怎么办」答状态机幂等加唯一索引三是「订单状态能不能被随意改」答所有变更都带前置状态条件前台没有直接改状态的接口。这三个问题答得出来技术分基本稳了。提示答辩前一晚把数据库导出成一份.sql文件和源码、教程一起放到同一个目录下。现场如果电脑出问题换一台机器导入脚本就能跑这比任何讲解都有说服力。从那以后我每次带项目验收前都强制走一遍「删库重建 真机跑主链路」这两步——因为真正会让你在最后一刻手忙脚乱的从来不是没写完的功能而是那些你以为已经好了的东西。希望帮到你。本文还有配套的精品资源点击获取
