简介微信小程序商城前端页面及源代码是一套基于 JavaScript 构建的完整电商示例覆盖首页、分类、产品详情、个人中心、分销、秒杀、购物车、积分、优惠券、订单、余额等模块页面交互与业务流程完整代码均测试运行成功个人毕设答辩平均分达96分适合计算机相关专业学生、教师及初级开发者作为毕设、课设或项目初期演示的参考。资源包为 zip 格式共 479 个文件、约 3.6MB其中 js/wxml/wxss/json 分别承担逻辑、页面结构、样式与配置png/jpg 图片提供页面视觉素材zbak 为备份文件md 文档含 README 说明目录按模块划分便于学习或二次开发时快速定位文件。已有 113 人浏览学习可在此基础上修改扩展新功能例如接入后端接口或增加营销组件需注意资源来源于网络分享仅供学习交流切勿用于商业用途。1. 微信小程序商城前端一次把全部业务模块的事说清楚你接到的需求大概率是某一版“完整版商城”首页、分类、详情、购物车、订单、个人中心一个不少外加分销、秒杀、积分、优惠券、余额这几条线上业务。真正开发时最难的不是某个页面多复杂而是十几个模块共用一套账户体系、价格体系和库存体系接口一多数据流就乱了。做这类小程序前端核心是两件事一是把页面按业务边界拆干净二是把“加购→下单→支付→查单”这条主链路的数据状态管住。本文从项目骨架讲到秒杀扣库存、分销绑定的实现思路全程可以直接复现。适合刚接触小程序商城开发的前端也适合准备接手现成商城项目、需要快速看懂代码布局的工程师。2. 项目骨架与工程化选型先把商城前端的底子立起来2.1 原生小程序、uni-app 还是 Taro商城项目怎么选微信小程序商城前端的实现路线常见有三类微信原生语法、uni-appVue 语法、TaroReact 语法。如果团队只有前端工程师、没有小程序经验用 uni-app 的 Vue 写法上手成本最低HBuilderX 里还能直接编译到微信开发者工具。如果是专门做微信生态、以后要深度使用微信插件和分包能力原生小程序语法更直接因为很多商城功能如客服会话、订阅消息、支付参数官方文档示例默认都拿原生语法写。选型时主要看三点团队技术栈、是否需要多端复用、分包和自定义组件的复杂程度。维度原生小程序uni-appTaro上手成本需熟悉小程序生命周期与语法Vue 技术栈可平迁React 技术栈可平迁多端复用仅微信端App/H5/小程序多端小程序/App/H5 多端生态与组件官方组件最稳定插件市场丰富中大厂使用多难点调试开发者工具直接调注意编译差异注意运行时差异商城项目涉及大量列表页、详情页、表单页页面多、跳转深建议第一版就用原生小程序加官方样式库减少编译层带来的不确定因素。等业务有明确多端需求时再把纯业务逻辑层抽出来单独维护页面层用框架迁移。实际项目里为了赶工期直接上 uni-app 的也很多后面遇到原生组件兼容问题再回头补这是常态。2.2 目录结构按业务模块划分页面注册在 app.json 中显式声明拿到一个完整商城源码包先看目录结构是否按模块组织。我一般把页面按业务域分组而不是按“页面”平铺这样订单、分销、秒杀这类模块扩展时只在对应目录里加页面。├── app.json ├── app.js ├── app.wxss ├── utils/ │ ├── request.js │ └── auth.js ├── components/ │ ├── price-tag/ │ ├── good-card/ │ └── count-stepper/ ├── pages/ │ ├── home/ │ ├── category/ │ ├── goods/ │ ├── cart/ │ ├── order/ │ ├── member/ │ ├── seckill/ │ └── distribution/ └── store/ └── index.jsapp.json 中注册页面路径、tabBar 和 window 配置。首页、分类、购物车、个人中心一般是底部 tab产品详情、订单确认、秒杀列表是普通页面。tabBar 的 iconPath 需要本地静态图片很多源码包这里容易缺文件编译时报错找 image 目录逐个对。window 配置里 navigationBarTitleText、backgroundColor 建议按商城主色统一不然上拉加载时背景色不一致审核界面观感很差。2.3 请求层封装要同时处理登录态、token 刷新与错误提示商城接口鉴权流程基本是用户进入小程序 → wx.login 换取 code → 后端用 code 换 openid 和自定义 token → 前端把 token 存缓存后续请求头带上。请求封装时不要把 wx.request 裸露在每个页面里统一走一个 Promise 方法集中处理 401 跳登录、网络错误提示、加载动画。token 要放在请求头里而不是 URL 参数否则日志和抓包里全暴露了。请求封装是后续秒杀、分销这些模块能稳定联调的基础因为它统一拦截了会话过期、接口降级和重复提交三类问题。// utils/request.js const request (url, method GET, data {}) { const token wx.getStorageSync(token) return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${token} }, success: (res) { if (res.data.code 200) { resolve(res.data.data) } else if (res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/auth/login }) reject(res.data) } else { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }BASE_URL建议放在单独 config 文件中区分开发、测试、生产环境。开发阶段可以直接用开发者工具“不校验合法域名”访问本地接口联调效率高但上线前一定要在公众平台配置 request 合法域名否则真机上一片 request:fail。这类问题排查时要先看开发者工具 Network 面板的状态码再查控制台是否有 url not in domain list 提示。代码里的 code 判断是后端约定的业务码如果不统一要在封装时加一层适配器做映射避免每个页面都去写同样判断。3. 首页、分类、详情页怎么做商城展示层的三个关键页3.1 首页使用自定义导航与骨架屏首屏速度从数据加载开始商城首页承载的内容通常很多轮播图、金刚区、运营位、商品瀑布流。直接在 onLoad 里发五六个请求页面会白屏很久。常见做法是首页接口做聚合。后端如果有专门的首页聚合接口就传一个页面标识返回整块数据如果没有前端用Promise.all并行拉取配合骨架屏占位数据回来后再整体渲染。骨架屏可以用 wx:if 控制一个静态视图也可以使用微信官方 skeleton 组件但注意骨架屏不要比真实接口慢否则反而拖慢首屏。首页上拉加载商品瀑布流要记录分页参数 page 和 hasMore 状态。逻辑上每次触底判断是否在加载中防止重复请求数据回来用concat拼接列表后 setData。如果列表项包含图片建议先缩略图后高清图用 image 组件的 lazy-load 属性懒加载。金刚区入口点击后跳分类、秒杀、分销页时跳转路径统一维护在一个数组里运营配置时不用改代码。商品位点击跳详情要带上商品 id这个 id 后面在详情页所有接口都会用到前端要校验空值否则详情页反复报错。3.2 分类页用 scroll-view 做左右联动联动本质是索引对齐分类页经典布局是左边一级分类、右边商品列表或二级分类。实现时左右两个 scroll-view左边点击设置当前分类索引右边 scrollTop 归零并加载该分类内容。右边滚动时根据当前 scrollTop 判断应该高亮哪个一级分类这里比较的是位置区间而不是简单相等避免最后一项因为内容不够长而永远触发不了高亮。分类数据一般两级接口返回嵌套结构前端需要拍平后重新组装。// 分类联动核心逻辑 const categoryList this.data.categoryList const scrollTop e.detail.scrollTop let currentIndex 0 for (let i 0; i categoryList.length; i) { if (scrollTop categoryList[i].offsetTop) { currentIndex i } } if (currentIndex ! this.data.activeIndex) { this.setData({ activeIndex: currentIndex }) }这段代码里offsetTop是右边列表每一项的累积高度需要在数据渲染后通过wx.createSelectorQuery()计算。注意时机要在 setData 回调里取不能在数据刚 set 完马上查询否则拿到的还是旧布局高度。右侧列表回滚时左边如果设置了 scroll-into-view要用 id 指定项锚定两个 scroll-view 的高度都必须显式设置默认高度为 0 时内容不显示这是新手常见问题。3.3 详情页要拆成小组件价格、SKU 弹层、商品图集独立维护商品详情页数据量大、交互多不要在单个 wxml 里写超长模板。图集、价格区、SKU 选择弹层、商品参数、用户评价拆成独立组件数据通过 properties 传入。SKU 选择是详情页最复杂的交互规格组合可能很多后端返回的 skuList 里每项包含规格值 id 组合与价格库存前端要做的是根据用户已选规格过滤可选项。实现思路是维护一个 selected 对象每选一个规格值遍历 skuList 找出匹配项。若某个规格值与其他已选规格无匹配库存则置灰禁用。库存数在 SKU 弹层里要用 stepper 控制购买数量控制器上限取库存和单次限购数较小值。详情页加购接口和立即购买逻辑是两个不同入口区别在于下单参数来源。加购只传商品 id 与 sku id、数量立即购买要带 sku 信息跳确认订单页。跳转时微信小程序 URL 长度有限制复杂对象用wx.setStorageSync存一个临时 key 传给下页不要在 URL 上拼一长串 JSON。支付按钮要防连点用this.locked true加锁提交成功后再释放否则用户连点会生成多个重复订单。详情页分享给好友时onShareAppMessage 里的 path 必须带商品 id保证别人打开能看到对应商品。4. 购物车、订单、优惠券、积分与余额商城交易主链路状态管理4.1 购物车选中态要存到 storage勾选和结算实时联动购物车页面是列表加底部结算栏。每件商品有勾选状态全选、单选、删除、数量变更都要即时汇总已选数量与合计金额。常见错误是只把购物车数据存在 data 里页面返回后再进来数据就丢了。正确做法是购物车列表同步写入wx.setStorageSync每次 setData 后立即持久化。合计金额的计算建议抽成纯函数输入购物车列表输出选中的 sku 项和总价这样任何一个状态变更后调用一次即可。// 购物车选中汇总逻辑 function calcChecked(cartList) { const selectedItems cartList.filter(item item.checked) const totalPrice selectedItems.reduce((sum, item) { return sum item.price * item.count }, 0) const totalCount selectedItems.reduce((sum, item) sum item.count, 0) return { selectedItems, totalPrice, totalCount } }单价参与计算前要确认后端返回的是整数分还是带小数点的元。如果是分前端展示要除以 100结算金额直接传分给后端避免浮点数相加出现精度误差。购物车删除接口一般要求传多个购物车 id批量删除比逐个删除减少请求次数。购物车选中状态变更可以只更新本地不做接口同步但结算时必须把选中的 sku id 列表提交到订单接口以后端计算结果为准前端总额只做展示。4.2 订单列表按状态 tab 切换订单详情有独立的轮询刷新策略订单模块通常有“全部、待付款、待发货、待收货、待评价”几个 tab。页面结构是一个 scroll-view 下多个 list切换 tab 时清空列表重新拉数据不要把所有状态都加载完再隐藏那样首屏性能差。订单列表项本身可以复用组件不同订单状态下的操作按钮不同用条件渲染控制文字和点击事件。订单取消、确认收货这类操作在成功后需要刷新当前列表注意刷新后保留滚动位置否则用户一操作就回到顶部体验很差。订单支付成功后的状态同步常见现象是用户在支付收银台点完成返回订单列表还是待付款。处理方法是订单详情页在 onShow 里主动重新拉一次订单详情同时根据支付结果调整本地展示状态。如果订单有物流信息可以在详情页埋点轮询但轮询间隔不要低于 15 秒页面隐藏时清除定时器否则后台持续耗电。订单详情接口返回的数据层级深wxml 引用时注意可能有空值字段比如物流为空时order.logistics.company会报错模板里用wx:if逐层判断即可。跳转订单详情时先在列表页存一份简要订单数据到缓存做兜底展示再异步拉详情覆盖弱网环境下体验更稳。4.3 优惠券计算放前端展示、后端结算状态机字段要分清优惠券模块分两块领券中心和我的优惠券。领券接口提交 couponId返回成功后在本地把该券状态置为已领取防止重复点击。我的优惠券列表要区分未使用、已使用、已过期三个状态前端根据 finishTime、usedTime 字段实时计算展示不依赖后端定时刷状态。结算页选择优惠券时前端做满减判断订单金额是否满足 threshold 门槛不满足的券置灰。真实抵扣金额在提交订单时由后端计算前端传 couponId 即可不要自己算完传给后端。优惠券状态机建议用整数值字段0 未使用、1 已使用、2 已过期、3 已锁定。锁定状态最常见于订单提交但未支付此时优惠券暂时不可用订单取消后回滚为未使用。如果发现用户提交订单时用了券、取消后券没回来大概率是后端状态回滚没做前端可以做一次兜底订单取消成功后主动调一次优惠券列表接口刷新本地数据。使用范围判断上全品类券和指定品类券的判断逻辑不同指定品类券要在 SKU 详情页也显示“可用”或“不可用”的提示这需要前端注意优惠券适用范围接口在商品详情上的返回字段。4.4 积分与余额作为虚拟资产页面只展示、变更靠明细个人中心里的积分和余额模块本质是资产账户核心不是金额展示而是明细列表与支付方式组合。积分明细列表按时间倒序数据量大时分页加载余额明细同理。前端要区分“变更中”和“已完成”的流水状态因为支付回调延时会导致明细短暂显示为处理中。提现功能如果用余额提现需要后端校验实名信息和提现密码前端在提交后要进入处理中状态不能立即显示成功。积分和余额在支付时可以组合使用比如“积分 微信支付”混合支付提交订单接口要传两个支付参数。// 提交订单支付参数示例 const orderData { orderId, paymentType: MIX, balanceAmount: Math.min(userBalance, orderTotalPrice), integrateAmount: useIntegral ? integralToMoney(integralCount) : 0, couponId }paymentType字段值要与后端约定常见有 BALANCE、WECHAT、MIX 三种。前端要实时校验余额和积分可抵扣金额不能超过订单总额超过时自动修正。这类校验逻辑放前端只是体验优化后端必须做同样的强校验因为小程序前端的数据可以被修改或者绕过。实际联调时如果遇到“余额扣了但订单未锁定”的情况多半是后端先扣款后创建订单正确时序是先冻结余额再创建订单前端对此无能为力只负责把参数按约定传全。5. 秒杀与分销模块商城业务里最敏感的两个功能区域5.1 秒杀列表与倒计时组件时间同步不能依赖本地时区秒杀模块前端除了常规列表渲染核心问题有两个倒计时准确性和库存显示实时性。倒计时不要用本地时间计算要以后端返回的服务器时间为基准否则用户手机时间不准会看到倒计时为负。实现方式是进入页面时拉一个 serverTime 和 endTime计算出 timeDiff serverTime - Date.now()之后每秒刷新时用endTime - (Date.now() timeDiff)来得到剩余秒数。倒计时组件建议做成独立组件多个商品同时倒计时时只跑一个定时器通过 data 里的列表项时间字段批量更新。秒杀页库存显示变化快每次倒计时跳秒时如果频繁拉详情会造成请求风暴。这里常见做法是秒杀列表只显示“是否已抢光”的状态由后端在下单接口里做实际校验。前端按钮状态根据stock 0控制可点击提交订单返回库存不足时再置灰。秒杀提交订单时要拿秒杀活动 id 和商品 id 一起提交后端校验参与资格。前端在秒杀详情页的固定时间点要自动抢跑提示但不要做真实请求预发避免被判定为脚本操作。开发时做秒杀接口压测要看接口响应时间和库存扣减是否一致。前端能做的优化只有减少请求体积和降低渲染开销真正的热点抗压在后端。5.2 分销绑定关系通过场景值传递页面加载时解析一次即可分销模块的入口一般是个人中心或邀请海报生成的带参二维码。用户扫码打开小程序进入分销申请页时需要通过“分享者身份”记录绑定关系。微信小程序中二维码传参格式是sceneinviteCode_123456前端在onLoad中通过options.scene获取并decodeURIComponent解码。把 inviteCode 传给后端绑定接口完成关系绑定后再 join 到主页。绑定接口要注意幂等防止同一用户重复提交生成多条邀请关系后端要按被邀请人 id 做唯一索引前端负责防止连点。Page({ onLoad(options) { if (options.scene) { const scene decodeURIComponent(options.scene) const inviteCode scene.split(_)[1] this.bindDistributor(inviteCode) } } })分销关系绑定在 onLoad 中做一次即可不要在 onShow 中重复调用否则用户每次切后台回来都会触发绑定接口。如果项目里分销层级有两级还要把二级分佣关系在前端展示出来佣金明细列表按“一级佣金、二级佣金”分类展示涉及金额的地方统一处理后端返回的分单位数字。分销中心页面通常有推广海报、专属二维码和佣金提现三个入口海报生成可以把商品图、头像和邀请码拼到 canvas 上注意 canvas 绘制用的是像素坐标需根据机型做适配一般用wx.getSystemInfo获取屏幕宽度按比例缩放。分销模块涉及“团队人数”“累计收益”这类汇总数据接口返回的可能是全量快照前端直接展示即可。5.3 秒杀与分销共用的防并发按钮处理统一封装按钮锁秒杀下单和分销绑定这类只有一个最终结果的请求都要做前端按钮锁。商城项目里因为连点导致重复提交的 bug 特别多统一封装一个 util 方法可以避免每个页面重复写锁逻辑。按钮锁的作用域要按操作维度区分同一个用户可以同时操作不同商品锁的粒度应该是“商品 id 操作类型”而不是一个全局变量。页面级的 locked 变量只能挡住同期同页面的重复点击跨页跳转后锁就失效了。function preventDuplicate(key, timeout 2000) { const storageKey submit_lock_${key} const now Date.now() const lock wx.getStorageSync(storageKey) if (lock now - lock timeout) { return false } wx.setStorageSync(storageKey, now) return true }上述代码将锁存到 storage 而不是内存变量跳转页面后依然有效。提交成功后主动清除锁请求失败或超时也建议清理避免用户一直被锁住。秒杀倒计时结束后一般会锁住按钮但注意“结束”与“库存为 0”是两个不同状态提示文案不要混用。实际项目里团队多人协作时这些工具函数要集中放在 utils 目录并写注释否则其他人临时改需求时会在页面里堆一堆私有锁逻辑后面查问题就很麻烦。6. 性能优化与上线前排查把商城前端调到可交付状态6.1 分包加载是首次打开速度的关键非核心页面全部移入分包微信小程序主包体积超过 2MB 后无法上传商城项目商品详情、订单、分销、秒杀这些页面都比较重建议全部拆入分包。分包目录下的页面执行流程不变但 tabBar 页面必须在主包不能放分包。配置示例在 app.json 中加入 subpackages 字段每个分包指定 root 和独立目录。{ subpackages: [ { root: pages/order, pages: [ pages/order/list, pages/order/detail ] }, { root: pages/distribution, pages: [ pages/distribution/center, pages/distribution/withdraw ] } ], preloadRule: { pages/home/index: { network: all, packages: [pages/order] } } }preloadRule 可在进入首页后静默预下载订单分包用户点击进入订单列表时秒开。分包内页面互相跳转时路径要带分包前缀否则会找不到页面。分包的静态资源也要放进各自分包目录不要全部塞在主包 asset 里否则主包体积依然膨胀。检查主包体积可以在开发者工具详情面板里看超过 1.5MB 时就要考虑拆包或压缩图片。6.2 setData 频繁调用是性能杀手高频场景用字段路径更新小程序 setData 每次调用都会做 diff 并传给渲染层频繁且数据量大的 setData 会直接导致页面卡顿商城首页和列表页最容易出现。真正的高频操作场景是倒计时、购物车数量步进、SKU 弹层切换。这三种场景要尽量缩小 setData 的更新范围用字段路径比传整个对象高效得多。比如只更新某个商品的库存显示不要 setData 整个列表。// 推荐按字段路径更新 this.setData({ [goodsList[${index}].stock]: newStock })大规模列表更新时要合并数据不要在循环里逐条 setData。列表数据超过 50 条时考虑截断渲染或使用 recycle-view 虚拟列表组件商品瀑布流能用就不要一次性渲染全部图片。开发者工具性能面板里可以看到 setData 的调用时间和数据量优化前后对比很明显。如果发现页面滚动掉帧优先检查是否有页面级 setData 在 scroll 事件里被频繁触发。6.3 真机调试与抓包验证页面验证和接口验证要同时通过开发完成不是手机上看一眼没问题就算结束。建议至少做四类验证功能遍历、弱网场景、支付回调、分享路径。微信开发者工具中模拟器和真机环境差异很大顶部导航栏高度在不同机型上不同涉及自定义导航的页面要用wx.getMenuButtonBoundingClientRect()获取胶囊按钮位置做适配不能写死高度。接口排查用 Charles 或 whistle 这类工具看请求和返回重点看 https 请求是否正常、响应时间是否过长、是否出现域名校验错误。开发者工具中的“真机调试”模式可以直接看真机 console 日志比扫码预览更能拿到有效报错。上线前在公众平台的开发管理里要核对 request 合法域名和业务域名。request 域名不加个数限制前缀也能跑但必须是 https。图片若走 CDNdownloadFile 合法域名也需要配置。支付功能还要在小程序后台配置微信支付商户号并关联 AppID一旦漏配真机支付会直接报错“支付签名验证失败”。最后用体验版账号完整走一遍“加购→下单→支付→订单可见”的主链路确认分销绑定和秒杀活动在真机上正常结束后再提审。本文还有配套的精品资源点击获取