简介：这份微信小程序电商源码合集，聚焦小程序开发场景，覆盖外卖、门店、展示、批发商城、分销等多种电商业务模板，适合从初学者到进阶开发的各类人群用于学习、参考或直接二次开发。压缩包共1287个文件，大小仅1.96MB，其中wxml负责页面结构、wxss负责样式、js处理交互逻辑、json存储配置，另含png/jpg图片素材与md说明文档，结构完整且轻量易检。资源包内还集成了异步封装、接口调用、Markdown渲染等工具脚本，体现了小程序开发中的常见工程写法，有助于快速理清前端页面与逻辑层的组织关系。目前该资源已累计有3075人学习或下载，具有一定的通用性和参考价值。无论是课程设计、毕设演示，还是商家小程序的快速原型验证，都能从中找到对应模块并加以复用。
1. 拆开zip先看目录：这套微信小程序电商源码的入口与页面骨架
下载下来的微信小程序电商源码.zip解压后，第一眼看到的不是一堆.wxml和.wxss，而是app.js、promise.js、clientInterface.js、showdown.js以及fws_bg2.jpg、特价title.jpg、333.jpg这些资源文件。这个结构说明它不是一个纯展示模板，而是带接口层和全局状态管理的电商脚手架，外卖、门店、分销、批发商城这些场景都是在这个骨架上长出来的。
对刚接触小程序开发的人来说，它最大的价值在于clientInterface.js这张「接口网关」——所有页面都不直接调wx.request，而是统一走这一层，这对后续对接自己的后端、处理登录态刷新和错误码，省掉了大量重复代码。而对有 5 年以上开发经验的从业者，值得看的是它如何用promise.js做基础库兼容、如何在app.js里协调异步初始化顺序，这些是很多项目上线后才暴露性能问题的根源。
2. app.js 初始化与全局登录态：微信小程序电商项目的启动链路
2.1 app.js 里到底初始化了什么：globalData 与 onLaunch 执行顺序
打开app.js，核心是App({})注册方法里的三个生命周期：onLaunch、onShow、onHide。电商小程序在onLaunch阶段至少要完成三件事：拉取店铺配置（店铺名称、主题色、运费模板开关）、静默登录换取 token、把必要的全局数据写入globalData。
globalData不是简单的「全局变量」，它是页面之间共享状态的唯一合规途径。比如门店小程序的当前城市、外卖场景的配送地址、分销场景的邀请人 ID，都应该挂在globalData下，而不是用wx.setStorageSync硬塞，因为缓存是异步落盘的，且清理策略不可控。常见写法如下：
// app.js App({ globalData: { shopInfo: null, token: '', userInfo: null, systemInfo: null }, onLaunch: function () { const that = this // 先取系统信息，后续所有页面都要用到状态栏高度 try { const res = wx.getSystemInfoSync() that.globalData.systemInfo = res } catch (e) { console.error('getSystemInfoSync failed', e) } // 并行发起两个初始化请求：先拿配置，再拿登录态 that.initShopConfig() that.initLogin() }, initShopConfig: function () { // 走 clientInterface 统一接口层，而不是直接 wx.request const client = require('./clientInterface.js') client.get('/api/shop/config', {}).then(res => { this.globalData.shopInfo = res.data }).catch(err => { console.warn('店铺配置拉取失败，使用默认配置', err) }) } })这段代码的关键点在于initShopConfig和initLogin是并行触发的，两者没有依赖关系。如果登录接口返回的 token 是后续所有下单接口的凭证，但店铺配置不依赖 token，那么并行请求能节省一次网络往返。如果有人把登录写成了await阻塞配置拉取，首屏会多出 300~500ms 的等待，这在弱网环境下体验差异很明显。
2.2 Promise.all 并发刷新配置与登录：避免串行等待
在源码同目录的promise.js里，打包了一个 Promise 的兼容实现。为什么电商源码还要带这个文件？因为微信小程序的基础库版本碎片化严重，如果最低支持版本定在 2.10 以下，Promise.finally这类方法可能不存在，所以源码里对 Promise 做了 polyfill。
实际项目中，更稳妥的做法是用Promise.all把两个初始化任务合并，等全部完成后再进入页面渲染，避免出现「配置还没回来，首页已经画出来了」的白屏错乱：
// app.js 中合并并发初始化 const Promise = require('./promise.js') const client = require('./clientInterface.js') App({ onLaunch: function () { const p1 = client.get('/api/shop/config', {}) const p2 = client.post('/api/auth/login', { code: this.getWxLoginCode() }) Promise.all([p1, p2]).then(([configRes, loginRes]) => { this.globalData.shopInfo = configRes.data this.globalData.token = loginRes.data.token // 所有依赖数据的页面在此之后才能稳定渲染 }).catch(err => { console.error('初始化失败，走降级逻辑', err) }) } })这里有一个容易被忽略的坑：wx.login拿到的code只能用一次，5 分钟内有效，而且后端拿去换openid和session_key之后立刻失效。如果Promise.all里有一个请求失败，整个 Promise 链进入catch，但wx.login的 code 已经被消费过一次，下次重试必须重新wx.login，不能复用旧的 code。所以接口层需要单独封装一个login()方法，每次调用都重新走wx.login。
2.3 从 app.json 到页面注册：tabBar 页面与分包策略
电商小程序的app.json里除pages数组外，最重要的是tabBar配置。外卖、门店、商城这三类场景的 tabBar 结构差异不大，通常都是首页、分类、购物车、我的四个 tab。但要注意，tabBar 页面的iconPath和selectedIconPath图片不得大于 40KB，且必须是本地路径。压缩fws_bg2.jpg这类大背景图时，建议用 TinyPNG 这类工具先压一遍，否则真机预览会直接报「本地资源无法从网络加载」。
如果这个 demo 里包含商品详情页、订单列表页、分销中心页，它们最好放入subpackages分包。主包只保留 tabBar 页面和公共组件，商品详情这类低频页放进分包，启动时可以少下载几百 KB。源码里333.jpg如果是商品占位图，放在静态资源目录下即可，但要注意小程序包体限制：主包 + 分包总大小上限 20MB（2.30 之前）或 30MB（2.30 之后）。以下是一张文件职责对照表：
| 文件/资源 | 职责定位 | 初始化时机 |
|---|---|---|
app.js/app.json | 全局生命周期与页面注册 | App 启动 |
promise.js | Promise polyfill，兼容旧基础库 | 最先加载（require引入） |
clientInterface.js | 统一 API 请求层、错误码映射 | app.js 初始化时引用 |
showdown.js | Markdown 渲染，用于商品详情、公告 | 页面进入时动态 require |
fws_bg2.jpg | 首屏背景图 / 弹窗背景 | 首页 onLoad 预加载 |
特价title.jpg/333.jpg | 促销位 banner、商品缩略图 | 按需加载 |
3. clientInterface.js 接口层设计：wx.request 封装、超时重试与参数签名
3.1 接口层为什么要单独拆文件：页面不持 wx.request
很多小程序项目把登录 token 直接wx.setStorageSync('token', xxx)，然后在每个页面里getStorageSync拿出来拼到 header 里。这套源码把这件事收敛到了clientInterface.js里，每个页面只需要关心「我要请求什么数据」，而不需要关心 token 从哪里来、过期了怎么办。
接口层必须承担四个职责：统一拼接baseURL、自动附加 token 和公共参数、统一处理 HTTP 状态码、对特定错误码做全局兜底。下面是源码里最常见的一种封装范式：
// clientInterface.js const Promise = require('./promise.js') const BASE_URL = 'https://api.example.com' const TOKEN_KEY = 'token' function request(method, path, data = {}, options = {}) { const token = wx.getStorageSync(TOKEN_KEY) return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method: method, data: data, timeout: options.timeout || 10000, header: { 'Content-Type': 'application/json', 'Authorization': token ? `Bearer ${token}` : '' }, success: function (res) { // res.statusCode 是 HTTP 状态码，res.data.code 是业务状态码 if (res.statusCode === 401) { // token 过期，触发全局重登录 handleUnauthorized() reject(new Error('登录已过期')) return } if (res.statusCode >= 200 && res.statusCode < 300) { if (res.data && res.data.code === 0) { resolve(res.data) } else { reject(new Error(res.data.message || '接口异常')) } } else { reject(new Error(`HTTP ${res.statusCode}`)) } }, fail: function (err) { if (options.retry > 0) { // 网络层失败时对 GET 请求做一次重试 if (method === 'GET') { return request(method, path, data, { ...options, retry: options.retry - 1 }) } } reject(err) } }) }) } module.exports = { get: (path, data, options) => request('GET', path, data, options), post: (path, data, options) => request('POST', path, data, options) }注意fail回调里的重试条件：只有 GET 请求重试是安全的，POST 请求在「请求已发出但响应超时」的状态下无法确认服务器是否已经处理，盲目重试会导致重复下单。在电商场景里，下单接口重试必须在订单号层面做幂等，普通场景不重试。
3.2 超时处理：连接超时与响应超时的区别
wx.request的timeout参数在基础库 2.10.0 之后才支持，它同时覆盖连接超时和响应超时。但真实网络环境下，连接成功之后服务器长时间不返回数据，和连接根本建立不起来，这两种失败原因完全不同。
常见做法是在接口层外面再包一层业务超时控制：
function withTimeout(promise, ms = 15000) { return new Promise((resolve, reject) => { const timer = setTimeout(() => { reject(new Error('请求超时')) }, ms) promise.then(res => { clearTimeout(timer) resolve(res) }).catch(err => { clearTimeout(timer) reject(err) }) }) }这样做的意义在于：wx.request的fail回调里网络异常和超时混在一起，业务上需要区分「网络断了请检查设置」和「服务器忙请稍后再试」。上述代码可以包装在request方法的返回值上，timeout由调用方按接口类型传入。下单、支付这类高优先级接口给 15 秒，商品列表这类查询接口给 10 秒就够。
3.3 签名与防篡改：下单和支付接口的参数签名
外卖、分销这类带资金流转的场景，下单接口不能裸奔。小程序端没有绝对安全的密钥存储位置，但可以做基本的参数签名，防止请求被本地代理工具篡改。常用方案是：把请求参数按 key 排序，拼接appId、timestamp、nonce后做 SHA-256 摘要，签名值放到 header 里。
// 参数签名示例 function buildSign(params, appSecret) { const keys = Object.keys(params).sort() const str = keys.map(k => `${k}=${params[k]}`).join('&') + `&secret=${appSecret}` // 实际项目中 appSecret 不应直接出现在前端代码里，应由后端代理颁发短期凭证 return sha256(str) }注意：appSecret不能硬编码在前端，一旦小程序代码被反编译，secret 就泄露了。正确做法是appSecret由后端下发到客户端，或者下单接口改为「前端生成预下单参数 -> 后端重新签名 -> 调用微信支付」。这套源码里clientInterface.js只负责请求转发，签名逻辑在对接自家后端时，放在服务端校验更稳妥。
常见的错误场景是开发者把时间戳的校验窗口设成了 5 分钟，用户手机时间不准，结果请求被拒。校验收敛到后端时，建议容错 10 分钟，并且忽略nonce在短时间内重复使用。
4. 页面渲染与富文本：showdown.js 在商品详情/营销公告里的落地
4.1 为什么商品详情不用原生 rich-text：Markdown 维护成本更低
电商后台编辑商品详情时，运营同学通常用富文本编辑器，但富文本编辑器导出的 HTML 在小程序rich-text组件里渲染，经常会出现标签不兼容、图片尺寸失控的问题。这套源码里出现的showdown.js说明它走了另一条路：后台存 Markdown，前端用showdown转成 HTML 片段交给rich-text渲染。
这个方案的好处是排版内容天然与代码分离。比如分销规则、售后政策这些长文案，用 Markdown 写完后端保存，前端只负责转换渲染。坏处是showdown转换出的 HTML 里，<script>标签虽然在小程序环境中不会执行，但<img>的onerror事件和href伪协议仍然可能被注入。所以渲染前必须做清洗。
4.2 showdown.js 接入：本地化引入、XSS 过滤与图片延迟加载
showdown.js是独立的前端库，不需要 npm 安装，直接放到utils/目录下用require引入即可。它默认不处理 XSS，所以要在转换后对 HTML 做正则清洗：
// product-detail.js 商品详情页的渲染逻辑 const showdown = require('../../utils/showdown.js') function renderMarkdown(sourceMd) { const converter = new showdown.Converter({ tables: true, // 支持表格 strikethrough: true, // 支持删除线 tasklists: true, // 支持任务列表 simpleLineBreaks: true // 换行转 <br> }) let html = converter.makeHtml(sourceMd) // 过滤 script 标签和 onerror 事件 html = html.replace(/<script[\s\S]*?<\/script>/gi, '') html = html.replace(/\son\w+\s*=\s*"[^"]*"/gi, '') html = html.replace(/javascript:/gi, '') this.setData({ detailHtml: html }) }注意simpleLineBreaks: true这个参数。微信小程序rich-text对<br>的渲染支持不完整，默认情况下连续换行在部分 Android 机型上会被忽略。开启simpleLineBreaks之后，Markdown 里的单个换行也会生成<br>，文案看起来更接近后台编辑效果。
图片尺寸控制也是商品详情页的高频坑。showdown默认输出的<img>不带 width、height 属性，在rich-text里大图直接溢出屏幕。常见做法是正则给<img>补上width:100%的样式：
html = html.replace(/<img /gi, '<img style="width:100%;display:block" ')如果商品详情图片太多，还要考虑懒加载。rich-text组件本身不支持图片懒加载，替代方案是：详情页先渲染前 200 个字符的摘要，滚动到底部时再setData完整 HTML。用户拉到详情底部的行为是明确意图，这时候一次性渲染大图对首屏性能没有影响。
4.3 规格选择与单选框交互：外卖加购页的自定义组件实践
外卖小程序的核心交互是「选规格 -> 加购物车」，这一类 UI 用radio-group+radio是最直接的做法，但原生radio样式在 iOS 和 Android 上渲染差异很大，通常会用cover-view或者自己写一个选择组件。
<!-- spec-popup.wxml 规格弹窗里的单选实现 --> <view class="spec-group" wx:for="{{specList}}" wx:key="id"> <view class="spec-title">{{item.name}}</view> <view class="spec-values"> <view class="spec-item {{selectedSpecId === item.id ? 'active' : ''}}" wx:for="{{item.values}}" wx:key="valueId" bindtap="onSelectSpec" >// 自定义导航栏高度计算 const menu = wx.getMenuButtonBoundingClientRect() const statusBarHeight = wx.getSystemInfoSync().statusBarHeight const navBarHeight = (menu.top - statusBarHeight) * 2 + menu.height这段代码输出的navBarHeight就是自定义导航栏的总高度。常见错误是只算胶囊高度忽略胶囊顶部到状态栏的间距，导致导航栏内容在 Android 上偏上、iOS 上偏下。
5.3 微信支付 v3 对接与本地代理抓包排查下单流程
微信支付 v3 接口相比 v2 最大的变化是要求请求头和应答验签的Wechatpay-Signature，并且证书序列号定期轮换。小程序端对接的完整流程是：后端调微信支付 v3 的下单接口拿到prepay_id，再生成小程序调起支付所需的 5 个参数（timeStamp、nonceStr、package、signType、paySign），最后前端wx.requestPayment发起支付。
调试时最常用的是本地代理抓包。电脑端开一个代理工具，手机微信设置代理指向电脑，就能看到小程序的每个请求和返回。前提是代理工具的 HTTPS 证书要安装到手机上，否则看到的是密文。排查下单失败时，按下面三个顺序看：
| 检查项 | 查看位置 | 常见异常 |
|---|---|---|
| 请求是否发出 | 代理工具里搜索/wxpay | 签名错误导致请求被后端网关拦截 |
| prepay_id 是否生成 | 后端日志或代理响应 | 商户号未开通对应产品权限 |
| wx.requestPayment 回调 | 小程序complete回调的errMsg | cancel属正常，requestPayment:fail是参数错误 |
最后一个建议是：调试微信支付时，把wx.requestPayment的fail回调里err.errMsg完整打印到 console，你会发现requestPayment:fail cancel和requestPayment:fail invalid payment是完全不同的两类问题。前者是用户主动取消，后者是签名错，很多开发者把两种混在一起上报，导致支付成功率分析失真。把这行日志格式化成支付失败: errMsg | 下单时间，线上排障效率能提高一半以上。
本文还有配套的精品资源，点击获取
