简介这份源码资源面向具备微信小程序开发基础的开发者提供一套可直接运行的购物车功能实现适用于电商平台或任何需要在线购物模块的小程序项目。包内共24个文件以JavaScript逻辑脚本、WXML页面结构、WXSS样式表和JSON配置文件为主另含少量图片素材与说明文档压缩包约1.03MB结构清晰、便于按模块查阅。核心功能覆盖商品添加、列表管理、数量调整、单项删除与总价自动计算并支持将购物车数据持久化到本地存储用户再次访问时可恢复此前状态界面设计直观交互路径简洁。源码分层合理组件与页面职责分明方便在此基础上扩展优惠券、规格选择或结算流程等定制需求。目前已有211人学习下载适合希望快速搭建购物车原型、理解小程序数据绑定与本地缓存机制的开发者参考借鉴。1. 购物车不是加加减减小程序里最容易被低估的状态同步模块很多人第一次接手「微信小程序 - 购物车功能源码」这类需求时第一反应是「不就是加加减减吗」结果真上手才发现购物车是整个小程序里状态最碎、边界最多、最容易在真机上翻车的模块。它同时牵扯本地缓存、页面栈通信、服务端价格校验、库存扣减时机、优惠券叠加顺序任何一环没对齐用户看到的就是「数量对了金额不对」「删了又回来」「结算时价格突变」。这篇笔记面向两类人一类是刚拿到一份购物车源码、想把它跑通并改成自己业务形态的开发者另一类是自己从零写购物车、写到一半发现状态到处飞、想找一套可落地结构的熟手。我会按「数据模型怎么定 → 本地缓存怎么存 → 页面怎么联动 → 服务端怎么校验 → 坑在哪」的顺序讲代码可以直接抄参数可以按你的业务改。核心结论先放这购物车真正的难点不在 UI而在「同一份数据在本地、页面、服务端三处保持一致」源码值不值得用就看它有没有把这层同步讲清楚。2. 先把数据模型定死购物车条目的 7 个字段与 3 种状态2.1 为什么字段设计决定了后面所有逻辑我见过不少购物车源码条目对象里只有id、name、price、count四个字段跑 demo 没问题一接真实业务就崩。原因很简单购物车条目不是商品它是「用户在某次会话里对某个 SKU 的购买意图」这个意图会随库存、规格、促销变化。字段少一个后面就要用各种if去补补到最后没人敢改。我一般会把条目固定成 7 个字段多一个都嫌重少一个都会疼字段类型作用易错点skuIdString唯一标识不是商品 id同商品不同规格必须不同spuIdString商品聚合用用于分组、凑单titleString展示名不要存富文本priceNumber下单时单价分必须用整数分别用浮点countNumber购买数量受库存和限购约束selectedBoolean是否勾选结算全选逻辑的根checkedAtNumber勾选时间戳用于排序和失效判断价格用「分」存整数是血泪经验。0.1 0.2 ! 0.3这种玄学在金额上就是事故源码里只要出现parseFloat直接算钱基本可以判定它没上过生产。2.2 三种状态有效、失效、缺货条目不是只有「在」和「不在」。真实场景至少三种状态有效可结算、已下架失效、库存不足。很多源码把失效条目直接删掉用户下次想找回都找不到体验很差。我的做法是保留条目用状态字段标记UI 上灰显并禁止勾选。// cart-item.js —— 购物车条目工厂统一入口避免各处手写对象 const ITEM_STATUS { VALID: valid, // 正常可结算 INVALID: invalid, // 已下架 OUT_OF_STOCK: oos // 库存不足 }; function createCartItem(sku) { return { skuId: sku.skuId, spuId: sku.spuId, title: sku.title, price: sku.price, // 单位分整数 count: 1, selected: true, checkedAt: Date.now(), status: ITEM_STATUS.VALID, stock: sku.stock // 本地冗余库存仅用于即时校验 }; } module.exports { createCartItem, ITEM_STATUS };逻辑说明工厂函数保证每个条目结构一致status和stock是本地冗余真正下单前必须回源校验。参数上price强制整数分count初始为 1selected默认 true 是因为用户加购通常就是想买。stock只用于本地即时提示不能作为下单依据这点后面第 5 章会展开。2.3 全选与反选一个容易被写错的派生状态selected是条目级状态全选是派生状态不该单独存。很多源码存了一个allSelected布尔值结果用户手动取消一个全选状态就错乱。正确做法是每次渲染时用items.every(i i.selected)现算。// 派生全选状态不落库、不缓存 function isAllSelected(items) { const valid items.filter(i i.status ITEM_STATUS.VALID); return valid.length 0 valid.every(i i.selected); }注意这里过滤了失效条目失效条目不该参与全选判断否则用户永远点不亮全选。这个细节在多数源码里是缺失的也是「全选按钮点了没反应」的常见根因。3. 本地缓存与页面联动让购物车在切页后不丢、不乱、不重复3.1 缓存键设计与读写封装小程序没有全局内存页面切换后data会重建购物车必须落wx.setStorageSync。但直接裸调缓存 API 是灾难因为多个页面同时读写会互相覆盖。我一般封装一层带版本号的存储// cart-store.js —— 购物车本地存储封装 const CART_KEY cart_v1; // 带版本号结构变更时直接换 key const MAX_ITEMS 100; // 防止缓存无限膨胀 function loadCart() { try { const raw wx.getStorageSync(CART_KEY); if (!raw || !Array.isArray(raw.items)) return { items: [] }; return raw; } catch (e) { // 缓存损坏时兜底避免整个购物车白屏 return { items: [] }; } } function saveCart(cart) { if (cart.items.length MAX_ITEMS) { cart.items cart.items.slice(0, MAX_ITEMS); } wx.setStorageSync(CART_KEY, cart); } module.exports { loadCart, saveCart, CART_KEY };逻辑说明CART_KEY带v1后缀将来字段结构变了直接升v2老数据自然失效不用写迁移脚本。try/catch是必须的缓存被外部写坏时不能让购物车页直接崩。MAX_ITEMS是防御性上限正常业务不会到 100但恶意或异常写入会撑爆缓存。3.2 页面间同步事件总线还是全局 store购物车数据会在商品详情页、购物车页、结算页三处被改。常见做法有两种一是用getApp().globalData加回调二是自己写一个极简事件总线。我倾向后者因为globalData没有变更通知页面onShow里手动刷新容易漏。// event-bus.js —— 极简发布订阅够用就好 const listeners {}; function on(event, fn) { (listeners[event] || (listeners[event] [])).push(fn); } function off(event, fn) { const arr listeners[event] || []; const idx arr.indexOf(fn); if (idx -1) arr.splice(idx, 1); } function emit(event, payload) { (listeners[event] || []).forEach(fn fn(payload)); } module.exports { on, off, emit };逻辑说明on注册、off注销、emit广播三个函数覆盖 90% 场景。关键约定是任何写购物车的地方写完必须emit(cart:change)购物车页在onLoad里on、onUnload里off避免内存泄漏。参数payload传最新 cart 对象订阅方直接渲染不用再读一次缓存。3.3 数量增减的边界库存、限购、最小值数量加减看着简单边界一堆不能小于 1、不能超过库存、不能超过限购数、失效条目不能改。我一般把校验收在一个函数里// 返回 { ok, count, reason } function clampCount(item, next, limitPerOrder 99) { if (item.status ! valid) { return { ok: false, count: item.count, reason: invalid }; } const max Math.min(item.stock, limitPerOrder); if (next 1) return { ok: false, count: 1, reason: min }; if (next max) return { ok: false, count: max, reason: max }; return { ok: true, count: next, reason: }; }逻辑说明limitPerOrder是业务限购默认 99实际按活动改。返回结构带reasonUI 层可以直接弹对应提示不用再判断。注意max取库存和限购的较小值两个约束同时生效这是很多源码只判库存漏掉限购的地方。4. 服务端校验与结算本地数据永远不可信4.1 为什么下单前必须回源本地购物车只是「用户意图的快照」价格、库存、促销随时会变。如果直接拿本地price去下单用户改个缓存就能一块钱买手机。常见做法是结算页进入时调一次「购物车校验接口」把skuId count列表发上去服务端返回最新价格、库存、可用优惠前端用返回值覆盖本地展示。// 结算前校验只传 skuId 和 count不传价格 async function validateCart(items) { const payload items .filter(i i.selected i.status valid) .map(i ({ skuId: i.skuId, count: i.count })); const res await wx.request({ url: /api/cart/validate, method: POST, data: { items: payload } }); return res.data; // { items: [{skuId, price, stock, status}], total } }逻辑说明请求体只带skuId和count价格由服务端算这是安全底线。返回的items用来覆盖本地条目的price、stock、statustotal用于展示。参数上不要传selected服务端不关心勾选勾选是前端结算范围的事。4.2 金额计算前端只做展示服务端才是准前端算总价只用于即时反馈最终以服务端为准。前端算的时候也要用整数分避免浮点误差// 前端预估总价仅展示 function calcTotal(items) { return items .filter(i i.selected i.status valid) .reduce((sum, i) sum i.price * i.count, 0); // 单位分 }逻辑说明reduce累加整数分最后展示时再除以 100 并toFixed(2)。注意过滤条件同时判selected和status失效条目即使被勾选也不计入。这个函数的结果和服务端返回的total不一致时以服务端为准并提示用户「价格已更新」。4.3 结算范围与优惠券叠加顺序优惠券、满减、会员价叠加顺序会直接影响最终金额前端不该自己算。常见做法是服务端返回一个「优惠明细数组」前端只负责按顺序展示。顺序一般是商品级促销 → 订单级满减 → 优惠券 → 会员折扣具体以业务为准。前端要做的只是把selected的条目传上去别自作主张先算一遍再传否则两边对不上排查起来就是黑匣子。5. 避坑与排查购物车源码里最常见的 5 个翻车现场5.1 现象删了条目切页回来又出现原因删除只改了页面data没写回缓存或者写了缓存但没emit通知其他页面用旧数据覆盖了。解决所有写操作走统一saveCartemit(cart:change)删除后立即落库别等onUnload。5.2 现象全选按钮点了没反应原因全选状态被单独存成布尔值和条目selected不同步或者失效条目参与了every判断。解决全选用isAllSelected现算过滤失效条目点击全选时只改有效条目的selected。5.3 现象金额偶尔差一分钱原因用了浮点数算钱或者前端算完直接下单。解决全程整数分前端只展示下单金额以服务端返回为准。这个坑最隐蔽测试时不一定复现上线后对账才发现。5.4 现象数量能加到 999库存明明只有 5原因本地没做库存校验或者stock字段没从服务端同步。解决clampCount里取Math.min(stock, limitPerOrder)结算前再回源校验一次双重保险。5.5 现象缓存写满后购物车白屏原因缓存无上限异常写入撑爆Storage读取时抛异常没兜底。解决saveCart里截断到MAX_ITEMSloadCart里try/catch返回空购物车保证页面能渲染。6. 进阶把购物车源码改成可复用模块的两个技巧第一个技巧是「把购物车逻辑抽成不依赖页面的纯函数模块」。上面所有cart-item、cart-store、clampCount、calcTotal都不碰this.setData只操作数据。页面层只做两件事调模块拿数据、setData渲染。这样同一套逻辑能同时用在购物车页、结算页、甚至未来的「立即购买」流程改一处全生效。我一般会建一个cart/目录index.js统一导出页面只require这一个入口。第二个技巧是「给缓存加一个轻量版本迁移」。CART_KEY带v1只是粗暴失效用户升级后购物车清空体验不好。更好的做法是读老 key字段映射后写新 key再删老 key// migrate.js —— 结构变更时的迁移示例 function migrate() { const old wx.getStorageSync(cart_v0); if (!old || !old.items) return; const items old.items.map(i ({ skuId: i.skuId, spuId: i.spuId || i.skuId, title: i.name || , price: Math.round((i.price || 0) * 100), // 元转分 count: i.count || 1, selected: true, checkedAt: Date.now(), status: valid, stock: 0 })); wx.setStorageSync(cart_v1, { items }); wx.removeStorageSync(cart_v0); }逻辑说明迁移只在启动时跑一次Math.round把老数据里的元转成分spuId缺失时用skuId兜底stock置 0 表示待服务端刷新。跑完删老 key避免重复迁移。这个技巧在源码迭代时特别有用能省掉一次「用户购物车被清空」的投诉。验证方法上我习惯用小程序开发者工具的「Storage」面板手动改数据模拟缓存损坏、字段缺失、超量写入三种情况看页面是否还能正常渲染。能扛住这三种基本就能上线。最后说个我自己的习惯每次改购物车逻辑先在纸上把「谁写、谁读、谁通知」画一遍三方对不上就别写代码。这个习惯帮我省了至少三次通宵排查。希望帮到你。本文还有配套的精品资源点击获取