简介：这是一套基于微信小程序商城开发的毕业设计项目包，面向准备完成课程设计、毕业设计或小程序入门实战的在校学生与初级开发者。项目围绕商品展示、详情浏览、发现页、个人中心、支付与消息等常见商城模块展开，代码带有注释，新手也能对照理解页面结构、样式与交互逻辑。压缩包共68个文件，约3.31MB，主要由png、jpg图片素材，js逻辑文件，wxss样式，wxml结构，json配置及txt说明文档组成，并附数据库脚本与部署说明，便于按目录快速查找源码和素材。已有1243人学习，适合用来参考完整功能组织、页面搭建和基础数据配置；若项目包含服务端，可先部署服务端再用微信开发者工具导入，以减少运行报错，也可作为课程设计说明书与功能演示的素材基础。

1. 商城类毕设真正的难点：从“能跑”到“能答辩”

每年到毕设选题的时候，总有人抱着“做个微信小程序商城”的念头进来，又抱着“网上随便扒个源码交差”的念头出去。翻车的点往往不在代码跑不跑得起来，而在于答辩现场老师翻到订单表发现没有状态机，问一句“超时未付款怎么处理”，人当场就哑了。这套方案要解决的就是这件事：把一套商城小程序从需求、数据模型、接口、后台管理到部署验收完整串起来，让学生能照着结构交出一份有说服力的毕业设计，也让需要快速搭一套交易闭环的开发者有可参考的落地骨架。适合谁？适合课程设计要交完整方案的人、毕业设计要写文档加代码的人，以及想拿一套结构清晰的小商城做二次开发的从业者。

2. 需求与选型：为什么商城毕设选中微信小程序这套组合

2.1 先把需求边界划清楚，别一上来就堆功能

商城类项目最容易犯的错是功能列表写三页，最后能跑通的只有商品列表和下单按钮。我在拆这类题目时习惯先把需求分为“必须闭环”和“加分演示”两档。必须闭环的部分只有四块：商品浏览与分类、购物车与下单、订单状态流转、后台商品与订单管理。这四块打通了，系统就是活的；剩下的优惠券、收藏、评价、地址簿属于加分项，做出来是亮点，做不出来不影响主线。

落实到具体角色上，需求边界可以这样划线：

这张表的价值不在于好看，而在于它直接决定了后面的表结构和工作量。加分项如果一开始就写进需求文档，评审时会默认你要交付，后面砍掉就是减分。通常的做法是需求文档里写“本期范围”和“后续迭代”，把边界写死，答辩时反而显得思路清楚。

2.2 技术选型：小程序端 + 服务端 + 管理后台的三段式

选型这块没什么玄学，商城类项目对实时性要求不高，对数据一致性要求高，所以选型的核心是“事务好写、调试链路短”。常见的组合是小程序原生框架做前台，Node.js 或 Java 做服务端，MySQL 存交易数据，管理后台用一套现成的后台模板。前端不用上太重的框架，小程序原生配合组件库足够，页面数量在 15 到 25 个之间，毕设体量刚好。

服务端为什么优先考虑 Node.js 加 MySQL 而不是别的？因为商城最难的不是并发，是订单和库存的联动，MySQL 的 InnoDB 事务能把“扣库存 + 建订单 + 清购物车”放进一个事务里，写起来直白。以下是数据库连接与事务封装的典型写法，也是整套方案里最容易被忽略但最关键的一段：

// db.js —— 连接池 + 事务封装，商城所有写操作都走这里 const mysql = require('mysql2/promise'); const pool = mysql.createPool({ host: '127.0.0.1', user: 'mall', password: 'mall_pass', database: 'mall_db', waitForConnections: true, connectionLimit: 10, // 毕设体量 10 个连接足够，别开太大 charset: 'utf8mb4' // 必须 utf8mb4，否则商品名里的 emoji 存不进去 }); // 统一事务入口：回调里抛错就回滚，成功才提交 async function withTransaction(fn) { const conn = await pool.getConnection(); try { await conn.beginTransaction(); const result = await fn(conn); await conn.commit(); return result; } catch (err) { await conn.rollback(); throw err; } finally { conn.release(); // 连接必须归还，否则连接池会被耗尽 } } module.exports = { pool, withTransaction };

这段代码的作用是把事务边界统一收口。参数上，connectionLimit设成 10 是给毕设环境留余量，本地压测几十个并发用户时完全够用；utf8mb4是血泪经验，商品标题里塞一个表情符号，用utf8建表会直接插入失败，报错信息还很不直观。withTransaction这个封装后面下单、发货、取消订单都会用到，凡是涉及两张以上表的写操作，一律走它，不要图省事直接pool.query。

