★ FEATURED ARTICLE 简介这份资源是面向小程序开发初学者、课程设计与毕业设计学生的商城类小程序完整源码包围绕商品展示、购物车、订单结算、用户管理等典型电商模块搭建可帮助读者理解微信小程序前端界面与后端业务逻辑的协作方式快速获得一个可运行、可二次改造的在线购物平台原型。压缩包共68个文件约3.32MB以30个png与4个jpg、1个jpeg图片资源承担商品与界面素材9个js、7个wxml、7个wxss与7个json构成页面逻辑、结构、样式和配置主体另含说明压缩包便于对照目录结构。已有652人学习下载适合作为课程作业、毕业设计参考或小程序入门练手项目。读者可从中梳理页面路由与组件组织方式借鉴商品详情、购物车、结算等页面的布局与交互写法并结合源码理解数据存储、订单生成与支付对接的基本思路为后续扩展营销活动、客服等模块打下基础。1. 从一份能跑起来的商城源码说起做小程序商城课设或毕设最耗时间的往往不是写页面而是把商品、订单、购物车、支付回调这几条链路串成能演示的闭环。很多同学卡在“页面画完了下单流程走不通”这一步最后交上去的东西自己都不敢点第二遍。这份小程序商城源码要解决的正是这个问题它给出一套已经跑通的商城骨架商品浏览、规格选择、购物车、下单、订单状态流转都在里面适合需要交课程设计、毕业设计或者想拿一套可改可交付的商城方案做二次开发的读者。拿到手先别急着改样式先按下面这套结构把需求、设计、实现、验收走一遍改起来才不慌。2. 需求与选型商城小程序到底要拆成哪几块2.1 先把功能边界划清楚商城类小程序看着功能多真正决定能不能交付的其实就四条主线商品展示、购物车、订单、用户。其余的评价、优惠券、收藏、地址管理都是挂在这四条主线上的枝叶。我一般会先画一张功能边界表把“必须有”和“可以砍”分开避免做到一半发现工作量失控。模块核心功能课设/毕设是否必做说明商品列表、详情、规格选择、分类必做规格决定价格和库存是难点购物车加购、改数量、选中结算必做涉及本地与服务端同步订单创建、列表、详情、状态流转必做状态机是答辩高频提问点用户登录、收货地址、订单归属必做登录态贯穿全流程营销优惠券、满减选做时间不够就砍别硬上评价晒单、评分选做可作为加分项这张表的价值在于它直接决定了你后面数据库要建几张表、接口要写几个。很多方案翻车不是因为技术难而是边界没定做着做着把营销体系也塞进来最后哪块都不完整。通常的做法是先把必做四项做透选做项留接口不实现答辩时说明“预留扩展点”比半成品强得多。2.2 技术选型为什么是这套组合小程序商城的选型基本围绕“前端用小程序原生还是跨端框架、后端用什么语言、数据存哪里”三个问题。这份源码走的是原生小程序 轻量后端 关系型数据库的路线对课设和毕设来说是最稳的组合。前端用原生小程序的好处是没有构建链路的黑匣子app.json配页面、wx.request调接口、setData驱动视图出问题一眼能定位。跨端框架虽然一套代码多端跑但编译产物和生命周期差异在调试时很折磨人课设阶段没必要给自己加难度。后端选轻量服务接口按 RESTful 风格组织一个资源一个路径答辩时讲起来清楚。数据库用关系型商品、订单、用户之间的关联用外键和事务保证订单创建时扣库存这种操作必须放在事务里否则并发下库存会扣成负数。提示选型不是越新越好。课设和毕设的评分点在于“你是否理解并掌控了这套系统”而不是用了多时髦的框架。能讲清楚每一层为什么这么选比堆技术栈得分高。2.3 目录结构先看懂再动手拿到源码第一件事不是运行是看目录。商城小程序的目录通常长这样miniprogram-shop/ ├── miniprogram/ # 小程序前端 │ ├── pages/ # 页面首页、分类、购物车、我的、订单 │ ├── components/ # 复用组件商品卡片、规格弹窗、数量步进器 │ ├── utils/ # 工具请求封装、金额格式化、登录态 │ └── app.json # 页面注册与全局配置 ├── server/ # 后端服务 │ ├── routes/ # 路由goods、cart、order、user │ ├── models/ # 数据模型商品、订单、用户 │ └── config/ # 数据库与密钥配置 └── sql/ # 建表脚本与初始数据看懂这棵树你就知道改一个功能要动哪几个文件。比如加“商品收藏”前端在pages/goods/detail加按钮utils/request里加一个接口方法后端在routes加路由、models加一张收藏表。路径清楚了改需求就不会像无头苍蝇。3. 总体设计数据模型与接口约定3.1 四张核心表撑起整个商城商城的数据模型不用一上来就设计十几张表先把商品、规格、订单、订单明细这四张核心表定下来其余表围绕它们扩展。下面是我一般会用的最小表结构字段名做了简化实际落地时按需补时间戳和软删除标记。-- 商品主表一个商品一条记录 CREATE TABLE goods ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(120) NOT NULL, -- 商品标题 cover VARCHAR(255), -- 主图地址 category_id INT NOT NULL, -- 分类 status TINYINT DEFAULT 1, -- 1上架 0下架 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 商品规格表同一商品不同规格不同价、不同库存 CREATE TABLE goods_sku ( id INT PRIMARY KEY AUTO_INCREMENT, goods_id INT NOT NULL, spec VARCHAR(80) NOT NULL, -- 如 黑色/128G price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, INDEX idx_goods (goods_id) ); -- 订单主表一次结算一条订单 CREATE TABLE orders ( id INT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, -- 业务单号对外展示 user_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT DEFAULT 0, -- 0待付款 1待发货 2已发货 3已完成 4已取消 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 订单明细一条订单对应多条商品 CREATE TABLE order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, sku_id INT NOT NULL, title VARCHAR(120) NOT NULL, -- 下单时快照防止商品改名 price DECIMAL(10,2) NOT NULL, -- 下单时快照价 quantity INT NOT NULL );这里有两个设计点值得在答辩时讲。第一价格和标题在订单明细里做了快照商品后续改价改名不影响历史订单这是电商系统的常识但很多课设会直接关联商品表查一改价历史订单金额就变了。第二库存放在 SKU 表而不是商品表因为同一商品不同规格库存独立扣库存要精确到 SKU。把这两点讲清楚数据模型这块基本就稳了。3.2 订单状态机是答辩必问点订单状态不能随便改必须定义清楚哪些状态能转到哪些状态。我一般用一张状态流转表来约束代码里也按这张表做校验防止出现“已取消的订单又被发货”这种脏数据。当前状态允许流转到触发动作0 待付款1 待发货 / 4 已取消支付成功 / 用户取消或超时1 待发货2 已发货后台发货2 已发货3 已完成用户确认收货3 已完成无终态4 已取消无终态状态机的实现不用上状态机框架一个映射对象加一个校验函数就够// 订单状态流转规则key 为当前状态value 为允许的下一状态 const ORDER_FLOW { 0: [1, 4], 1: [2], 2: [3], 3: [], 4: [] }; // 变更订单状态前先校验非法流转直接拒绝 function canTransit(from, to) { return (ORDER_FLOW[from] || []).includes(to); } // 调用示例支付回调里把订单从待付款改为待发货 if (!canTransit(order.status, 1)) { throw new Error(订单状态不允许支付); }这段代码的意义在于把业务规则从散落各处的if里收拢到一个地方。答辩时老师问“如果用户重复支付怎么办”你可以答支付回调先查订单当前状态只有状态为 0 才允许流转到 1重复回调时状态已是 1canTransit返回 false直接幂等返回成功即可。这就是状态机带来的好处规则集中、可验证。3.3 接口约定先定前后端不打架前后端分离最容易出的问题是字段名对不上、返回结构不统一。我的习惯是先定一份接口约定所有接口统一返回{ code, msg, data }结构code为 0 表示成功非 0 表示业务错误。下面以创建订单为例// 前端调用提交购物车选中项创建订单 wx.request({ url: ${BASE_URL}/api/order/create, method: POST, header: { Authorization: Bearer ${token} }, // 登录态 data: { items: [{ skuId: 1001, quantity: 2 }], // 只传 skuId 和数量 addressId: 8 // 收货地址 }, success(res) { if (res.data.code 0) { // 拿到 orderNo 跳转支付或订单详情 wx.navigateTo({ url: /pages/order/detail?orderNo${res.data.data.orderNo} }); } else { wx.showToast({ title: res.data.msg, icon: none }); } } });注意前端只传skuId和数量价格、库存、商品标题全部由后端根据 SKU 查出来计算绝不能信任前端传来的金额。这是安全底线也是答辩时能体现你工程意识的地方。后端收到请求后在一个事务里完成校验库存、扣减库存、写订单主表、写订单明细、返回单号。任何一步失败整体回滚避免出现“库存扣了订单没生成”的脏数据。4. 关键模块实现购物车、下单与登录态4.1 购物车本地与服务端怎么同步购物车是商城小程序里最容易做拧的模块。用户没登录时加购存本地登录后要合并到服务端合并策略没想清楚就会出现“登录后购物车清空”或者“同一商品重复两条”的问题。我一般按这个顺序处理未登录时购物车存wx.setStorageSync登录成功后调一次合并接口把本地购物车整体提交服务端按skuId去重、数量相加合并完清空本地缓存。// 登录成功后合并本地购物车到服务端 async function mergeCartAfterLogin() { const localCart wx.getStorageSync(cart) || []; if (localCart.length 0) return; await request({ url: /api/cart/merge, method: POST, data: { // 只传 skuId 和数量服务端负责去重与累加 items: localCart.map(i ({ skuId: i.skuId, quantity: i.quantity })) } }); wx.removeStorageSync(cart); // 合并成功后清本地避免重复提交 }服务端合并时按skuId查已有记录有则数量累加无则新增整个过程放在一个事务里。这里有个细节数量累加后要校验不超过库存超过就截断到库存上限并在返回里提示而不是直接报错让用户懵。购物车这种模块用户体验的容错比严格校验更重要但库存上限必须守住。4.2 下单流程的事务与库存扣减下单是整个系统最不能出错的地方。前面接口约定里提过后端要在事务里完成校验、扣库存、写订单。这里把关键逻辑展开// 创建订单核心逻辑伪代码省略框架细节 async function createOrder(userId, items, addressId) { return await db.transaction(async (t) { let total 0; const orderItems []; for (const item of items) { // 行锁查 SKU防止并发超卖 const sku await t.query( SELECT * FROM goods_sku WHERE id ? FOR UPDATE, [item.skuId] ); if (!sku || sku.stock item.quantity) { throw new BizError(商品库存不足${item.skuId}); } // 扣减库存 await t.execute( UPDATE goods_sku SET stock stock - ? WHERE id ?, [item.quantity, item.skuId] ); total sku.price * item.quantity; orderItems.push({ skuId: sku.id, title: sku.title, price: sku.price, quantity: item.quantity }); } // 写订单主表生成业务单号 const orderNo genOrderNo(userId); const orderId await t.insert(orders, { order_no: orderNo, user_id: userId, total_amount: total, status: 0 }); // 批量写明细 for (const oi of orderItems) { await t.insert(order_item, { order_id: orderId, ...oi }); } return { orderNo, total }; }); }FOR UPDATE这行行锁是防超卖的关键没有它两个用户同时下单同一 SKU 最后一件库存会扣成负数。事务保证任何一步失败整体回滚不会出现库存扣了订单没写的情况。金额全部由后端按 SKU 现价计算前端传的金额一律不采信。这套逻辑讲清楚答辩时关于“并发下单怎么办”的问题就能接住。4.3 登录态与请求封装小程序的登录态用wx.login拿 code后端换 openid 并签发 token之后每个请求带 token。为了避免每个页面都写一遍 token 读取和错误处理通常封装一个请求方法// utils/request.js统一注入 token、统一处理登录失效 const BASE_URL https://your-domain.example.com; function request({ url, method GET, data {} }) { const token wx.getStorageSync(token); return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: token ? { Authorization: Bearer ${token} } : {}, success(res) { if (res.statusCode 401) { // 登录失效清 token 并跳登录页 wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); return reject(new Error(未登录)); } if (res.data.code ! 0) { return reject(new Error(res.data.msg)); } resolve(res.data.data); }, fail: reject }); }); }封装的价值在于登录失效、错误提示这些横切逻辑只写一次。页面里只管调request({ url: /api/goods/list })拿到的直接是data不用每处判断code。这种写法在课设里是加分项因为它体现了分层意识而不是把所有逻辑堆在页面里。5. 避坑与排查几个最容易翻车的地方5.1 金额用浮点数计算导致对不上账现象购物车合计和订单金额差几分钱或者多个商品相加后总额和明细对不上。原因是用 JavaScript 的Number做小数运算0.1 0.2 ! 0.3这个经典问题在金额场景会真实发生。解决方式有两种一是金额统一用“分”为单位的整数存储和计算展示时再除以 100二是后端用DECIMAL类型前端计算只做展示、最终金额以后端返回为准。我一般两者都用前端展示用格式化函数任何参与结算的金额都走后端。5.2 图片资源路径写死导致换环境全裂现象本地跑得好好的换台机器或者部署后商品图全变成裂图。原因是图片地址写成了http://localhost:3000/...或者某个临时目录。解决方式是图片统一走配置项config里放一个IMG_BASE所有图片路径拼接这个前缀部署时只改配置不改代码。同时注意小程序对图片域名有白名单要求正式环境要在后台配置合法域名这个坑在真机预览时才会暴露。5.3 订单超时未取消导致库存被占死现象用户下单不付款库存一直被占着别人买不了。原因是只做了下单扣库存没做超时释放。解决方式是给订单加创建时间用一个定时任务扫描超过 30 分钟仍是“待付款”的订单批量改为“已取消”并回补库存。课设里可以简化成启动时扫一次加定时扫答辩时说明“生产环境会用延迟队列”既落地又体现认知。5.4 规格选择没做联动导致价格错乱现象用户选了“黑色”再选“128G”价格显示的是另一个 SKU 的价。原因是规格维度和 SKU 没建立映射选择组合后没正确匹配到唯一 SKU。解决方式是前端维护“已选规格 → SKU”的查找表每次选择后重新匹配匹配不到就禁用“加入购物车”按钮。这个逻辑建议单独抽成组件别散在页面里。5.5 真机与开发者工具表现不一致现象开发者工具里一切正常真机上请求失败或页面白屏。常见原因是域名未配置、wx.request的method大小写、或者用了工具支持但真机不支持的 API。排查顺序是先看真机调试面板的报错再核对后台合法域名配置最后检查基础库版本。我一般会在项目里固定一个基础库最低版本避免用到高版本 API 在低版本真机上崩掉。6. 验收与答辩怎么证明这套商城真的能跑验收这件事很多人栽在“功能都有但讲不清”。我的建议是准备一份可复现的验收清单按用户路径走一遍每一步都留下证据。下面这张表可以直接拿去用验收项操作路径通过标准商品浏览首页 → 分类 → 商品详情列表分页正常详情规格可切换加购与合并未登录加购 → 登录本地购物车合并后无重复、数量正确下单闭环购物车结算 → 提交订单生成订单号库存相应减少状态流转模拟支付回调 → 后台发货 → 确认收货状态按状态机流转非法流转被拒异常场景库存不足下单、重复支付回调有明确提示数据无脏写超时取消下单后等待超时任务订单变已取消库存回补答辩时不要从头到尾念功能挑两个点深讲一个是订单状态机讲清楚为什么这么设计、非法流转怎么拦另一个是下单事务和库存扣减讲清楚并发下怎么防超卖。这两个点能体现你的设计能力比罗列十个页面有用。老师追问“如果要做秒杀怎么办”你可以答当前行锁方案在低并发下够用高并发会把库存预热到缓存、用队列削峰这是演进方向而不是当前缺陷这样答既不虚也不露怯。还有一个实操技巧答辩前把数据库清空用初始数据重新跑一遍完整流程录一段两分钟的屏幕操作视频备用。现场演示最怕网络或环境出问题有视频兜底心态稳很多。我吃过一次现场数据库连不上的亏从那以后每次答辩前都强制走一遍“清库 → 初始化 → 全流程操作 → 录屏”的流程再没翻过车。希望这套结构和清单能帮到你把这份源码改成一份拿得出手的交付物。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
