简介：这份微信小程序商城完整源码面向希望快速搭建移动端电商应用的开发者与学习者，提供从商品展示、购物车、订单管理到支付与用户互动的整套实现方案，适合具备一定前端基础、想深入理解小程序技术栈的人群参考。压缩包共60个文件，约412KB，以24个png界面素材、9个wxss样式表、9个js逻辑脚本、7个json配置、7个wxml结构文件为主，另含说明文档与版本管理配置，覆盖页面结构、样式、业务逻辑与全局配置等层面。源码按pages页面目录、app全局文件、utils工具库、models数据模型、components自定义组件等模块组织，便于对照理解WXML、WXSS与JavaScript的协作方式，以及wx.request、wx.setStorage等接口在商品加载、订单提交与支付调用中的实际用法。目前已有7728人学习下载，可作为搭建自有微信商城或研究小程序开发原理的完整参考。
1. 微信小程序商城完整源码：从拿到代码到跑通第一单，中间隔着什么
很多人第一次接触「微信小程序商城完整源码」，脑子里想的是一套能直接上线的成品：打开开发者工具、导入代码、点一下编译，商城就跑起来了。实际拿到源码之后，大概率会遇到三个问题——后端接口对不上、数据库表缺字段、支付回调根本没法在本地调通。这不是源码质量差，而是「完整」这两个字在不同人嘴里含义不一样：有人指的是前端页面齐全，有人指的是前后端加数据库全都有，还有人指的是连部署脚本和初始化数据都打包好了。
这篇文章面向的是手里已经有一份小程序商城源码、或者正准备选一套来二次开发的开发者。我会按「先搞清楚一套商城源码由哪些部分组成，再动手把本地环境跑通，然后处理商品、订单、支付这三条核心链路，最后讲部署和二次开发时最容易翻车的地方」这个顺序来写。不假设你拿到的源码长什么样，但每一步的判断方法和排查思路是通用的。读完你应该能做到：知道一套源码能不能用、该怎么改、改哪里会出问题。
2. 一套商城源码到底包含什么：先看清结构再动手
2.1 前端、后端、数据库、管理后台，四块缺一不可
一套能真正跑起来的小程序商城，最少包含四个部分。前端是小程序端，用微信开发者工具打开，负责商品展示、下单、支付、个人中心这些用户能看到的页面。后端是提供 API 的服务，通常用 Node.js、Java、PHP 或 Python 写，处理商品查询、订单创建、支付签名、库存扣减这些逻辑。数据库存商品、用户、订单、优惠券等数据，MySQL 最常见，也有用 PostgreSQL 或云开发数据库的。管理后台是给运营用的 Web 页面，用来上架商品、改价格、看订单、发优惠券。
拿到源码后第一件事不是急着编译，而是打开目录看这四块是不是都在。常见情况是：前端代码很完整，后端只有一个 README 说「请自行对接接口」，数据库只有一个空 SQL 文件没有初始数据。这种源码不是不能用，但你要清楚自己需要补多少东西。判断方法很简单——看根目录有没有 server、api、backend 这类文件夹，看有没有 .sql 文件且里面包含 INSERT 语句，看有没有 admin、manage、dashboard 这类前端管理端目录。
2.2 用目录树快速判断源码完整度
导入项目之前，先花五分钟看目录结构，能省掉后面很多无效折腾。下面是一个典型的完整商城源码目录，你可以拿自己手里的源码对照：
mall-miniprogram/ ├── miniprogram/ # 小程序前端 │ ├── pages/ # 页面：首页、分类、购物车、订单、我的 │ ├── components/ # 公共组件：商品卡片、数量选择器 │ ├── utils/ # 请求封装、工具函数 │ └── app.js # 全局逻辑，检查里面的 baseUrl ├── server/ # 后端服务 │ ├── controllers/ # 业务逻辑：商品、订单、支付 │ ├── models/ # 数据库模型 │ ├── routes/ # 接口路由 │ └── config/ # 数据库配置、支付配置 ├── admin/ # 管理后台（可能是独立项目） ├── database/ │ └── init.sql # 建表语句 + 初始数据 └── README.md # 部署说明，重点看环境变量部分重点看三个地方：app.js 里的 baseUrl 指向哪里，server/config 里的数据库配置是不是明文写死的，database/init.sql 里有没有商品和分类的初始数据。如果 init.sql 只有建表语句没有数据，你启动后首页会是空的，这不是 bug，是缺数据。
2.3 环境准备：Node、MySQL、开发者工具三件套
不管源码用什么技术栈，本地跑通一般需要三样东西：Node.js 环境（如果后端是 Node）、MySQL 数据库、微信开发者工具。Node 建议用 16 或 18 这两个长期支持版本，太新的版本有时会和老依赖冲突。MySQL 用 5.7 或 8.0 都行，注意 8.0 默认的认证插件和某些老 Node 驱动不兼容，遇到连接报错可以先把用户认证方式改成 mysql_native_password。
微信开发者工具下载安装后，用微信扫码登录，然后选择「导入项目」，目录指向 miniprogram 文件夹，AppID 可以先用测试号。如果源码里 app.js 的 baseUrl 写的是某个线上地址，你要么改成自己本地的后端地址，要么在开发者工具里勾选「不校验合法域名」，否则请求会被拦截。这一步是新手最容易卡住的地方——页面能显示但数据加载不出来，九成是请求域名没配好。
# 后端依赖安装，在 server 目录下执行 npm install # 如果安装慢或报错，先检查 Node 版本 node -v # 建议输出 v16.x 或 v18.x # 初始化数据库，先建库再导入 mysql -u root -p -e "CREATE DATABASE mall_db DEFAULT CHARSET utf8mb4;" mysql -u root -p mall_db < database/init.sqlnpm install之后如果出现大量 deprecated 警告不用慌，只要没有 error 就能继续。数据库导入时注意字符集用 utf8mb4，否则商品名里的特殊字符或表情会乱码。导入完成后用mysql -u root -p mall_db -e "SHOW TABLES;"确认表都建好了，再用SELECT COUNT(*) FROM goods;看看有没有商品数据。如果商品表是空的，后面首页和分类页都会是空白，需要手动补几条测试数据。
3. 把本地环境跑通：从启动后端到小程序首页出数据
3.1 后端启动与接口自测
后端启动命令通常在 package.json 的 scripts 里，常见的是npm run dev或npm start。启动前先确认 config 里的数据库连接信息和你本地一致——host、port、user、password、database 五个字段。很多源码的 config 里写的是作者自己的数据库密码，你直接启动会报连接失败。
// server/config/db.js 典型配置，改成你自己的 module.exports = { host: '127.0.0.1', port: 3306, user: 'root', password: '你的密码', // 这里必须改 database: 'mall_db', // 和前面建的库名一致 charset: 'utf8mb4', timezone: '+08:00' // 时区不对会导致订单时间差8小时 };时区这个参数容易被忽略。如果后端和数据库时区不一致，订单创建时间会偏差几个小时，后面做统计和对账时很麻烦。启动成功后，先用浏览器或 curl 测一个最简单的接口，比如商品列表：
# 测试商品列表接口，确认后端和数据库通了 curl http://127.0.0.1:3000/api/goods/list # 如果返回 HTML 而不是 JSON，说明路由没匹配上 # 如果返回 500，去看后端控制台的报错信息 # 如果返回空数组，说明数据库里没数据接口能返回 JSON 数据，说明后端这条链路通了。返回 500 就去看控制台，常见原因是数据库字段和模型定义对不上，比如模型里写了goods_name但表里字段叫name。返回空数组就去补数据。这一步不要跳过，后端不通后面全是白费。
3.2 小程序端请求封装与 baseUrl 修改
小程序端的请求一般封装在 utils/request.js 或类似文件里，核心是wx.request。你要改的是请求的域名前缀，让它指向你本地的后端。如果后端跑在 3000 端口，baseUrl 就写http://127.0.0.1:3000。
// miniprogram/utils/request.js const BASE_URL = 'http://127.0.0.1:3000'; // 改成你的后端地址 function request(options) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'content-type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' // 登录后拿到的凭证 }, success: (res) => { if (res.statusCode === 200) { resolve(res.data); } else { reject(res); } }, fail: reject }); }); }改完 baseUrl 后，在开发者工具里点「详情」→「本地设置」，勾选「不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书」。这个选项只在开发阶段用，上线前必须配好合法域名。然后重新编译，看首页有没有商品数据出来。如果还是没有，打开开发者工具的 Network 面板，看请求的完整 URL 和返回内容，基本能定位到问题。
3.3 首页、分类、详情三条链路的联调顺序
不要一上来就点遍所有页面，按「首页 → 分类 → 商品详情」这个顺序联调效率最高。首页通常调的是商品列表或推荐接口，分类页调的是分类树加分类下商品，详情页调的是单个商品详情。这三条链路都依赖商品数据，所以先把商品数据准备好。
如果首页出数据了但分类页没有，大概率是分类接口的字段和前端渲染对不上，比如前端要children数组但后端返回的是平铺列表。如果详情页打不开，看传参是不是商品 id，以及后端有没有按 id 查询的接口。这三步走完，商城的浏览链路就通了，接下来才是下单和支付。
4. 商品、订单、支付三条核心链路的实现与参数
4.1 商品模块：分类树、SKU、库存三个关键点
商品模块看起来简单，实际有三个容易出问题的地方。第一是分类树，商城一般支持多级分类，后端返回的应该是嵌套结构，前端用递归组件渲染。如果后端返回平铺列表，前端要自己组装成树。第二是 SKU，同一件商品有不同规格（颜色、尺寸），每个规格组合对应不同的价格和库存。SKU 的数据结构通常是「规格项 + 规格值 + 对应库存价格」三张表或一个 JSON 字段。第三是库存，库存扣减必须在下单时用数据库行锁或乐观锁处理，否则并发下单会超卖。
-- 商品表核心字段 CREATE TABLE goods ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(128) NOT NULL, category_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, cover VARCHAR(255), detail TEXT, status TINYINT DEFAULT 1, -- 1上架 0下架 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 下单时扣库存，用条件更新防止超卖 UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock >= 1; -- 检查 affectedRows，如果为0说明库存不足stock >= 1这个条件就是防超卖的关键。不要先查库存再更新，那样在并发下会出问题。直接带条件更新，根据影响行数判断是否成功。SKU 的库存扣减同理，只是条件里要加上 SKU 的标识。
4.2 订单模块：状态机与超时取消
订单是有状态的，常见状态包括待付款、待发货、待收货、已完成、已取消。状态之间的流转必须严格，不能从待付款直接跳到已完成。后端每次改状态前都要校验当前状态是否允许这个操作。另一个重点是超时取消——用户下单后一定时间内没付款，订单要自动取消并回滚库存。
// 订单状态流转校验，简化版 const ORDER_STATUS = { PENDING: 0, // 待付款 PAID: 1, // 待发货 SHIPPED: 2, // 待收货 DONE: 3, // 已完成 CANCELED: 4 // 已取消 }; // 允许的状态流转 const ALLOW_TRANSITION = { 0: [1, 4], // 待付款 -> 待发货 或 已取消 1: [2], // 待发货 -> 待收货 2: [3], // 待收货 -> 已完成 3: [], 4: [] }; function canTransition(from, to) { return ALLOW_TRANSITION[from] && ALLOW_TRANSITION[from].includes(to); }超时取消一般用定时任务实现，每隔一分钟扫描一次超过时限的待付款订单，批量取消并回滚库存。回滚库存时同样要用条件更新，并且要记录回滚日志，方便对账。如果源码里没有这个定时任务，你需要自己加，否则未付款订单会一直占着库存。
4.3 支付模块：签名、回调、对账三个环节
小程序支付用的是微信支付，流程是：后端生成预支付订单并签名，返回给小程序调起支付，用户付款后微信回调后端，后端更新订单状态。三个环节各有坑。签名环节，参数顺序、大小写、密钥都要对，错一个字符就报签名错误。回调环节，必须验证回调的签名，不能收到请求就直接改订单状态，否则会被伪造回调。对账环节，定期拉取支付账单和本地订单比对，处理掉单和重复支付。
// 支付回调处理的核心逻辑（伪代码结构） app.post('/api/pay/notify', (req, res) => { const notifyData = req.body; // 1. 验证签名，防止伪造回调 if (!verifySign(notifyData)) { return res.send(failXml('签名验证失败')); } // 2. 检查订单是否已处理，防止重复回调 const order = getOrderByNo(notifyData.out_trade_no); if (order.status !== 0) { return res.send(successXml()); // 已处理过，直接返回成功 } // 3. 更新订单状态和支付信息 updateOrderPaid(order.id, notifyData.transaction_id); // 4. 返回成功，否则微信会重复通知 res.send(successXml()); });回调接口必须做幂等处理，因为微信可能会重复通知。判断依据是订单状态，如果已经是已付款就直接返回成功，不要重复改状态和加积分。回调返回的 XML 格式也要对，返回失败微信会按策略重试，重试多次都失败会影响后续收款。
5. 部署上线与二次开发避坑：那些源码不会告诉你的事
5.1 从本地到服务器：域名、HTTPS、合法域名配置
本地跑通不等于能上线。上线前要准备：一台服务器、一个已备案的域名、HTTPS 证书。小程序要求所有请求走 HTTPS，且域名要在微信公众平台配置为合法域名。配置路径是「开发」→「开发设置」→「服务器域名」，把后端接口域名加进去。注意域名不能带端口，必须是 443 端口的标准 HTTPS。
部署后端时，数据库密码、支付密钥这些敏感信息不要写在代码里，用环境变量或配置文件管理。Node 项目可以用 pm2 守护进程，保证服务挂了能自动重启。数据库要定期备份，订单和支付相关的表尤其重要。
5.2 二次开发时最容易改错的五个地方
第一，改价格显示逻辑时忘了改订单快照。订单里应该保存下单时的商品价格，而不是关联商品表实时查，否则商品改价后历史订单金额会变。第二，加新页面时忘了在 app.json 里注册，页面白屏。第三，改接口返回结构时没同步改前端解析，页面报错。第四，加优惠券逻辑时没考虑叠加和互斥规则，导致金额算错。第五，改数据库字段后没更新模型定义，接口报字段不存在。
5.3 常见问题排查：白屏、请求失败、支付报错
现象：小程序首页白屏，控制台无报错。原因通常是 app.json 里页面路径配错，或者首页的 onLoad 里有同步报错被吞了。解决方法是打开开发者工具的调试器，看 AppData 和页面栈，确认首页有没有被正确加载。
现象：请求全部失败，提示不在合法域名列表。原因是你没勾选「不校验合法域名」，或者 baseUrl 写的是 IP 加端口。开发阶段勾选不校验即可，上线前必须换成 HTTPS 域名。
现象：支付调起时报「签名错误」。原因是签名参数不对，常见的有：参数没按字典序排列、密钥用错（用成了小程序密钥而不是支付密钥）、金额单位不对（微信支付用分，不是元）。逐个核对，用官方签名工具验证一次。
现象：支付成功后订单还是待付款。原因是回调没收到或处理失败。检查服务器日志有没有收到回调请求，回调地址是否公网可访问，返回格式是否符合微信要求。本地开发时回调没法直接测，可以用内网穿透工具临时映射一个公网地址来调试。
现象：商品图片不显示。原因是图片域名没配或者图片路径是相对路径。小程序里图片要用完整 URL，且域名要在合法域名里配置。如果图片存在本地服务器，确保静态资源目录配置正确。
6. 用测试数据验证商城闭环：一个可复现的检查清单
跑通一套商城源码，最终要验证的是一个完整闭环：浏览商品 → 加入购物车 → 下单 → 支付 → 订单状态变更 → 库存扣减。这个闭环里任何一环断了，商城就不能算真正可用。我一般会准备一组测试数据来验证，而不是靠手动点。
-- 插入测试分类和商品，验证首页和详情 INSERT INTO category (id, name, parent_id) VALUES (1, '测试分类', 0); INSERT INTO goods (name, category_id, price, stock, cover, status) VALUES ('测试商品A', 1, 9.90, 100, '/images/test-a.jpg', 1), ('测试商品B', 1, 19.90, 50, '/images/test-b.jpg', 1);插入后刷新小程序首页，应该能看到两个商品。点进详情，加购物车，下单，然后在订单列表里看到待付款订单。支付环节如果没法真实支付，可以手动改数据库把订单状态改成已付款，然后验证库存有没有扣减、订单状态有没有正确流转。这个手动改状态的过程能帮你理解订单状态机是怎么工作的。
验证库存扣减时，注意看下单前后的 stock 值。如果下单后库存没变，说明扣减逻辑没执行或者事务回滚了。如果库存变成负数，说明防超卖条件没生效。这两个问题在上线前必须解决。
二次开发时，我习惯先把这个闭环跑通再改任何代码。因为一旦改了商品或订单逻辑，闭环可能就断了，而断在哪需要花时间排查。保持一个可用的基线，改坏了能回退，这是最省时间的做法。希望帮到你。
本文还有配套的精品资源，点击获取