选型上还有一条容易踩的：小程序登录用的是code换openid的机制，服务端必须保存自己的会话凭证，不能把openid直接当 token 用。通常的做法是服务端签发一个自定义 token 存进缓存，前端每次请求带上，中间件统一校验。这一步做扎实了，后面的订单归属判断才不会出错。

3. 总体架构与数据模型：四层结构和七张核心表怎么落

3.1 四层架构与模块职责划分

整套系统按职责切成四层，每层只干一件事，这样文档里画架构图也有得画。

• 表现层：小程序页面与管理后台页面，只负责展示和收集输入，不写业务判断。
• 接口层：接收请求、校验参数、鉴权，把请求转成服务调用，不碰 SQL。
• 服务层：业务规则都在这里，订单状态怎么流转、库存怎么扣、购物车怎么合并，全在这一层。
• 数据层：MySQL 表与 DAO 封装，只做增删改查和事务，不含业务语义。

这个分层不是形式主义。举个例子，库存扣减的规则写在服务层，接口层只传skuId和数量，将来要加“限购一件”的功能，只改服务层，接口和页面都不用动。答辩时老师问“你的业务逻辑在哪”，能一句话答清楚，比含糊其辞强很多。模块上则切分为用户模块、商品模块、购物车模块、订单模块、支付模块、后台管理模块六个，和上面的分层是正交的，横切竖切都能讲。

3.2 七张核心表的设计与关键字段说明

数据模型是商城毕设的骨架，表设计错了，后面所有代码都在给错误买单。核心表我一般控制在七张，再加两三张辅助表，具体如下：

几个字段的选择值得单独说。orders.status用整数枚举而不是字符串，0 待付款、1 已付款待发货、2 已发货、3 已完成、4 已取消，整数索引小、比较快，配一张字典表或在代码里写常量都行，但一定要在文档里给出映射说明，否则答辩时看表的人一脸懵。order_item里的price存的是下单那一刻的价格快照，不能关联sku表实时取价，这是电商系统的常识，也是很多学生方案里翻车的地方——商品一改价，历史订单金额全变了。

-- 订单主表：状态字段与订单号是核心 CREATE TABLE `orders` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号，非主键，用于展示', `user_id` BIGINT UNSIGNED NOT NULL, `total_amount` DECIMAL(10,2) NOT NULL COMMENT '订单总额，单位元', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待付款 1待发货 2已发货 3已完成 4已取消', `address_snapshot` VARCHAR(255) NOT NULL COMMENT '收货地址快照', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `paid_at` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_status` (`user_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表语句里有三处设计意图。order_no单独建唯一索引而不做主键，是因为主键用自增id对 InnoDB 的聚簇索引更友好，而业务单号是给用户看的、可能要按时间规则生成，两者职责分开。address_snapshot存的是下单时的收货地址文本快照，用户后来改了默认地址，老订单的收货信息不能跟着变。idx_user_status这个联合索引对应的是“我的订单”页按状态筛选的高频查询，没有它，订单量一多列表页就卡。金额一律用DECIMAL不用FLOAT，浮点数算钱迟早出问题，这是硬规矩。

3.3 商品与 SKU 的拆分逻辑

单规格商品和多规格商品的差别，决定了product和sku必须拆开。一个商品可能有颜色和尺寸两个维度，组合出多个 SKU，每个 SKU 有自己的库存和价格。购物车、订单明细关联的都是sku_id而不是product_id，原因很简单：用户买的是一件具体规格的货，不是一个抽象商品。这个拆分在文档里画一张简图就能讲明白，实现上sku表加一个spec_json字段存规格组合，比再拆规格表省事得多，毕设体量完全够用。

4. 核心模块落地：登录、购物车、订单与后台的代码级实现

4.1 登录与会话：openid 换 token 的完整链路

小程序登录链路是固定的：前端wx.login拿code，传给服务端，服务端用code换openid和session_key，查库或建号，签发 token 返回。这里的关键在于服务端不要相信前端传来的任何用户身份，userId一律从 token 里解出来。

