1. 购物车模块为什么值得单独拆出来写做小程序电商的人都知道购物车是整个交易链路里最琐碎、又最容易写出 bug 的模块之一。它不像商品详情页那样只要展示信息也不像下单页那样流程固定购物车要同时处理选中状态、数量变化、价格计算、地址联动任何一个环节没想清楚后面都会牵连出一堆问题。我这篇文章要聊的内容正好就是标题里这几个功能点全选与反选、修改商品数量、删除商品、计算总价格和总数量、收货地址。这几个功能看起来各自独立实际上是一条完整的交互链路——用户勾选商品 - 调整数量 - 看总价 - 确认收货地址 - 去结算整条链路的数据流转是共享的。所以我把它们拆成一篇文章从头到尾捋一遍。文章适合两类人看一类是刚接触小程序开发、正准备上手写购物车的初学者另一类是已经写过购物车但总觉得代码绕来绕去、想看看别人怎么组织数据的开发者。我会从数据模型讲起把每个交互背后的状态管理逻辑说清楚最后再分享一些真实项目里踩过的坑。2. 先把数据结构想明白后面能少改一半代码购物车功能能不能写得顺第一个决定因素不是页面长什么样而是数据怎么组织。我在早期开发时犯过一个典型的错误把购物车数据直接塞在页面 data 里页面里到处是cartList[0].checked true这种硬编码索引的操作。结果需求一调整改一个字段连带三四段逻辑一起崩。后来我总结出一个原则购物车的数据结构要能独立表达一个商品的所有购物车状态并且状态之间的变更尽量收敛到几个固定方法里。2.1 商品条目最少需要哪些字段以我目前常用的结构为例购物车里每一个商品条目至少需要这些字段{ id: sku_001, // 商品规格ID不是商品ID一个商品可能有多个规格 name: 无线蓝牙耳机, // 用于展示 price: 129.00, // 单价注意用数字类型别用字符串 count: 2, // 当前购物车数量 checked: true, // 是否被选中默认 false stock: 50, // 库存用来限制最大购买数量 image: /images/xxx.png, // 缩略图 specText: 白色 / 标准版 // 规格描述比如颜色、尺寸 }这里有两个容易被忽略的点。第一id一定要用规格ID而不是商品ID。同一件商品如果有黑白两个颜色在购物车里就是两个独立条目它们有着不同的 sku 标识。如果用商品ID做唯一标识选颜色就会完全混乱。第二price用数字类型。很多从后端拿到价格可能是字符串直接拿来算总价会出现129 2变成1292这种令人抓狂的问题。建议在数据进入购物车前统一用Number()转换一次。2.2 页面层购物车数据的整体形态购物车页面的 data 里通常需要维护三个核心字段商品列表、全选状态、以及计算后的总数量和总价格。data: { cartList: [], // 商品条目数组 allChecked: false, // 全选按钮的状态 totalCount: 0, // 选中的商品总数量 totalPrice: 0.00 // 选中的商品总价格 }我见过不少新手把总价、总数也当作独立变量去手动赋值比如每次点击加号就this.setData({ totalPrice: this.data.totalPrice price })。这种方式在单个操作下没问题一旦出现同时取消多个商品批量删除这类操作手动累加的误差就很容易冒出来。后面我会讲一种更稳的方式——计算函数集中重算。3. 全选与反选checkbox 联动背后的状态同步全选与反选是购物车交互里最表面、但坑最多的地方。先说概念再讲实现。这里我先明确一下反选在我的语境里的含义它对应的是全选按钮被再次点击时的动作。当所有商品都被选中时用户再次点击全选按钮应该让所有商品变成未选中状态——也就是一个全不选的切换。有的需求会把反选理解为选中状态翻转选中的变未选中未选中的变选中但购物车场景下这种需求极少大部分产品设计的都是前者。我下面的实现按这个来。3.1 单商品的选中切换单个商品的选中状态通过商品行内的 checkbox 来切换。这是最底层的事件其他所有状态全选、总计都要由它触发重新计算。view classcart-item wx:for{{cartList}} wx:keyid checkbox checked{{item.checked}} >onItemCheck(e) { const index e.currentTarget.dataset.index; const cartList this.data.cartList; cartList[index].checked e.detail.value; this.setData({ cartList: cartList }); // 重新计算全选状态和总计 this.updateAllChecked(); this.calcTotal(); }这里有一个非常关键的细节修改数组里的某个元素不能用this.data.cartList[index].checked ...之后直接 setData 整个数组吗可以但我不推荐直接改this.data。小程序里setData的性能和可维护性都跟数据操作方式有关更稳妥的做法是先用wx:key让列表有稳定的 diff 基础然后单独更新被修改的那一项onItemCheck(e) { const index e.currentTarget.dataset.index; const checked e.detail.value; this.setData({ [cartList[${index}].checked]: checked }); this.updateAllChecked(); this.calcTotal(); }使用cartList[index].checked这种路径式写法只更新一个字段避免整个列表重新渲染性能更好代码意图也更清晰。3.2 全选按钮的状态计算不是点击出来的是推导出来的很多新手的第一反应是全选按钮就是点击之后遍历列表把所有项设置为 true 或 false。这个方向没错但隐藏着一个容易漏掉的问题——当用户手动取消了某个商品时全选按钮必须自动变为未选中状态而不是停留在之前的选中态。所以全选按钮的状态不应该只在点击全选时维护而应该在每次商品选中状态变化时重新推导。updateAllChecked() { const cartList this.data.cartList; // 空列表时全选应为 false if (cartList.length 0) { this.setData({ allChecked: false }); return; } // 所有商品都被选中全选才为 true const allChecked cartList.every(item item.checked); this.setData({ allChecked: allChecked }); }Array.prototype.every在这里非常好用只要有一个商品未选中结果就是 false不需要自己写循环去数。3.3 全选/反选的切换事件全选按钮的事件逻辑是onToggleAll() { const newChecked !this.data.allChecked; const cartList this.data.cartList; // 遍历所有商品批量设置选中状态 const newList cartList.map(item { return { ...item, checked: newChecked }; }); this.setData({ cartList: newList, allChecked: newChecked }); this.calcTotal(); }注意虽然allChecked已经在点击时直接设置了我依然建议用updateAllChecked()推导一遍这样可以保证数据和状态的逻辑永远只有一条来源不容易出现看起来状态对了但数据里 checked 字段是错的这种隐性 bug。你说多调用一次是不是浪费在小程序这种体量的列表渲染下这点开销可以忽略换来的是维护成本下降。4. 商品数量修改与删除边界条件和交互反馈同样重要数量修改和删除表面是做加减法和移除数组元素实际要处理的细节很多——边界值、库存限制、空列表状态、二次确认每一项都是用户体验的关键。4.1 步进器的加减逻辑数量控制的经典作法是商品行内的加减按钮中间显示数量。我用一个统一的changeCount方法处理加和减changeCount(e) { const { index, type } e.currentTarget.dataset; const cartList this.data.cartList; const item cartList[index]; let newCount item.count; if (type minus) { if (item.count 1) { // 数量到达下限给出提示或者引导删除 wx.showToast({ title: 最少购买1件, icon: none }); return; } newCount item.count - 1; } else if (type plus) { if (item.count item.stock) { wx.showToast({ title: 已达库存上限, icon: none }); return; } newCount item.count 1; } this.setData({ [cartList[${index}].count]: newCount }); this.calcTotal(); }这里有三个容易被忽视的细节下限不一定是 1。有些商品设置了最少起购量比如批发类的商品最少买 5 件。设计数据模型时最好预留一个minBuy字段不要写死。上限是库存 stock但实际场景中还要考虑限购数量。有些活动商品单人限购 2 件这时上限应该是Math.min(stock, limit)而不是只看库存。超出边界时不要直接 return 不响应。一个简单的 toast 提示能避免用户反复点按钮却没有任何反馈觉得自己买到假按钮了。另外有些项目会提供输入框让用户直接修改数量这个场景下还要额外校验输入值是不是整数、是否在合法区间处理方式类似只是来源从按钮变成了输入事件。4.2 删除商品确认弹窗与数据清理删除操作在移动端几乎都要做二次确认防止误触。小程序的wx.showModal是标准方案removeItem(e) { const index e.currentTarget.dataset.index; const item this.data.cartList[index]; wx.showModal({ title: 提示, content: 确定要删除「${item.name}」吗, success: (res) { if (res.confirm) { const cartList this.data.cartList; cartList.splice(index, 1); this.setData({ cartList: cartList }); this.updateAllChecked(); this.calcTotal(); } } }); }删除之后有两件事必须立刻做更新全选状态可能你删掉了最后一个未选中的商品或者删到列表为空以及重新计算总价和总数量。还有一个经常被忽略的场景——批量删除。购物车右上角一般会有管理/完成切换进入管理状态后可以多选商品批量删除。这种模式下的实现并不复杂批量删除其实就是把所有 checked 为 true 的条目从数组里过滤掉。removeBatch() { const cartList this.data.cartList; const remainList cartList.filter(item !item.checked); this.setData({ cartList: remainList }); this.updateAllChecked(); this.calcTotal(); }注意这个方案对全选删除也成立——把全部商品删掉后cartList变为空数组updateAllChecked会把全选按钮置灰总价归零页面显示空状态。边界情况要专门测试一下。4.3 删除到空列表之后空态提示购物车清空后页面底部不应该还显示着一个大大的结算按钮和 0.00 的总价。通常的做法是cartList为空时展示一个空态区域提示用户去逛逛同时隐藏底部操作栏。这个逻辑不复杂核心是在 data 里加一个布尔值在每次增删后同步更新data: { // 新增一个字段 isEmpty: true } updateEmptyState() { this.setData({ isEmpty: this.data.cartList.length 0 }); }WXML 里用wx:if控制空态和列表的切换底部操作栏也用wx:if{{!isEmpty}}控制显示。空态页面建议加一个去逛逛按钮直接跳转到商品列表页这样用户清空购物车之后不会卡在页面上不知道去哪。5. 总价格和总数量的计算把所有状态收敛到一个方法里这是整篇文章里逻辑最核心的部分。标题里写了计算总价格和总数量这个功能我把它单独拿出来是因为很多 bug 都是在这里产生的。5.1 为什么不能每操作一次就手动加减总价我先解释一下前面提到的计算函数集中重算为什么不手写累加。假设商品 A 价格 100 选 2 件商品 B 价格 50 选 3 件。总价是 350。用户把商品 A 取消选中这时总价应该变成 150但如果你的代码在取消选中时误加了商品 A 的 200总价就变成 550。我见过实际项目里出现过总价和明细对不上的线上问题排查了半天原因就是在多个回调方法里分别写了总价的加减逻辑有个分支漏掉了。后来我统一改成任何影响总价的操作最终都调用同一个calcTotal方法从列表数据重新算一遍。5.2 计算函数的具体实现calcTotal() { const cartList this.data.cartList; let totalCount 0; let totalPrice 0; cartList.forEach(item { if (item.checked) { totalCount item.count; // 注意浮点数精度问题 totalPrice item.price * item.count; } }); // 保留两位小数避免 0.30000000000000004 这种结果 totalPrice Math.round(totalPrice * 100) / 100; this.setData({ totalCount: totalCount, totalPrice: totalPrice }); }这个实现的逻辑非常直白只统计checked: true的商品。取消选中的商品不会进入任何总计计算。这样无论用户进行了什么操作——单独勾选、全选、改数量、删除——只要调用一次calcTotal结果一定是基于当前真实数据的。关于浮点数精度我特别提一下。0.1 * 3在 JavaScript 里算出来是0.30000000000000004这个精度问题在小程序里同样存在。我平时处理价格这种金额字段的原则是展示给用户之前统一用Math.round(price * 100) / 100做规整或者干脆把所有金额用分为单位存储为整数展示时再除以 100。后端接口如果给的是元前端在进入购物车时就可以直接转成分来运算最后展示再转回来。这样能彻底避开浮点数误差。5.3 展示格式价格数字的格式化总价算完了UI 上还要注意格式。比如总价 123.5 要显示成 123.50结果 0 要显示成 0.00。小程序里没有内置的toFixed以外的格式化函数建议统一用正则或toFixed处理formatPrice(value) { return Number(value).toFixed(2); }WXML 里绑定的时候直接这样写view classtotal-price{{totalPrice}}/view但注意totalPrice在 data 里已经是Math.round(...)后的数字展示时toFixed(2)的过程可以在calcTotal里完成也可以额外做一次格式化。我个人更推荐在calcTotal里直接setData一个字符串格式的总价避免在 WXML 里写{{totalPrice.toFixed(2)}}这种表达式因为 WXML 的表达能力有限写复杂表达式不便于维护。所以上面calcTotal的代码可以微调一下this.setData({ totalCount: totalCount, totalPrice: Math.round(totalPrice * 100) / 100 });然后在 WXML 里用{{totalPrice.toFixed(2)}}或者干脆 data 里直接存显示用的字符串都行。选一种适合你项目的方式保持一致就好。6. 收货地址模块从选一个地址到完整的地址链路标题里的收货地址是个容易被低估的功能。很多初学者觉得收货地址不就是跳转到一个地址列表页选择一下吗实际做起来涉及的东西比想象中多默认地址的标识、无地址时的引导、编辑/新增地址页、选择后的数据回传。6.1 地址数据的最小结构购物车页面要展示的地址信息通常只是当前选中的收货地址卡片不需要管整个地址簿。这个卡片的数据长这样data: { addressInfo: { id: 1001, name: 张三, phone: 138****8888, province: 广东省, city: 深圳市, district: 南山区, detail: 某路某号某栋某室, isDefault: true } }实际开发中地址列表和编辑页面通常不是购物车页面自己维护的而是跳转到独立的地址管理页面。小程序页面间可以通过eventChannel或者previewImage? 不应该用wx.navigateTo的events回调来传值。6.2 选择地址的页面跳转与回传我推荐用wx.navigateTo事件通道的方式把用户新选的地址回传到购物车页chooseAddress() { wx.navigateTo({ url: /pages/address/address?selectModetrue, events: { // 地址列表页选择地址后触发 selectAddress: (address) { this.setData({ addressInfo: address }); // 如果这个地址要参与后续的配送费计算这里也要联动重算 this.calcTotal(); } } }); }地址列表页在用户选择后这样把数据传回来// 地址列表页内部 bindSelectAddress(e) { const address e.currentTarget.dataset.item; const eventChannel this.getOpenerEventChannel(); eventChannel.emit(selectAddress, address); wx.navigateBack(); }这种方式的优点是购物车页不用把自己的状态透传给地址页地址页也不用关心上游是谁在听数据在事件通道上传递逻辑解耦。6.3 没有地址时怎么办如果addressInfo为空地址卡片位置应该显示请添加收货地址的引导点击后直接进入地址编辑页而不是地址列表页。data: { addressInfo: null } tapAddress() { if (!this.data.addressInfo) { // 无地址跳转去新增 wx.navigateTo({ url: /pages/address/edit?modeadd }); return; } // 已有地址跳转地址列表选择 this.chooseAddress(); }这里有一个产品层面的小决策新增完地址后要自动把它设为当前选中的地址。所以地址编辑页保存成功返回时也应该通过事件通道把新地址传递回来。6.4 地址变更后的价格联动有些项目的配送费会根据收货地址区域变化比如满 XX 元免运费偏远地区加配送费。如果购物车页的结算金额依赖地址信息地址回传后一定要重新调用calcTotal里有关配送费的部分。我在实际项目里会把配送费单独拆一个方法calcDeliveryFee(addressInfo, totalPrice) { if (!addressInfo) return 0; // 假设满 99 包邮否则收 10 元运费 if (totalPrice 99) return 0; return 10; }然后在calcTotal的最后根据addressInfo和totalPrice计算运费再生成实付款总额。记住地址不仅仅是展示卡片它是计算链路的一部分。7. 联动逻辑整合一次操作引发的连锁反应到这里购物车页面的几个核心功能都已经讲完。但把它们组合在一起才是真正考验代码组织能力的地方。7.1 统一的状态刷新入口我在项目里会做一个统一的刷新方法把全选状态、总数、总价、配送费、空态这些相互依赖的状态一次性刷新refreshState() { this.updateAllChecked(); this.calcTotal(); this.updateEmptyState(); }然后所有的用户交互方法比如onItemCheck、changeCount、removeItem、onToggleAll在修改完cartList之后统一调用refreshState()而不是各自调用其中的一两个。这样做最大的好处是新增需求时不需要去梳理到底哪些交互需要刷新哪些状态只要保证 refreshState 里的逻辑完整所有页面状态一定同步。举个例子后来我在项目里增加了每个商品显示小计金额即price * count实时展示因为所有路径都走 refreshState只需要在列表渲染时计算一下item.price * item.count就行完全不需要改其他方法。7.2 结算按钮的权限判断购物车页面的底部通常有一个结算按钮点击后的逻辑不只是一句跳转到下单页这么简单。要判断几个前置条件购物车是否为空是否有选中的商品是否已有收货地址是否所有选中商品的数量都在库存范围内。goToCheckout() { if (this.data.cartList.length 0) { wx.showToast({ title: 购物车空空如也, icon: none }); return; } const selectedItems this.data.cartList.filter(item item.checked); if (selectedItems.length 0) { wx.showToast({ title: 请先选择商品, icon: none }); return; } if (!this.data.addressInfo) { // 提示用户去添加地址 wx.showModal({ title: 提示, content: 请先添加收货地址, confirmText: 去添加, success: (res) { if (res.confirm) { this.tapAddress(); } } }); return; } // 组装下单参数 const orderParams { addressId: this.data.addressInfo.id, items: selectedItems.map(item ({ skuId: item.id, count: item.count })), totalPrice: this.data.totalPrice, deliveryFee: this.data.deliveryFee }; wx.navigateTo({ url: /pages/order-confirm/order-confirm?params${JSON.stringify(orderParams)} }); }这里有一个细节如果某个商品的库存发生了变化比如其他端的用户把货买完了实际提交订单时后端可能返回库存不足。前端的校验只能优化体验不能替代后端校验这点务必在联调时和接口方对齐。7.3 数据持久化用户关闭小程序再打开购物车还在吗购物车数据如果只存在页面 data 里用户一旦关闭小程序数据就没了——这显然不能接受。常见的方案有两种。第一种同步到服务端。用户每次变更购物车就调用接口把购物车列表保存到服务端下次进入页面时请求接口拉取。这是最稳的方案购物车数据不占用本地存储多端同步也没问题。第二种用本地缓存wx.setStorageSync做兜底。在购物车数据每次变更后把cartList写进本地缓存页面加载时先读取本地缓存展示同时异步请求服务端数据服务端数据返回后以服务端为准。saveCartToStorage(cartList) { wx.setStorageSync(cartList, cartList); } loadCartFromStorage() { return wx.getStorageSync(cartList) || []; }我个人的建议是如果项目有完整的用户体系和登录态优先做服务端同步本地缓存只作为弱网环境的临时数据源。如果只是教学项目或者内部 demo本地缓存也够用。8. 开发中容易踩的坑以及我总结的几条心得最后这部分我把自己在购物车功能上踩过的坑和解决思路整理出来希望能帮你少走弯路。8.1 wx:key 的使用在wx:for渲染购物车列表时wx:key一定要写。如果不写小程序会报一个警告而且列表增删时渲染效率会明显下降严重时会出现勾选状态错乱的视觉问题。view classcart-item wx:for{{cartList}} wx:keyidwx:key的值必须是列表中每个条目的唯一字段。如果后端返回的 skuId 有可能重复比如数据异常可以在进入页面前主动清洗数据为每个条目补充一个_key字段const list rawList.map((item, index) ({ ...item, _key: item.skuId || ${index}_${Date.now()} }));然后用wx:key_key。8.2 视图层与数据层的选中状态不同步我遇到过一种情况用户快速连续点击两个商品的 checkbox结果界面上第二个商品选中了但结算总价没有发生变化。原因是第一个 click 回调还没执行完setData还没更新到视图层第二次点击拿到的this.data.cartList还是旧的。这种异步更新导致的竞态在小程序中并不少见。规避方法有两个一是在交互方法开头用this.setData直接计算新状态而不是依赖上一次 setData 完成后的 this.data也就是我上面写的用路径更新cartList[index].checked这种方式二是对于批量操作场景不要在回调里做复杂的异步链尽量保证一次交互只更新一次状态。8.3 金额计算一定要用分或规整函数前面提过的精度问题我这里再展开一次。如果你后端的金额单位是元前端直接减乘除大概率会出现类似19.99 * 3 59.970000000000006的结果。虽然在小程序的数字类型里它也能显示但你拿去做条件判断比如price 60就可能出错。我现在的习惯是所有从后端拿到的金额字段进入前端逻辑层后统一乘以 100 转成整数分。比如 19.99 元处理后是1999分。所有运算都在整型上做最后展示时统一(price / 100).toFixed(2)。这样基本可以消除浮点误差也方便后续对接支付接口很多支付渠道的金额单位就是分。8.4 修改数量时的防抖处理步进器按钮如果用bindtap用户快速连点十下加号会触发十次changeCount每次都要 setData 和计算总价。虽然小程序性能不至于卡死但肯定有浪费。简单防抖的做法在changeCount里加一个锁或者减少 setData 的频率。我个人更推荐后者——连续点击时使用count的差量累计在最后一次点击后统一更新。不过对于绝大多数中小型项目单次 setData 的开销完全可接受不用过度优化。如果哪天你发现页面在低端机上明显卡顿再考虑做防抖和批量更新也不迟。8.5 与后端的字段对齐这块属于联调时的高频坑。后端返回的商品列表中价格字段可能是price、salePrice、promotionPrice的任意一个库存可能是stock或quantity。购物车页面到底显示哪个价格、用哪个库存做上限一定要在开发前和后端确认清楚。我吃过一次亏商品列表页展示的是salePrice购物车页没注意用了price结果用户在列表页看是 99 元进购物车变成 129 元差点变成投诉事故。前端页面之间数据语义不一致是比写错代码更隐蔽的问题。8.6 可扩展的方向如果你做完购物车基础功能想继续往下深入可以考虑这几个方向优惠券/促销活动的费用计算满减、折扣、优惠券会在 calcTotal 里引入更复杂的规则。建议把每种优惠规则抽成独立函数不要堆在一个方法里。失效商品的处理商品下架或已删除后购物车里的条目要能标识失效用户可以直接删除但不能选中参与结算。购物车的多端同步用户在小程序里加购在另一个端也要能看到同一份购物车数据这要求购物车数据整体放到服务端前端只做展示和操作。勾选状态的记忆有些产品设计希望用户离开页面再回来时之前勾选的状态保留有些则希望重置。这个产品决策需要提前跟产品经理确认再决定是否需要持久化 checked 状态。9. 结语购物车这个模块写一版能用不难但想写得稳、容易扩展、不容易出线上问题还是有不少门道的。我在这个功能上反反复复重构过几次最终的体会是先把数据结构和状态来源想清楚比把页面样式做漂亮重要得多。希望你看完这篇再回头写购物车的时候能少踩几个坑。如果你在开发中遇到了我没提到的问题欢迎在评论区和大家交流集思广益总比自己苦思冥想要高效得多。 
长河君 · 2026/10/16 9:36:36 · 阅读 1.2k 小程序购物车开发：全选反选、数量修改、删除与地址联动实现
1. 购物车模块为什么值得单独拆出来写做小程序电商的人都知道购物车是整个交易链路里最琐碎、又最容易写出 bug 的模块之一。它不像商品详情页那样只要展示信息也不像下单页那样流程固定购物车要同时处理选中状态、数量变化、价格计算、地址联动任何一个环节没想清楚后面都会牵连出一堆问题。我这篇文章要聊的内容正好就是标题里这几个功能点全选与反选、修改商品数量、删除商品、计算总价格和总数量、收货地址。这几个功能看起来各自独立实际上是一条完整的交互链路——用户勾选商品 - 调整数量 - 看总价 - 确认收货地址 - 去结算整条链路的数据流转是共享的。所以我把它们拆成一篇文章从头到尾捋一遍。文章适合两类人看一类是刚接触小程序开发、正准备上手写购物车的初学者另一类是已经写过购物车但总觉得代码绕来绕去、想看看别人怎么组织数据的开发者。我会从数据模型讲起把每个交互背后的状态管理逻辑说清楚最后再分享一些真实项目里踩过的坑。2. 先把数据结构想明白后面能少改一半代码购物车功能能不能写得顺第一个决定因素不是页面长什么样而是数据怎么组织。我在早期开发时犯过一个典型的错误把购物车数据直接塞在页面 data 里页面里到处是cartList[0].checked true这种硬编码索引的操作。结果需求一调整改一个字段连带三四段逻辑一起崩。后来我总结出一个原则购物车的数据结构要能独立表达一个商品的所有购物车状态并且状态之间的变更尽量收敛到几个固定方法里。2.1 商品条目最少需要哪些字段以我目前常用的结构为例购物车里每一个商品条目至少需要这些字段{ id: sku_001, // 商品规格ID不是商品ID一个商品可能有多个规格 name: 无线蓝牙耳机, // 用于展示 price: 129.00, // 单价注意用数字类型别用字符串 count: 2, // 当前购物车数量 checked: true, // 是否被选中默认 false stock: 50, // 库存用来限制最大购买数量 image: /images/xxx.png, // 缩略图 specText: 白色 / 标准版 // 规格描述比如颜色、尺寸 }这里有两个容易被忽略的点。第一id一定要用规格ID而不是商品ID。同一件商品如果有黑白两个颜色在购物车里就是两个独立条目它们有着不同的 sku 标识。如果用商品ID做唯一标识选颜色就会完全混乱。第二price用数字类型。很多从后端拿到价格可能是字符串直接拿来算总价会出现129 2变成1292这种令人抓狂的问题。建议在数据进入购物车前统一用Number()转换一次。2.2 页面层购物车数据的整体形态购物车页面的 data 里通常需要维护三个核心字段商品列表、全选状态、以及计算后的总数量和总价格。data: { cartList: [], // 商品条目数组 allChecked: false, // 全选按钮的状态 totalCount: 0, // 选中的商品总数量 totalPrice: 0.00 // 选中的商品总价格 }我见过不少新手把总价、总数也当作独立变量去手动赋值比如每次点击加号就this.setData({ totalPrice: this.data.totalPrice price })。这种方式在单个操作下没问题一旦出现同时取消多个商品批量删除这类操作手动累加的误差就很容易冒出来。后面我会讲一种更稳的方式——计算函数集中重算。3. 全选与反选checkbox 联动背后的状态同步全选与反选是购物车交互里最表面、但坑最多的地方。先说概念再讲实现。这里我先明确一下反选在我的语境里的含义它对应的是全选按钮被再次点击时的动作。当所有商品都被选中时用户再次点击全选按钮应该让所有商品变成未选中状态——也就是一个全不选的切换。有的需求会把反选理解为选中状态翻转选中的变未选中未选中的变选中但购物车场景下这种需求极少大部分产品设计的都是前者。我下面的实现按这个来。3.1 单商品的选中切换单个商品的选中状态通过商品行内的 checkbox 来切换。这是最底层的事件其他所有状态全选、总计都要由它触发重新计算。view classcart-item wx:for{{cartList}} wx:keyid checkbox checked{{item.checked}} >onItemCheck(e) { const index e.currentTarget.dataset.index; const cartList this.data.cartList; cartList[index].checked e.detail.value; this.setData({ cartList: cartList }); // 重新计算全选状态和总计 this.updateAllChecked(); this.calcTotal(); }这里有一个非常关键的细节修改数组里的某个元素不能用this.data.cartList[index].checked ...之后直接 setData 整个数组吗可以但我不推荐直接改this.data。小程序里setData的性能和可维护性都跟数据操作方式有关更稳妥的做法是先用wx:key让列表有稳定的 diff 基础然后单独更新被修改的那一项onItemCheck(e) { const index e.currentTarget.dataset.index; const checked e.detail.value; this.setData({ [cartList[${index}].checked]: checked }); this.updateAllChecked(); this.calcTotal(); }使用cartList[index].checked这种路径式写法只更新一个字段避免整个列表重新渲染性能更好代码意图也更清晰。3.2 全选按钮的状态计算不是点击出来的是推导出来的很多新手的第一反应是全选按钮就是点击之后遍历列表把所有项设置为 true 或 false。这个方向没错但隐藏着一个容易漏掉的问题——当用户手动取消了某个商品时全选按钮必须自动变为未选中状态而不是停留在之前的选中态。所以全选按钮的状态不应该只在点击全选时维护而应该在每次商品选中状态变化时重新推导。updateAllChecked() { const cartList this.data.cartList; // 空列表时全选应为 false if (cartList.length 0) { this.setData({ allChecked: false }); return; } // 所有商品都被选中全选才为 true const allChecked cartList.every(item item.checked); this.setData({ allChecked: allChecked }); }Array.prototype.every在这里非常好用只要有一个商品未选中结果就是 false不需要自己写循环去数。3.3 全选/反选的切换事件全选按钮的事件逻辑是onToggleAll() { const newChecked !this.data.allChecked; const cartList this.data.cartList; // 遍历所有商品批量设置选中状态 const newList cartList.map(item { return { ...item, checked: newChecked }; }); this.setData({ cartList: newList, allChecked: newChecked }); this.calcTotal(); }注意虽然allChecked已经在点击时直接设置了我依然建议用updateAllChecked()推导一遍这样可以保证数据和状态的逻辑永远只有一条来源不容易出现看起来状态对了但数据里 checked 字段是错的这种隐性 bug。你说多调用一次是不是浪费在小程序这种体量的列表渲染下这点开销可以忽略换来的是维护成本下降。4. 商品数量修改与删除边界条件和交互反馈同样重要数量修改和删除表面是做加减法和移除数组元素实际要处理的细节很多——边界值、库存限制、空列表状态、二次确认每一项都是用户体验的关键。4.1 步进器的加减逻辑数量控制的经典作法是商品行内的加减按钮中间显示数量。我用一个统一的changeCount方法处理加和减changeCount(e) { const { index, type } e.currentTarget.dataset; const cartList this.data.cartList; const item cartList[index]; let newCount item.count; if (type minus) { if (item.count 1) { // 数量到达下限给出提示或者引导删除 wx.showToast({ title: 最少购买1件, icon: none }); return; } newCount item.count - 1; } else if (type plus) { if (item.count item.stock) { wx.showToast({ title: 已达库存上限, icon: none }); return; } newCount item.count 1; } this.setData({ [cartList[${index}].count]: newCount }); this.calcTotal(); }这里有三个容易被忽视的细节下限不一定是 1。有些商品设置了最少起购量比如批发类的商品最少买 5 件。设计数据模型时最好预留一个minBuy字段不要写死。上限是库存 stock但实际场景中还要考虑限购数量。有些活动商品单人限购 2 件这时上限应该是Math.min(stock, limit)而不是只看库存。超出边界时不要直接 return 不响应。一个简单的 toast 提示能避免用户反复点按钮却没有任何反馈觉得自己买到假按钮了。另外有些项目会提供输入框让用户直接修改数量这个场景下还要额外校验输入值是不是整数、是否在合法区间处理方式类似只是来源从按钮变成了输入事件。4.2 删除商品确认弹窗与数据清理删除操作在移动端几乎都要做二次确认防止误触。小程序的wx.showModal是标准方案removeItem(e) { const index e.currentTarget.dataset.index; const item this.data.cartList[index]; wx.showModal({ title: 提示, content: 确定要删除「${item.name}」吗, success: (res) { if (res.confirm) { const cartList this.data.cartList; cartList.splice(index, 1); this.setData({ cartList: cartList }); this.updateAllChecked(); this.calcTotal(); } } }); }删除之后有两件事必须立刻做更新全选状态可能你删掉了最后一个未选中的商品或者删到列表为空以及重新计算总价和总数量。还有一个经常被忽略的场景——批量删除。购物车右上角一般会有管理/完成切换进入管理状态后可以多选商品批量删除。这种模式下的实现并不复杂批量删除其实就是把所有 checked 为 true 的条目从数组里过滤掉。removeBatch() { const cartList this.data.cartList; const remainList cartList.filter(item !item.checked); this.setData({ cartList: remainList }); this.updateAllChecked(); this.calcTotal(); }注意这个方案对全选删除也成立——把全部商品删掉后cartList变为空数组updateAllChecked会把全选按钮置灰总价归零页面显示空状态。边界情况要专门测试一下。4.3 删除到空列表之后空态提示购物车清空后页面底部不应该还显示着一个大大的结算按钮和 0.00 的总价。通常的做法是cartList为空时展示一个空态区域提示用户去逛逛同时隐藏底部操作栏。这个逻辑不复杂核心是在 data 里加一个布尔值在每次增删后同步更新data: { // 新增一个字段 isEmpty: true } updateEmptyState() { this.setData({ isEmpty: this.data.cartList.length 0 }); }WXML 里用wx:if控制空态和列表的切换底部操作栏也用wx:if{{!isEmpty}}控制显示。空态页面建议加一个去逛逛按钮直接跳转到商品列表页这样用户清空购物车之后不会卡在页面上不知道去哪。5. 总价格和总数量的计算把所有状态收敛到一个方法里这是整篇文章里逻辑最核心的部分。标题里写了计算总价格和总数量这个功能我把它单独拿出来是因为很多 bug 都是在这里产生的。5.1 为什么不能每操作一次就手动加减总价我先解释一下前面提到的计算函数集中重算为什么不手写累加。假设商品 A 价格 100 选 2 件商品 B 价格 50 选 3 件。总价是 350。用户把商品 A 取消选中这时总价应该变成 150但如果你的代码在取消选中时误加了商品 A 的 200总价就变成 550。我见过实际项目里出现过总价和明细对不上的线上问题排查了半天原因就是在多个回调方法里分别写了总价的加减逻辑有个分支漏掉了。后来我统一改成任何影响总价的操作最终都调用同一个calcTotal方法从列表数据重新算一遍。5.2 计算函数的具体实现calcTotal() { const cartList this.data.cartList; let totalCount 0; let totalPrice 0; cartList.forEach(item { if (item.checked) { totalCount item.count; // 注意浮点数精度问题 totalPrice item.price * item.count; } }); // 保留两位小数避免 0.30000000000000004 这种结果 totalPrice Math.round(totalPrice * 100) / 100; this.setData({ totalCount: totalCount, totalPrice: totalPrice }); }这个实现的逻辑非常直白只统计checked: true的商品。取消选中的商品不会进入任何总计计算。这样无论用户进行了什么操作——单独勾选、全选、改数量、删除——只要调用一次calcTotal结果一定是基于当前真实数据的。关于浮点数精度我特别提一下。0.1 * 3在 JavaScript 里算出来是0.30000000000000004这个精度问题在小程序里同样存在。我平时处理价格这种金额字段的原则是展示给用户之前统一用Math.round(price * 100) / 100做规整或者干脆把所有金额用分为单位存储为整数展示时再除以 100。后端接口如果给的是元前端在进入购物车时就可以直接转成分来运算最后展示再转回来。这样能彻底避开浮点数误差。5.3 展示格式价格数字的格式化总价算完了UI 上还要注意格式。比如总价 123.5 要显示成 123.50结果 0 要显示成 0.00。小程序里没有内置的toFixed以外的格式化函数建议统一用正则或toFixed处理formatPrice(value) { return Number(value).toFixed(2); }WXML 里绑定的时候直接这样写view classtotal-price{{totalPrice}}/view但注意totalPrice在 data 里已经是Math.round(...)后的数字展示时toFixed(2)的过程可以在calcTotal里完成也可以额外做一次格式化。我个人更推荐在calcTotal里直接setData一个字符串格式的总价避免在 WXML 里写{{totalPrice.toFixed(2)}}这种表达式因为 WXML 的表达能力有限写复杂表达式不便于维护。所以上面calcTotal的代码可以微调一下this.setData({ totalCount: totalCount, totalPrice: Math.round(totalPrice * 100) / 100 });然后在 WXML 里用{{totalPrice.toFixed(2)}}或者干脆 data 里直接存显示用的字符串都行。选一种适合你项目的方式保持一致就好。6. 收货地址模块从选一个地址到完整的地址链路标题里的收货地址是个容易被低估的功能。很多初学者觉得收货地址不就是跳转到一个地址列表页选择一下吗实际做起来涉及的东西比想象中多默认地址的标识、无地址时的引导、编辑/新增地址页、选择后的数据回传。6.1 地址数据的最小结构购物车页面要展示的地址信息通常只是当前选中的收货地址卡片不需要管整个地址簿。这个卡片的数据长这样data: { addressInfo: { id: 1001, name: 张三, phone: 138****8888, province: 广东省, city: 深圳市, district: 南山区, detail: 某路某号某栋某室, isDefault: true } }实际开发中地址列表和编辑页面通常不是购物车页面自己维护的而是跳转到独立的地址管理页面。小程序页面间可以通过eventChannel或者previewImage? 不应该用wx.navigateTo的events回调来传值。6.2 选择地址的页面跳转与回传我推荐用wx.navigateTo事件通道的方式把用户新选的地址回传到购物车页chooseAddress() { wx.navigateTo({ url: /pages/address/address?selectModetrue, events: { // 地址列表页选择地址后触发 selectAddress: (address) { this.setData({ addressInfo: address }); // 如果这个地址要参与后续的配送费计算这里也要联动重算 this.calcTotal(); } } }); }地址列表页在用户选择后这样把数据传回来// 地址列表页内部 bindSelectAddress(e) { const address e.currentTarget.dataset.item; const eventChannel this.getOpenerEventChannel(); eventChannel.emit(selectAddress, address); wx.navigateBack(); }这种方式的优点是购物车页不用把自己的状态透传给地址页地址页也不用关心上游是谁在听数据在事件通道上传递逻辑解耦。6.3 没有地址时怎么办如果addressInfo为空地址卡片位置应该显示请添加收货地址的引导点击后直接进入地址编辑页而不是地址列表页。data: { addressInfo: null } tapAddress() { if (!this.data.addressInfo) { // 无地址跳转去新增 wx.navigateTo({ url: /pages/address/edit?modeadd }); return; } // 已有地址跳转地址列表选择 this.chooseAddress(); }这里有一个产品层面的小决策新增完地址后要自动把它设为当前选中的地址。所以地址编辑页保存成功返回时也应该通过事件通道把新地址传递回来。6.4 地址变更后的价格联动有些项目的配送费会根据收货地址区域变化比如满 XX 元免运费偏远地区加配送费。如果购物车页的结算金额依赖地址信息地址回传后一定要重新调用calcTotal里有关配送费的部分。我在实际项目里会把配送费单独拆一个方法calcDeliveryFee(addressInfo, totalPrice) { if (!addressInfo) return 0; // 假设满 99 包邮否则收 10 元运费 if (totalPrice 99) return 0; return 10; }然后在calcTotal的最后根据addressInfo和totalPrice计算运费再生成实付款总额。记住地址不仅仅是展示卡片它是计算链路的一部分。7. 联动逻辑整合一次操作引发的连锁反应到这里购物车页面的几个核心功能都已经讲完。但把它们组合在一起才是真正考验代码组织能力的地方。7.1 统一的状态刷新入口我在项目里会做一个统一的刷新方法把全选状态、总数、总价、配送费、空态这些相互依赖的状态一次性刷新refreshState() { this.updateAllChecked(); this.calcTotal(); this.updateEmptyState(); }然后所有的用户交互方法比如onItemCheck、changeCount、removeItem、onToggleAll在修改完cartList之后统一调用refreshState()而不是各自调用其中的一两个。这样做最大的好处是新增需求时不需要去梳理到底哪些交互需要刷新哪些状态只要保证 refreshState 里的逻辑完整所有页面状态一定同步。举个例子后来我在项目里增加了每个商品显示小计金额即price * count实时展示因为所有路径都走 refreshState只需要在列表渲染时计算一下item.price * item.count就行完全不需要改其他方法。7.2 结算按钮的权限判断购物车页面的底部通常有一个结算按钮点击后的逻辑不只是一句跳转到下单页这么简单。要判断几个前置条件购物车是否为空是否有选中的商品是否已有收货地址是否所有选中商品的数量都在库存范围内。goToCheckout() { if (this.data.cartList.length 0) { wx.showToast({ title: 购物车空空如也, icon: none }); return; } const selectedItems this.data.cartList.filter(item item.checked); if (selectedItems.length 0) { wx.showToast({ title: 请先选择商品, icon: none }); return; } if (!this.data.addressInfo) { // 提示用户去添加地址 wx.showModal({ title: 提示, content: 请先添加收货地址, confirmText: 去添加, success: (res) { if (res.confirm) { this.tapAddress(); } } }); return; } // 组装下单参数 const orderParams { addressId: this.data.addressInfo.id, items: selectedItems.map(item ({ skuId: item.id, count: item.count })), totalPrice: this.data.totalPrice, deliveryFee: this.data.deliveryFee }; wx.navigateTo({ url: /pages/order-confirm/order-confirm?params${JSON.stringify(orderParams)} }); }这里有一个细节如果某个商品的库存发生了变化比如其他端的用户把货买完了实际提交订单时后端可能返回库存不足。前端的校验只能优化体验不能替代后端校验这点务必在联调时和接口方对齐。7.3 数据持久化用户关闭小程序再打开购物车还在吗购物车数据如果只存在页面 data 里用户一旦关闭小程序数据就没了——这显然不能接受。常见的方案有两种。第一种同步到服务端。用户每次变更购物车就调用接口把购物车列表保存到服务端下次进入页面时请求接口拉取。这是最稳的方案购物车数据不占用本地存储多端同步也没问题。第二种用本地缓存wx.setStorageSync做兜底。在购物车数据每次变更后把cartList写进本地缓存页面加载时先读取本地缓存展示同时异步请求服务端数据服务端数据返回后以服务端为准。saveCartToStorage(cartList) { wx.setStorageSync(cartList, cartList); } loadCartFromStorage() { return wx.getStorageSync(cartList) || []; }我个人的建议是如果项目有完整的用户体系和登录态优先做服务端同步本地缓存只作为弱网环境的临时数据源。如果只是教学项目或者内部 demo本地缓存也够用。8. 开发中容易踩的坑以及我总结的几条心得最后这部分我把自己在购物车功能上踩过的坑和解决思路整理出来希望能帮你少走弯路。8.1 wx:key 的使用在wx:for渲染购物车列表时wx:key一定要写。如果不写小程序会报一个警告而且列表增删时渲染效率会明显下降严重时会出现勾选状态错乱的视觉问题。view classcart-item wx:for{{cartList}} wx:keyidwx:key的值必须是列表中每个条目的唯一字段。如果后端返回的 skuId 有可能重复比如数据异常可以在进入页面前主动清洗数据为每个条目补充一个_key字段const list rawList.map((item, index) ({ ...item, _key: item.skuId || ${index}_${Date.now()} }));然后用wx:key_key。8.2 视图层与数据层的选中状态不同步我遇到过一种情况用户快速连续点击两个商品的 checkbox结果界面上第二个商品选中了但结算总价没有发生变化。原因是第一个 click 回调还没执行完setData还没更新到视图层第二次点击拿到的this.data.cartList还是旧的。这种异步更新导致的竞态在小程序中并不少见。规避方法有两个一是在交互方法开头用this.setData直接计算新状态而不是依赖上一次 setData 完成后的 this.data也就是我上面写的用路径更新cartList[index].checked这种方式二是对于批量操作场景不要在回调里做复杂的异步链尽量保证一次交互只更新一次状态。8.3 金额计算一定要用分或规整函数前面提过的精度问题我这里再展开一次。如果你后端的金额单位是元前端直接减乘除大概率会出现类似19.99 * 3 59.970000000000006的结果。虽然在小程序的数字类型里它也能显示但你拿去做条件判断比如price 60就可能出错。我现在的习惯是所有从后端拿到的金额字段进入前端逻辑层后统一乘以 100 转成整数分。比如 19.99 元处理后是1999分。所有运算都在整型上做最后展示时统一(price / 100).toFixed(2)。这样基本可以消除浮点误差也方便后续对接支付接口很多支付渠道的金额单位就是分。8.4 修改数量时的防抖处理步进器按钮如果用bindtap用户快速连点十下加号会触发十次changeCount每次都要 setData 和计算总价。虽然小程序性能不至于卡死但肯定有浪费。简单防抖的做法在changeCount里加一个锁或者减少 setData 的频率。我个人更推荐后者——连续点击时使用count的差量累计在最后一次点击后统一更新。不过对于绝大多数中小型项目单次 setData 的开销完全可接受不用过度优化。如果哪天你发现页面在低端机上明显卡顿再考虑做防抖和批量更新也不迟。8.5 与后端的字段对齐这块属于联调时的高频坑。后端返回的商品列表中价格字段可能是price、salePrice、promotionPrice的任意一个库存可能是stock或quantity。购物车页面到底显示哪个价格、用哪个库存做上限一定要在开发前和后端确认清楚。我吃过一次亏商品列表页展示的是salePrice购物车页没注意用了price结果用户在列表页看是 99 元进购物车变成 129 元差点变成投诉事故。前端页面之间数据语义不一致是比写错代码更隐蔽的问题。8.6 可扩展的方向如果你做完购物车基础功能想继续往下深入可以考虑这几个方向优惠券/促销活动的费用计算满减、折扣、优惠券会在 calcTotal 里引入更复杂的规则。建议把每种优惠规则抽成独立函数不要堆在一个方法里。失效商品的处理商品下架或已删除后购物车里的条目要能标识失效用户可以直接删除但不能选中参与结算。购物车的多端同步用户在小程序里加购在另一个端也要能看到同一份购物车数据这要求购物车数据整体放到服务端前端只做展示和操作。勾选状态的记忆有些产品设计希望用户离开页面再回来时之前勾选的状态保留有些则希望重置。这个产品决策需要提前跟产品经理确认再决定是否需要持久化 checked 状态。9. 结语购物车这个模块写一版能用不难但想写得稳、容易扩展、不容易出线上问题还是有不少门道的。我在这个功能上反反复复重构过几次最终的体会是先把数据结构和状态来源想清楚比把页面样式做漂亮重要得多。希望你看完这篇再回头写购物车的时候能少踩几个坑。如果你在开发中遇到了我没提到的问题欢迎在评论区和大家交流集思广益总比自己苦思冥想要高效得多。