简介这是一套完整的微信小程序商城项目源码面向前端开发者、小程序初学者及电商类应用学习者可用于快速搭建具备商品展示、分类浏览、购物车与订单管理等基础功能的轻量级商城系统。资源包共67个文件包含9个JavaScript逻辑文件如app.js、页面业务脚本、7个WXML结构文件、7个WXSS样式文件、7个JSON配置文件含app.json全局配置及页面路由以及30张PNG和4张JPG素材图整体压缩后仅3.3MB轻量易部署。已有10160人下载学习适合作为小程序开发入门实践案例或二次开发基础模板。源码结构清晰涵盖app根目录与pages多页面组织方式附带完整静态资源与基础交互逻辑便于理解小程序生命周期、组件通信及API调用流程是掌握微信小程序工程化开发的实用参考。 我见过太多人下载了一套“微信小程序 商城(源码)”之后第一反应是直接点开模拟器看效果然后对着满屏报错发呆或者倒腾一晚上也没搞明白购物车数据到底存在哪里。源码的本质不是一份能跑的代码而是一张完整的业务地图——商品、购物车、订单、支付、登录五个环节串起来才是商城的最小闭环。这篇文章我就从一套可用的微信小程序商城源码出发拆一拆它的整体骨架、核心模块、开发期最容易踩的坑以及从“能跑”到“能上线”之间还差的那几步。不管你是刚接触小程序开发还是准备在已有项目里集成商城模块都可以照着这份经验去对照自己的代码。1. 这套商城源码的骨架从页面清单到全局配置1.1 源码包的三个层次小程序端、后端接口、管理后台市面上很多标着“微信小程序商城源码”的下载包其实不是一份代码而是三个部分小程序前端、接口后端、管理后台。我拿到源码第一件事一定不是打开微信开发者工具而是先看目录结构把这三层分清楚。小程序前端放在miniprogram/或直接放在根目录主要文件是app.js、app.json、pages/下的页面文件。接口后端常见的有 PHP、JavaSpring Boot、Node.js 三套体系。你看到的api/、server/、backend/目录基本就是它。管理后台处理商品上架、订单发货、库存修改的 Web 系统一般是 Vue 或 React 写的独立工程。热搜词里出现了“php源码”“springboot”“linuxapi源码”说明大家下载的商城源码十有八九是这三种后端技术栈。我的建议是选后端时优先看接口文档是否齐全、数据库 SQL 文件能不能直接导入而不是纠结哪个语言更高级。商城业务模型是固定的用户表、商品表、SKU 表、订单表、支付流水表哪套后端都是围绕这几张表转。源码能不能跑起来往往取决于你本地的 PHP 版本或 JDK 版本匹不匹配这个比语言本身更影响体验。1.2 页面结构一条完整的用户动线商城的页面不需要多花哨但动线必须完整。我拆过的商城源码里最精简的结构通常是下面这组页面页面主要作用核心交互首页展示推荐位与活动入口轮播图、金刚区、推荐商品流分类页商品检索左侧类目、右侧商品列表商品列表页按条件筛选商品排序、筛选、分页加载商品详情页决策转化核心SKU 选择、加入购物车、立即购买购物车页批量管理与结算勾选、改数量、合计金额订单确认页信息核对收货地址、优惠券、备注支付页支付发起调起微信支付订单列表/详情页售后与物流订单状态展示、取消、退款对应的app.json里 pages 字段长这样{ pages: [ pages/index/index, pages/category/category, pages/cart/cart, pages/user/user, pages/goods/list, pages/goods/detail, pages/order/confirm, pages/order/pay, pages/order/list, pages/order/detail ], window: { navigationBarBackgroundColor: #ffffff, navigationBarTextStyle: black, navigationStyle: custom }, tabBar: { list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/category/category, text: 分类 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/user/user, text: 我的 } ] } }注意这里的navigationStyle: custom很多商城源码都会开启自定义导航栏这会给后续适配带来一系列麻烦后面我会单独讲。1.3 app.js 里的两件大事登录态和全局购物车数量app.js在商城项目里不只是生命周期入口更是登录状态和全局数据的枢纽。一份合格的商城源码app.js里至少要做好两件事。第一冷启动时静默登录。小程序端拿到 code传给后端换取 openid 和自定义 token。商城不像内容类应用可以游客模式随便逛购物车、订单、优惠券都绑定用户身份所以这个登录动作要在启动阶段就完成但又不能阻塞页面渲染。常见做法是在onLaunch里发起登录请求同时把 Promise 存到全局变量中这样后续所有页面在调用需要登录态的接口时可以先await这个登录 Promise。App({ onLaunch() { this.loginPromise this.login() }, login() { return new Promise((resolve, reject) { wx.login({ success: async ({ code }) { const res await request.post(/auth/login, { code }) wx.setStorageSync(token, res.token) resolve(res) }, fail: reject }) }) } })第二维护全局购物车数量。底部 tabBar 的购物车角标基本上是商城的标配但直接在每个页面onShow里都去读一次购物车列表有点浪费。更稳的方式是维护一个全局的cartCount购物车操作成功后更新它tabBar 页面在onShow时读取最新值。很多源码在这块处理得比较粗暴要么刷新不及时要么多重页面同时操作时数据错乱。你拿到源码后可以优先检查这两个点它们直接决定用户体感。2. 技术选型复盘原生小程序为什么更适合商城2.1 原生 vs uni-app 的对比热搜词里有一条很扎眼“uniapp做微信小程序在手机上预览没问题但是在微信开发者上是白片”。这说明很多人正在用跨端框架做小程序然后被各种环境差异折磨得够呛。我自己也经历过不同框架的来回切换最后做商城类项目时还是回到了原生小程序。这不是说原生有多先进而是商城这个业务场景有一个很明显的特征页面多、状态多、平台能力依赖强。微信小程序为电商场景提供了很多原生能力比如wx.requestPayment支付、wx.login静默登录、wx.getSetting获取收货地址、wx.chooseMedia上传评价图片。这些能力用原生 API 调用最简单直接而用跨端框架时光是把这些平台 API 的差异抹平就需要不少兼容代码。维度原生小程序uni-appTaro上手成本需要学 WXML/WXSSVue 语法即可React 语法即可调试方式开发者工具天然支持需要编译后再调试需要编译后再调试多端支持仅微信微信/支付宝/抖音/H5微信/H5/React Native平台新 API 可用性同步更新依赖框架版本跟进依赖框架版本跟进包体积控制精细到页面级运行时有一定冗余运行时有一定冗余性能损耗无中间层有编译和运行时转换有编译和运行时转换我自己做商城的经验是如果只做微信端原生是省心选项如果团队已经熟 Vue 且要求同时覆盖支付宝小程序和 H5那 uni-app 是合理选择。关键是要接受一个事实——跨端框架一定会带来“某个端表现不一致”的问题这时候你需要花额外的调试时间。2.2 白屏问题到底是怎么来的回到“手机上预览没问题开发者工具白屏”这个问题我来还原一下我遇到过的几种可能。第一种基础库版本不一致。手机微信的“调试基础库”可能比开发者工具里默认的基础库版本高或低。某些新 API 在新基础库上正常但在开发者工具的老基础库上直接报错界面就白给了。处理方式是点击开发者工具右上角的“详情 - 本地设置 - 调试基础库”切换成和手机一致的版本。第二种编译错误被隐藏了。开发者工具白屏时并不一定没有任何提示很多情况下是控制台输出了报错但页面渲染被中断。跨端框架编译后的代码有一层运行时报错很难定位你要先把报错信息完整截图再对应到源码的具体行。第三种CSS 兼容性问题。微信开发者工具基于 Chromium手机端用的是系统 WebView 或 Skyline 渲染对于部分position: fixed、flex嵌套、env(safe-area-inset-bottom)的解析会有差异。表现就是开发者工具正常真机上某个区块塌陷严重时整页内容不可见。我的排查顺序是先看 Console 有没有红色报错 → 再切基础库版本 → 再关掉“增强编译”和“ES6 转 ES5”等编译选项逐个排除 → 最后用 vConsole 在真机上打印页面数据看是不是 setData 层面就把数据搞丢了。2.3 什么情况下可以选 uni-app我不反对跨端框架。如果你的项目是“平台矩阵”打法——微信、支付宝、抖音都要上团队又只有一套前端人力那 uni-app 的性价比就出来了。但选它之前你要想清楚一件事商城里有大量页面是强交互的跨端框架在标签页切换、长列表渲染上的性能会打折扣。另外如果源码本身就是 uni-app 写的你在微信开发者工具里看到的可能是编译后的 dist 目录而不是源码目录。这时候你需要先跑一次npm run dev:mp-weixin再打开编译输出目录很多“源码打开白屏”其实就是打开错了目录。3. 商城核心模块的源码拆解商品、SKU、购物车、订单3.1 商品列表和详情数据解构、骨架屏与价格格式化商品模块是商城的地基。我检查一套商城源码时会先看商品列表接口返回的数据结构是否合理。一个典型的商品列表项包含这些字段id、title、cover、price、sales、stock、skuList。很多源码问题出在把一个商品的完整 SKU 列表塞进了列表接口导致列表页数据量巨大、渲染卡顿。正确的做法是列表接口只返回轻量字段详情接口再返回完整 SKU 和详情图文。这是商城性能的第一个分水岭。列表页还有一个容易被忽略的细节价格字段的单位。后端为了精确计算价格通常以“分”存储前端拿到 1290 需要格式化为 12.90。如果源码里直接展示原始数字你会看到 1290 元的诡异价格。处理方式很简单function formatPrice(cents) { return (cents / 100).toFixed(2) }商品详情页的图片一般比较多如果不做处理进入页面时会有一段时间的白屏。一套合格的源码应该在 WXML 里用wx:if控制骨架屏的显示等数据请求完成后再切换成真实内容。这个逻辑不难但很体现细节view wx:if{{loading}} classskeleton view classskeleton-title/view view classskeleton-price/view /view view wx:else !-- 真实商品内容 -- /view3.2 SKU 规格选择为什么系统单选框在这里不可用热搜词里有“微信小程序单选框”很多新手做商城时会搜“小程序单选框怎么做商品规格”。我必须说一句商品规格选择的正确实现不是单选框而是一套规格组合匹配逻辑。一个商品有颜色、尺码两个维度这就是一个二维规格矩阵。当用户选了“红色”和“XL”前端要去 SKU 列表里找出同时满足这两个条件的 SKU再展示对应的价格和库存。如果该组合不存在对应的规格按钮应该置灰。原生radio-group只适合互斥选项而 SKU 选择是多维状态组合每个维度内部互斥、维度之间互相影响。所以在商城源码里这个模块通常是自定义组件核心逻辑大致是// 规格选择选中的规格值数组 function findSku(selectedSpecs, skuList) { return skuList.find(sku { return selectedSpecs.every(spec sku.specs.includes(spec)) }) }这个逻辑在小型商城够用但要注意一个边界情况当 skuList 数据量很大的时候全量遍历性能会变差你可能需要预处理一个规格索引对象用空间换时间。源码里如果循环嵌套很多层就是需要优化的信号。3.3 购物车本地存储方案与版本兼容购物车数据存哪这是每套商城源码都必须回答的问题。成熟的方案是“本地存储 后端同步”双轨制未登录或弱网时先写本地登录后定时与后端同步。不成熟的做法是只存内存用户一关小程序购物车就空空如也。我见过一套源码的购物车实现缓存 key 写死成cart压根没考虑多用户切换的问题。你应该用cart_${userId}这样的命名空间避免用户 A 退出后用户 B 还能看到 A 的购物车数据。存储结构上每个购物车条目应该包含{ skuId: 1001_red_xl, goodsId: 1001, title: 某某商品, specText: 红色 XL, price: 12900, count: 2, selected: true, cover: https://example.com/cover.jpg }selected字段很关键它决定了结算页能勾选出哪些商品。很多源码把这个状态存在页面 data 里没有持久化导致下次进入购物车时所有勾选状态丢失用户需要重新勾选。改数量时还要注意防抖因为每次-或都触发一次 setData 和存储写入高频操作会让低端机明显卡顿。简单做法是本地先改 UI 和缓存等用户停止操作 500ms 后再请求后端同步。3.4 订单流程与虚拟支付合规边界订单模块是商城最复杂的部分一套完整的源码至少包含创建订单、预支付、支付回调、订单状态机流转。我建议你先看订单状态是否清晰待支付、已支付、已发货、已完成、已取消、退款中等。支付这块必须提醒一句微信小程序对虚拟支付管控非常严格。实体商品走wx.requestPayment没有问题但如果你在卖会员、课程、充值这类虚拟商品iOS 端在微信小程序内直接调起虚拟支付是违规的平台会限制甚至封禁支付能力。很多商城源码为了实现虚拟商品的支付会做 H5 中转或跳转公众号支付但这类方案有合规风险如果你不是合规运营方不建议在正式项目里这么做。创建订单的正确流程应该是前端把商品 ID、SKU ID、数量、收货地址提交到后端 → 后端校验库存和价格 → 创建订单并返回订单号 → 前端调起支付。注意支付金额必须以服务端计算为准不能信任前端传的金额。这是商城源码里最核心的安全底线之一。4. 开发期绕不开的三个细节导航栏、request 封装、地图组件4.1 自定义顶部导航栏的高度计算热搜词里问到“微信小程序顶部导航栏高度”这里把答案一次说透。当你在app.json里设置了navigationStyle: custom后页面内容会延伸到屏幕最顶部如果不用safe-area适配状态栏文字会和页面标题重叠。正确的高度计算方式是const windowInfo wx.getWindowInfo() const menuRect wx.getMenuButtonBoundingClientRect() // 状态栏高度 const statusBarHeight windowInfo.statusBarHeight // 菜单按钮胶囊高度 const menuHeight menuRect.height // 导航栏总高度 (胶囊顶部到状态栏顶部的距离 * 2) 胶囊高度 const navBarHeight (menuRect.top - statusBarHeight) * 2 menuHeight这套公式的原理是胶囊按钮在垂直方向上是居中于自定义导航栏的所以导航栏高度 胶囊上方留白 × 2 胶囊高度。不同机型的状态栏高度和胶囊尺寸不同但都满足这个几何关系。拿到navBarHeight后给自定义导航栏设置该高度再用padding-top: statusBarHeight让内容避开状态栏。好源码会把这段计算封装进全局方法或自定义组件里而不是每个页面写一遍。如果你拿到的源码里到处复制这段逻辑可以考虑重构成工具函数。4.2 request 封装登录态失效与并发请求重试商城页面一旦多了网络请求不可能每个页面裸写wx.request。一套靠谱的源码一定会封装统一的 request 方法我见过最常用的模式是 Promise 封装 拦截器。核心逻辑长这样const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data) } else if (res.statusCode 401) { // token 失效重新登录后再发起一次请求 reLogin().then(() { request(url, method, data).then(resolve).catch(reject) }).catch(reject) } else { reject(res.data) } }, fail(err) { reject(err) } }) }) }这里有个关键设计当 token 失效时自动重新登录并重放原请求。商城场景里用户长时间停留在某个页面后 token 过期很常见如果没有这个重放机制用户会莫名其妙地看到请求失败体验很差。另外一个容易忽略的点是baseUrl要区分环境。开发环境用http://192.168.x.x:8080测试环境用https://test-api.xxx.com生产环境用https://api.xxx.com。源码里如果只写死一个地址你联调时就得频繁改代码正确做法是封装一个config.js按环境切换。4.3 地图组件选型微信原生 map 与第三方地图的差异有人问“微信小程序可以使用天地图画地图组件吗”这个问题在商城场景里通常出现在“门店自提”或“同城配送”模块。原生map组件走的是腾讯位置服务展示商家门店时可以直接用它支持 marker 标注、路线规划还能配合wx.getLocation拿到用户当前位置。如果你的需求是展示天地图图层原生 map 组件并不可用通常要用web-view加载天地图网页版或者在 web-view 里嵌入天地图 JS API。但这时候要注意web-view的域名必须在小程序后台配置业务域名并且要过 ICP 备案验证。很多源码在这里栽跟头web-view页面直接白屏因为业务域名没配好。在商城项目里我建议优先用原生 map 组件别一上来就接第三方地图。原生 map 在性能、手势交互、与小程序生命周期绑定上都更自然。只有在需要展示特定地图服务商的独家图层时再考虑 web-view 方案。5. 性能优化与问题排查分包异步化、白屏、真机调试5.1 分包与分包异步化商城包体积管理小程序主包有 2MB 限制商城这种页面多、图片多、组件库重的项目很容易就撞到上限。解决方案就是分包加载。我拆过一套商城源码把商品、订单、用户中心拆成三个分包主包只保留 tabBar 页面和公共工具库。{ subpackages: [ { root: packageGoods, pages: [ pages/list, pages/detail ] }, { root: packageOrder, pages: [ pages/confirm, pages/pay, pages/list ] }, { root: packageUser, pages: [ pages/coupon, pages/address ] } ] }分包配置不难真正有技术含量的是分包异步化。常规分包之间不能互相引用资源但你用require.async或开启“分包异步化”后可以在一个分包里异步加载另一个分包的 JS 或组件。这个特性很适合商城的优惠券弹窗或活动页这类低频但高流量页面按需加载能显著减少首次启动体积。注意分包异步化需要基础库 2.11.2 以上版本同时开发者工具里要手动开启“使用 npm 分包异步化”之类的配置。源码里如果没有这个配置你在低版本基础库上运行会直接报错。5.2 真机白屏问题排查链路真机白屏是商城源码被问得最多的问题之一而且原因五花八门。我根据实际经验整理一个排查顺序先用 vConsole 看日志。在app.js里引入wechat-miniprogram/vconsole或者直接开着开发者工具的“真机调试”看 Console 有没有红色报错。真机白屏十有八九伴随某个 JS 运行时报错。检查分包加载状态。如果你的页面在分包里而分包某个资源加载失败页面会表现为白屏。在 Network 面板里看对应分包 JS 有没有加载成功。检查图片域名有没有配。商城首页和商品详情页全是图片如果图片服务器不在 downloadFile/request 合法域名列表里图片加载会失败页面布局被撑乱甚至露出空白。这不是 JS 报错但视觉上和白屏很像。检查基础库兼容。真机微信版本可能较旧如果源码里用了wx.createSelectorQuery().selectViewport().scrollOffset()这类 API在部分旧基础库上行为不一致。建议看源码里有没有判断基础库版本后再调用 API 的逻辑。页面栈溢出。某些商城跳转逻辑有 bug用户反复跳转会撑爆页面栈导致新页面渲染时白屏。排查方式是清掉之前的页面栈用wx.redirectTo代替wx.navigateTo来避免无限叠加。白屏问题最怕的不是修不好而是没有固定排查顺序。按上面这套链路走一遍大多数问题都能定位到具体原因。5.3 网络调试从开发者工具到真机抓包商城这种项目接口联调是家常便饭。微信开发者工具自带的 Network 面板是最直接的调试工具能看到每个请求的 URL、请求头、响应体、耗时还能直接复制为 cURL。大部分接口问题在开发者工具里就能定位。但真机环境有时候会复现不出开发者工具的问题因为手机网络安全策略更严格。常用的做法是打开开发者工具的“真机调试”它会把真机上的网络请求实时同步到电脑上。很多人想用第三方抓包工具看真机请求但微信小程序对 HTTPS 证书有强校验自定义 CA 证书在大多数情况下会被拦截。这不是 bug而是安全机制碰到请求失败时应该先检查证书和域名而不是想着怎么绕过校验。另外要说明一点商城接口联调时请求参数打印是个好习惯。在 request 封装里加一段console.log把 url、method、data、响应结果都打出来会大幅提升定位问题的速度。源码里如果不打印你自己加上就好调试完再注释掉不影响线上。6. 从源码到上线最后几道关口与扩展方向6.1 上线前必须过完的自查清单很多源码在本地能跑但提交审核时反复被拒问题往往不在代码而在配置和资质。我整理了一份上线前自查清单你可以直接对着逐项核实。服务器域名request、uploadFile、downloadFile合法域名必须在小程序管理后台配置且必须是 HTTPS。用户隐私保护指引微信要求小程序必须完善用户隐私保护指引在你调用wx.login、wx.getLocation、wx.chooseImage等接口前需声明对应隐私用途。订单与支付场景资质商城属于电商类目需要提供对应的营业执照或行业资质。虚拟商品类目审核更严格没有资质别硬上。UGC 内容安全如果商城有商品评价、社区模块用户上传的内容要接入内容安全检测接口否则容易被审核驳回。登录态时效确保 token 有过期时间并且前端有续期机制不能让用户一进场就无限期挂着。静默更新与版本号app.json里的versionName要跟着发布版本同步更新方便线上定位问题。这些项目在源码里往往没有体现因为它们属于运营和配置层面的事。但恰恰是这些“文档之外”的关卡决定了你的商城能不能顺利出现在微信里。6.2 源码扩展方向同声传译、短剧频道、会员体系一套商城源码跑通之后往上叠加新能力是常见需求。如果你要把商城做成内容电商可以考虑短剧频道模块——把短剧列表嵌入首页作为种草/引流内容。不过短剧内容需要相应版权和内容审核能力不是放个视频就有流量。如果你要做跨语言用户群体语音能力或许有用。微信同声传译插件能实现语音识别和文本翻译比如在客服聊天里实时翻译但对插件权限有要求不是随随便便开通的。会员体系和会员价是商城最自然的扩展方向。实现上只需要在用户表和商品表上各加一个等级字段再在小程序端根据会员等级展示对应价格即可。源码如果连这么基础的角色体系都没有后续扩展会比较吃力。6.3 关于防截屏这类边界需求有人搜索“微信小程序 控制不让截屏”通常是想保护优惠券码或会员码。微信小程序确实提供了一个 iOS 端的防截屏 APIwx.setVisualEffectOnCapture设置为hidden后页面在截屏时会变模糊或隐藏敏感内容。但这只对 iOS 有效Android 端没有统一的系统级防截屏机制。如果你的商城销量不错可以考虑给电子卡券页面单独加一个这个 API作为一种体验增强但不要把它当成安全方案。真正防刷还得靠服务端风控——限制领取频率、校验设备指纹、动态生成二维码这些。最后分享一点做商城源码的体会源码的价值不在于它跑得起来而在于你出了问题以后能不能读懂它、改得了它。我最常做的验证方式是拿到源码后先模拟一遍“用户从首页逛到商品详情选好规格加购提交订单并支付成功”的完整链路这条链路上任何一个环节出错都能反映这套源码的健壮程度。如果你正在看一套商城源码不妨也按这个链路走一遍比看任何文档都直观。本文还有配套的精品资源点击获取