// auth.js —— 登录接口与鉴权中间件 const jwt = require('jsonwebtoken'); // 登录：code 换 openid，再换自家 token async function login(req, res) { const { code } = req.body; if (!code) return res.status(400).json({ msg: '缺少 code' }); // 换取 openid，这里的 appid/secret 从配置读，不要硬编码 const wxRes = await callWxApi(code); if (!wxRes.openid) return res.status(401).json({ msg: '登录失败' }); // 查用户，没有就注册 let [rows] = await pool.query('SELECT id FROM user WHERE openid = ?', [wxRes.openid]); let userId; if (rows.length === 0) { const [r] = await pool.query( 'INSERT INTO user (openid, created_at) VALUES (?, NOW())', [wxRes.openid] ); userId = r.insertId; } else { userId = rows[0].id; } // 签发 token，有效期 7 天，毕设够用 const token = jwt.sign({ userId }, process.env.JWT_SECRET, { expiresIn: '7d' }); res.json({ token, userId }); } // 鉴权中间件：所有需要登录的接口都挂这个 function auth(req, res, next) { const token = (req.headers.authorization || '').replace('Bearer ', ''); try { req.user = jwt.verify(token, process.env.JWT_SECRET); // 解出 userId next(); } catch (e) { res.status(401).json({ msg: '登录已过期' }); } }

这段实现的要点在鉴权中间件。所有涉及“我的订单”“我的购物车”的接口挂上auth，服务层只用req.user.userId，不接收查询参数里的userId。很多学生方案为了省事直接在 URL 里传userId，等于把越权接口白送给老师当提问素材。JWT_SECRET从环境变量读，.env文件加进.gitignore，提交源码时别把密钥一起交上去。

4.2 购物车与下单：一次事务里完成扣库存、建订单、清购物车

下单是整个系统最容易翻车的地方。正确的做法是把校验、扣库存、建订单、写明细、清购物车放进同一个事务，任何一步失败全部回滚。库存扣减要用带条件的更新语句，stock >= quantity写进WHERE里，靠数据库的行锁保证不超卖。

// orderService.js —— 下单主流程 async function createOrder(userId, address) { return withTransaction(async (conn) => { // 1. 查购物车并锁定对应 SKU 行（FOR UPDATE 防并发） const [cartItems] = await conn.query( `SELECT c.sku_id, c.quantity, s.price, s.stock FROM cart c JOIN sku s ON c.sku_id = s.id WHERE c.user_id = ? FOR UPDATE`, [userId] ); if (cartItems.length === 0) throw new Error('购物车为空'); let total = 0; for (const item of cartItems) { if (item.stock < item.quantity) { throw new Error(`库存不足: sku ${item.sku_id}`); } // 2. 条件扣减，stock 不足时影响行数为 0，直接抛错 const [upd] = await conn.query( 'UPDATE sku SET stock = stock - ? WHERE id = ? AND stock >= ?', [item.quantity, item.sku_id, item.quantity] ); if (upd.affectedRows === 0) throw new Error(`扣库存失败: ${item.sku_id}`); total += Number(item.price) * item.quantity; } // 3. 建订单主表 + 明细 const orderNo = 'M' + Date.now() + Math.floor(Math.random() * 1000); const [order] = await conn.query( 'INSERT INTO orders (order_no, user_id, total_amount, address_snapshot) VALUES (?,?,?,?)', [orderNo, userId, total.toFixed(2), address] ); for (const item of cartItems) { await conn.query( 'INSERT INTO order_item (order_id, sku_id, price, quantity) VALUES (?,?,?,?)', [order.id, item.sku_id, item.price, item.quantity] ); } // 4. 清空购物车，事务提交后生效 await conn.query('DELETE FROM cart WHERE user_id = ?', [userId]); return { orderId: order.insertId, orderNo, total }; }); }

参数与逻辑说明：FOR UPDATE锁住的是购物车里对应的 SKU 行，两个用户同时买最后一件，后一个会等锁，拿到锁后再判断stock >= quantity，条件不满足就抛错回滚，不会出现负库存。扣库存语句里的AND stock >= ?是双保险，配合行锁一起用。金额累加用Number()转一下再乘，最后toFixed(2)，因为 MySQL 的DECIMAL驱动返回的是字符串。订单号用时间戳加随机数只是演示，正式一点可以加用户 ID 前缀防止碰撞。整个流程任何一步抛错，withTransaction都会回滚，购物车和库存都回到原样，这就是把写操作收口到事务封装里的好处。

4.3 订单状态流转：枚举加校验，别让状态乱跳

订单状态必须用一张流转规则表约束，不能谁想改就改。0 待付款只能到 1 待发货或 4 已取消；1 只能到 2；2 只能到 3。实现时在服务层写一个校验函数，任何改状态的入口都先过它。

// 合法的状态迁移：from -> [to...] const TRANSITIONS = { 0: [1, 4], // 待付款 -> 待发货 / 已取消 1: [2], // 待发货 -> 已发货 2: [3], // 已发货 -> 已完成 3: [], 4: [] }; function assertTransition(from, to) { if (!(TRANSITIONS[from] || []).includes(to)) { throw new Error(`非法状态迁移: ${from} -> ${to}`); } }

加了这个校验，老师问“订单能不能从待付款直接变已完成”，你能答“不能，服务层拦截”。超时未付款的取消用定时任务扫status = 0 AND created_at < NOW() - INTERVAL 30 MINUTE的订单改成 4，同时把库存加回去，这一步也要走事务。库存回补的 SQL 是UPDATE sku SET stock = stock + ? WHERE id = ?，注意别写成覆盖式的赋值。

4.4 后台管理：商品上下架与订单发货的最小实现

后台不用做得多花哨，两个页面撑住场面就够：商品列表页带上下架开关和库存编辑，订单列表页带发货按钮。发货接口的核心是把状态从 1 改到 2 并写入发货时间，走同一个状态校验函数。商品下架不是删数据，是把product.status置为 0，小程序端查询商品时加status = 1条件，这样历史订单还能正常显示商品信息。后台接口统一走一层管理员鉴权，与用户 token 分开，用一个固定的角色字段判断，别混在小程序登录体系里。

5. 避坑与常见问题：这类商城毕设最容易翻车的五个地方

5.1 购物车重复加购导致数量叠加异常

现象是用户连点两次“加入购物车”，购物车里出现两条相同 SKU 的记录，结算时金额算错。原因是加入购物车用的是纯INSERT，没有先查再决定插入还是更新。解决是给cart表加(user_id, sku_id)唯一索引，写入用INSERT ... ON DUPLICATE KEY UPDATE quantity = quantity + ?，一条语句解决查重和累加，前端连点也不会出问题。

5.2 图片存二进制导致数据库膨胀、接口变慢

现象是商品列表加载慢，数据库体积几百兆。原因是封面图直接以BLOB存进product表。解决是把图片存文件系统或对象存储，表里只存 URL 字符串，长度VARCHAR(255)足够。小程序端展示时直接用image组件绑 URL，顺带还能配 CDN。这条几乎是每届都有人踩的坑，改起来不难，但等你发现时数据已经灌进去了。

5.3 库存扣减与订单取消没做成对操作

现象是订单取消后库存没回来，或者只回了一半。原因是取消逻辑只改了orders.status，忘了遍历order_item回补库存。解决是把“取消订单”写成一个事务：改状态 + 逐条回补库存 + 记录取消时间，三者同生共死。测试时专门造一个下单再取消的场景，比对操作前后的库存总量，能立刻发现问题。

5.4 小程序请求域名与本地调试环境不匹配

现象是开发者工具里一切正常，真机预览全部请求失败。原因是小程序要求请求域名在后台配置白名单，且必须是已备案的 HTTPS 域名，本地http://127.0.0.1只能在开发者工具勾选“不校验合法域名”时用。解决是开发阶段用工具的不校验选项，交付前把服务端部署到有域名的环境，把request的baseURL抽成配置项，切换环境只改一处。答辩演示尽量用真机加线上环境，别在现场切工具，容易出岔子。

5.5 事务里混入非数据库操作导致回滚失效

现象是下单接口偶发“订单建了但购物车没清”，或者回滚后库存仍然被扣。原因是事务回调里调用了发短信、调支付这类外部接口，外部调用失败抛错，但外部副作用回滚不了。解决是事务里只放数据库操作，外部调用全部挪到事务提交之后执行，用事件或简单的afterCommit回调串起来。这条不算高频，但一旦出现排查起来极费时间。

6. 验收与答辩：用一张自检清单把方案讲圆

验收这套东西，我一般的做法是分两轮走。第一轮是功能自检，按角色把所有主流程走一遍，用一张表打钩，写完才算代码部分收工。

第二轮是答辩预演，重点不是演示功能，是讲清楚三个问题：数据模型为什么这么设计、订单状态为什么只能这么流转、并发下单怎么保证不超卖。这三个问题答好了，剩下的都是细节。演示前把数据准备好，商品至少 20 条、订单至少 10 条覆盖各种状态，别现场空库点半天。数据库脚本、源码、部署说明三样整理成一个压缩包，README 里写清楚环境版本和启动顺序，老师翻到能直接跑起来，印象分就稳了。

从那以后我每次带这类商城题目，都强制先让学生在纸上画出订单状态流转图和七张表的关系，画不出来就先别写代码，画出来了后面基本一路顺。希望这套结构能帮到你，照着改改就能交出一份站得住的方案。

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