购物车页面大概是电商小程序里交互密度最高的页面之一。全选和反选、修改商品数量、删除商品、计算总价格和总数量、收货地址这五组功能单独拆开都不算难但真要在一个页面里全部跑通就会撞上数据同步、状态判断、浮点精度、授权处理这些订单文档里不会写的问题。最近我在做电商项目时正好把这套购物车功能完整实做了一遍借这个机会把完整思路、可复用的代码结构、以及实际踩过的坑都整理出来给正在写购物车页面的朋友当个参考。这篇文章默认你用的是原生小程序语法对该项目熟悉后要迁移到第三方框架思路同样适用。1. 项目整体思路与购物车数据模型1.1 购物车功能开发前必须先想清楚的三件事第一个问题购物车数据从哪来、怎么存。购物车本质上是一个本地待确认的商品集合数据来源通常有两个渠道用户手动加购的商品快照以及用户之前加购但未下单的历史记录。前者要求前端实时维护后者要求接口持久化。一个标准购物车页面进入时先拉接口拿历史数据再合并本地临时加购的商品整个列表才完整。第二个问题视图层与数据层的关系。小程序是数据驱动视图的框架页面里看到的一切——商品名、价格、数量、选中状态、勾选样式——都应该是data里某个字段的直接映射。我最常看到新手翻车的地方就是在wxml里直接修改checkbox的checked属性却没有同步更新data里的selected字段。结果就是视觉上勾选了点全选时数据却对不上总价计算全乱。第三个问题页面内有几类状态需要维护。购物车这个页面至少有三类状态商品本身的属性名称、价格、规格、库存、数量商品的选中状态selected以及派生的全选框三态底部结算栏的统计状态总数量、总价格。这三类状态不是孤立的每次交互都可能同时影响多个角落。1.2 购物车的数据结构怎么设计先说结论用数组存储商品列表每个商品是一个扁平对象推荐的结构如下。Page({ data: { items: [ { id: spu_10001, // 商品唯一标识 name: 夏季薄款纯棉T恤, // 商品名称 priceCent: 9900, // 成交单价单位是分重要 originalPriceCent: 15900, spec: 白色 / M码, // 规格文案 stock: 99, // 库存 count: 2, // 当前数量 selected: true, // 是否被选中 image: /images/t-shirt.png } ], selectAllStatus: all, // 全选框状态none / partial / all totalCount: 0, // 选中商品总数量 totalPriceYuan: 0.00, // 选中商品总价单位元展示用 hasItems: true // 购物车是否为空 } })有几个设计点需要解释清楚。第一价格字段为什么用priceCent而不是price。因为JS的浮点运算在金额计算上会出问题比如19.9 * 3在某些情况下会得到59.69999999999999。而用整数分做计算乘法加法都是整数运算不会丢精度展示时再除以100转成元。这个设计在绝大多数商城系统中都是标准做法小程序项目里也应该遵守。第二为什么购物车要存商品快照而不是实时去后台查商品表。因为购物车展示的价格应该是用户加购那一刻的价格。如果后台改了价购物车里的历史价格也跟着变用户下单时会发现价格和之前看到的不一致容易引发纠纷。所以购物车列表用快照价格展示结算时后台再根据真实商品id做最终校验。同样的道理也适用于商品名称、图片、规格文案——都应该是快照。第三selectAllStatus单独拎出来维护而不是让WXML里动态判断。这个字段承载的是全选按钮的三态全部未选none、部分选中partial、全部选中all。原生checkbox的checked只有 true/false 两个状态表达不了部分选中的视觉所以需要我们自己维护一个三态字段配合CSS样式来渲染。1.3 这个项目的功能链路规划购物车页面的完整流程可以串成一条线进入页面 - 加载并渲染购物车列表 - 用户单选/全选/反选商品 - 修改商品数量或删除商品 - 底部统计栏实时计算总数量和总价格 - 点击结算 - 校验是否已选商品、是否已有收货地址 - 选择或新增地址 - 提交订单。整条链路中前端要重点盯住两个节点一是列表数据的任何变化都要触发统计逻辑重新计算二是结算前的地址校验必须走通缺了任何一个环节用户都会卡在半路。2. 全选与反选选中状态的三态管理2.1 全选按钮为什么会有三种视觉状态很多人第一次写全选以为全选按钮只有选中/未选中两态。实际在电商场景里只要用户手动取消了其中一个商品全选按钮就会进入第三种视觉状态——半选态通常显示为一个横杠表示部分商品已选中。所以全选按钮的视觉逻辑是这样的统计所有商品的selected状态如果全部为true显示全选态如果全部为false显示未选态如果有部分为true显示半选态。这个统计函数在每次单品选择变化后必须重新执行这是整个页面状态同步的核心。2.2 单元选择与全选状态的联动单选一个商品的事件处理逻辑可以这样写toggleSelect(e) { const index e.currentTarget.dataset.index const current this.data.items[index].selected this.setData({ [items[${index}].selected]: !current }) this.updateSelectAllStatus() }, updateSelectAllStatus() { const items this.data.items const selectedCount items.filter(item item.selected).length let status none if (selectedCount 0) { status none } else if (selectedCount items.length) { status all } else { status partial } this.setData({ selectAllStatus: status }) this.calcTotal() }这里有一个关键技巧用items[index].selected这种路径更新的方式只更新被点击的那一项数据而不是把整个items数组重新set一遍。当购物车里有几十个商品时全量setData和路径更新的性能差异非常明显低端机上能感知到卡顿。2.3 全选与反选的交互实现标题里说的全选和反选在电商购物车场景下指的就是全选按钮的正向与反向操作当前处于非全选状态时点击后全部选中当前已经全选时点击后全部取消。这是同一种按钮的两种方向不需要额外做反选所有当前未选中的商品这种文件管理器的逻辑。实现代码toggleSelectAll() { const items this.data.items const isAllSelected this.data.selectAllStatus all const newItems items.map(item ({ ...item, selected: !isAllSelected })) this.setData({ items: newItems, selectAllStatus: isAllSelected ? none : all }) this.calcTotal() }注意全选按钮我用的是bindtap不是bindchange。原因很简单checkbox组件的change事件在不同基础库版本上表现有差异而且它的状态变化往往是自管理的容易和数据层产生混淆。直接用tap自己控制状态翻转逻辑更干净。2.4 全选按钮的WXML与样式实现全选按钮用自定义view来画而不是用原生checkbox。原因是原生checkbox的中间态半选样式很难自定义跨端表现也不一致。自定义view的方式灵活得多用CSS类切换三种状态。view classselect-all-bar view classcheck-btn {{selectAllStatus ! none ? checked : }} {{selectAllStatus partial ? partial : }} bindtaptoggleSelectAll text wx:if{{selectAllStatus all}}✓/text text wx:elif{{selectAllStatus partial}}-/text /view text全选/text /view对应的样式.check-btn { width: 40rpx; height: 40rpx; border-radius: 50%; border: 2rpx solid #ccc; display: flex; align-items: center; justify-content: center; margin-right: 12rpx; box-sizing: border-box; } .check-btn.checked { background: #e64340; border-color: #e64340; color: #fff; } .check-btn.partial { background: #e64340; border-color: #e64340; color: #fff; }单个商品的勾选按钮样式可以完全复用这套类只是绑定事件和状态不同。这样整个购物车页面的选中视觉是统一的不会有商品勾选是圆的、底栏全选是方的这种割裂感。3. 修改商品数量与删除商品3.1 数量加减的边界条件数量修改是购物车里最容易出bug的部分核心就是边界判断。数量不是可以无限加减的它有两个硬边界下限是1上限是库存。changeCount(e) { const { index, type } e.currentTarget.dataset const item this.data.items[index] if (type minus item.count 1) { return } if (type plus item.count item.stock) { wx.showToast({ title: 已达库存上限, icon: none }) return } const newCount type plus ? item.count 1 : item.count - 1 this.setData({ [items[${index}].count]: newCount }) this.calcTotal() }这里有几个容易被忽略的点。减到1时按钮要不要置灰取决于产品设计但至少点击不应再触发计算。加到库存上限时除了拦截最好给个轻提示不然用户会以为按钮坏了。另外库存的判断要用而不是因为等于库存时已经不能再加了。还有一个实战中的细节在快速连续点击按钮时事件处理函数拿到的item.count可能还是上一次setData之前的值导致连点几次后数量超过库存。解决办法是在每次点击时直接基于页面data里最新的值计算并且可以考虑用一个isUpdating锁来防止高频操作。简单场景下基于当前data值计算加库存判断基本够用。3.2 输入框直接修改数量的校验除了加减按钮很多购物车还支持在输入框里直接输入数量。这个功能的坑在于输入过程是连续变化的如果每输入一个数字就重新计算总价并setData页面会频繁刷新性能和体验都很差。我的做法是输入过程中只做数字过滤不计算总价等输入框失焦blur时再做边界校正和统计计算。onCountInput(e) { const { index } e.currentTarget.dataset let value e.detail.value.replace(/\D/g, ) // 只保留数字 if (value ) value 1 this.setData({ [items[${index}].count]: parseInt(value, 10) }) }, onCountBlur(e) { const { index } e.currentTarget.dataset const item this.data.items[index] let finalCount item.count if (isNaN(finalCount) || finalCount 1) finalCount 1 if (finalCount item.stock) { finalCount item.stock wx.showToast({ title: 已达库存上限, icon: none }) } this.setData({ [items[${index}].count]: finalCount }) this.calcTotal() }失焦时校正边界是必须的用户可能输入0、输入负数、输入超过库存的数字甚至删空了。所有这些情况都要被拉回到合法区间内。输入框的type记得用number弹出数字键盘省去一层过滤。3.3 删除商品的两种路径购物车删除商品通常有两条路径单个删除和批量删除。单个删除就是每条商品右侧放一个删除按钮点击后弹确认框确认后删除该项。批量删除通常配合一个管理入口进入管理态后每个商品左侧出现勾选框底部栏变成删除选中商品。不管是哪个路径删除前必须用wx.showModal做二次确认。因为删除是不可逆操作用户误触的代价很高。删除后的处理有三步从items里移除该项、重新计算全选状态、重新计算总价和总数量。如果删的是最后一件商品还需要切换到空购物车状态。deleteItem(e) { const { index } e.currentTarget.dataset wx.showModal({ title: 提示, content: 确定要删除这件商品吗, success: (res) { if (res.confirm) { const items this.data.items items.splice(index, 1) this.setData({ items, hasItems: items.length 0 }) this.updateSelectAllStatus() this.calcTotal() } } }) }批量删除则是对所有selected为true的商品统一过滤掉。这里还有一个产品细节批量删除时如果删除数量较多建议用loading遮罩提示正在删除防止用户重复点击。3.4 关于左滑删除功能的取舍如果产品经理提出要左滑删除我的建议是小项目用按钮删除足够左滑删除用movable-view或swiper-cell实现涉及到手势识别、滑动状态复位、多个组件间的联动开发成本高且部分低端机上的滑动流畅度不理想。如果必须做左滑优先考虑使用现成的UI组件库里的SwipeCell组件不要自己造轮子。这个取舍不是技术不能实现而是投入产出比的问题。4. 总价格和总数量的动态计算4.1 只统计选中商品的累加逻辑底部结算栏只统计被选中的商品这一点想清楚就不会算错。统计函数会遍历items把selected为true的商品的count和price * count分别累加。calcTotal() { const items this.data.items let totalCount 0 let totalCent 0 items.forEach(item { if (item.selected) { totalCount item.count totalCent item.priceCent * item.count } }) this.setData({ totalCount, totalPriceYuan: (totalCent / 100).toFixed(2) }) }注意totalCount和totalCent是本地变量累加完最后再一次性setData。不要在遍历过程中反复setData这是新手最常犯的性能错误。4.2 金额精度用分做计算用元做展示这个点前面已经提过这里再展开说明一下具体做法。商品数据从接口返回时价格就是分后端一般也按分存储前端所有运算都用分。展示到页面上时再除以100并保留两位小数formatPrice(cent) { return (cent / 100).toFixed(2) }这样19.99元在代码里就是1999分1999 x 3 5997分得到59.97元不会有任何浮点误差。相比之下如果直接用19.99 * 3在部分机型上会得到59.969999999999995toFixed虽然能修复展示但中间过程如果参与其他运算误差会继续传播。整分存储是从根源上消掉这个问题。4.3 计算时机与setData的性能优化calcTotal()的调用时机总共有四个单选切换后、全选切换后、数量变化后、删除商品后。我建议把calcTotal和updateSelectAllStatus做成两个独立函数在各自需要的时机分别调用。如果合并成一个函数每次单品选择时只更新选中状态也要重算全选状态逻辑上也没问题但分开更清晰。还有一个性能优化点在计算总价时不需要把items数组整个setData一次。统计结果单独setData就好。如果数量变化时已经用了路径更新items[index].count紧接着再setData一个totalPriceYuan两次setData可以合并成一次减少一次渲染周期this.setData({ [items[${index}].count]: newCount, totalCount: newTotalCount, totalPriceYuan: newTotalPrice })像这种数据都准备好了再一次性提交比让WXML里每处都绑定一个函数去计算要高效得多。我见过有人在WXML里写{{calcPrice(item)}}这种在模板里执行函数的写法每次setData整个页面所有绑定都会重新跑一遍商品稍微多一点就卡。购物车这种高频交互页面统计结果应该预先算好存到data里模板只负责展示。5. 收货地址的接入与管理5.1 用微信原生能力获取收货地址收货地址是整个购物车功能的最后一环。微信小程序获取收货地址最省事的方案是调用wx.chooseAddress()。首次调用时会弹出授权窗口用户同意后会在回调里返回完整的地址信息。chooseAddress() { wx.chooseAddress({ success: (res) { const address { name: res.userName, phone: res.telNumber, province: res.provinceName, city: res.cityName, county: res.countyName, detail: res.detailInfo, fullAddress: ${res.provinceName}${res.cityName}${res.countyName}${res.detailInfo} } // 存到本地并更新页面 wx.setStorageSync(selectedAddress, address) this.setData({ address }) } }) }拿到地址后我通常会做两件事一是把地址整体存到本地缓存这样下次进入购物车页面还能显示上一次选择的地址二是把地址同步到后台方便订单结算时后台直接取用。前端本地缓存只用于页面展示的恢复订单提交时还是要以当次提交的数据为准。5.2 授权被拒绝之后的引导方案wx.chooseAddress有个特点用户第一次拒绝后后续再调用不会重新弹授权框而是直接走fail回调。所以fail分支必须处理否则用户点了地址栏毫无反应体验非常差。我的处理方案是fail里判断错误信息如果涉及授权拒绝弹窗给出提示并引导用户去设置页重新授权。chooseAddress() { wx.chooseAddress({ success: (res) { // 正常处理 }, fail: (err) { if (err.errMsg err.errMsg.indexOf(auth) ! -1) { wx.showModal({ title: 需要授权, content: 获取收货地址需要您的授权是否去设置页开启, confirmText: 去设置, success: (res) { if (res.confirm) { wx.openSetting() } } }) } } }) }这里有一个安卓机上常见的坑用户从设置页重新打开授权后不会自动回到chooseAddress的success回调。需要在wx.openSetting的success回调里再次调用chooseAddress才能引导用户完成地址选择。如果不做这一步用户授权完又要手动点一次地址栏多一个步骤不说很多人会以为功能坏了。5.3 多地址列表与默认地址的联动如果产品要求支持多个收货地址那就需要单独做一个地址列表页。购物车页点击地址栏时跳出当前页面进入地址列表页。地址列表页的功能包括展示地址列表、新增地址、编辑地址、删除地址、设置默认地址。用户在地址列表页选中一个地址后需要把选中的地址带回购物车页。跨页面回传数据我推荐用eventChannel或者wx.setStorageSync。在地址列表页点击确定时把地址对象存到storage然后wx.navigateBack返回购物车页。购物车页在onShow生命周期里从storage读取最新地址并刷新展示。onShow() { const address wx.getStorageSync(selectedAddress) if (address) { this.setData({ address }) } }用onShow而不是onLoad是因为从地址列表返回时购物车页已经在栈里不会重新触发onLoad但一定会触发onShow。这个选择是实战中踩过坑才换过来的。地址列表页中设置默认地址的字段通常是isDefault新增地址时接口会往后台传。如果已经有默认地址第一次进购物车时优先展示默认地址。如果没有地址点击结算时直接跳转到新增地址页面。5.4 结算时地址快照和商品价格快照提交订单时前端传给后台的地址应该是完整的地址快照而不只是一个addressId。因为用户在下单之后可能修改地址信息但订单里的收货地址应该保持下单那一刻的版本。这个原则和前面提到的商品价格快照完全一致。后台应该把提交上来的地址信息连同订单一起存储不能在上游数据变化后反向修改订单里的地址字段。6. 高频问题排查与避坑实录6.1 单品取消后全选框还是全选状态这是购物车页面最经典的状态不同步问题。症状是用户点了全选然后手动取消其中一个商品底栏的全选按钮依然是红色全选样式。原因是单品点击事件里只改了该商品的selected没有重新统计全选状态。解决办法就是前文写的每次单品切换后必须调用updateSelectAllStatus。排查这种问题时建议在开发者工具里用AppData面板实时观察selectAllStatus字段的值。如果视觉和字段值对不上问题多半出在CSS类绑定上如果字段值本身就是错的那就是统计逻辑没执行。6.2 setData全量更新导致低端机卡顿购物车列表如果几十件商品加减数量时全量setData items数组低端安卓机会出现明显的迟滞感。解决的核心思路是小步更新单条数据变化用路径更新items[${index}].count统计结果单独setData尽量一次交互只触发一次渲染周期。数据量再大的项目可以考虑把列表拆分成子组件用组件内部setData隔离渲染范围但这会增加项目复杂度视情况取舍。6.3 价格计算出现一长串小数浮点精度问题在前文已经说过这里补充一个现场案例。某次实测39.9 * 8在某台安卓机上显示为319.20000000000005用toFixed(2)之后显示正常但用户反馈说价格跳动了一下后来排查发现是因为页面同时有两处地方渲染价格一处用了toFixed另一处没有。修复方式是把格式化统一封装成一个filter函数或工具函数所有价格展示都走同一个格式化入口不要有的地方格式化有的地方不格式化。6.4 用户从设置页返回后授权状态不更新这是一个偶发但很恶心的坑用户拒绝了地址授权弹窗引导去设置页重新开启授权用户照做了返回购物车页后再次点击地址栏却发现什么都没发生。原因就是前面提到的wx.openSetting返回后系统并不会有任何事件通知页面重新执行chooseAddress。正确的写法是在wx.openSetting的success回调里再次调用一次wx.chooseAddress把授权后的流程直接续上。6.5 商品删完时底部结算栏还亮着删除最后一个商品后items数组为空但底部结算栏还在结算按钮还能点点了之后弹出请选择商品的提示。虽然不算功能错误但体验很差。处理方式很直接删除后判断items.length为0时设置hasItems: falseWXML里用wx:if切换空状态图同时隐藏底部的全选和结算栏。空状态图建议提供去逛逛按钮跳转首页给用户一条回流路径。6.6 一个值得养成的代码习惯购物车页面涉及的交互函数很多我习惯把所有功能相关的事件处理函数按模块分组注释比如// 选中状态 toggleSelect() {} toggleSelectAll() {} updateSelectAllStatus() {} // 数量与删除 changeCount() {} onCountInput() {} onCountBlur() {} deleteItem() {} // 统计与结算 calcTotal() {} chooseAddress() {} goCheckout() {}页面逻辑一旦超过两三百行分组注释能显著降低维护成本。等到后面要加优惠券、加赠品、加凑单模块时这个习惯的价值会体现得更明显。说实话购物车页面的核心难点从来不是某个单独功能写不出来而是所有功能共享同一份数据时如何保证状态一致性。全选状态、选中商品的勾选状态、底部统计的金额数量三者必须像齿轮一样咬合。我实际开发中所有出过的bug几乎都出现在这三个齿轮不同步的时刻。所以写代码时养成一个习惯每次交互改完数据后花一秒钟想一想这次改动影响到了哪几个派生状态把所有需要更新的状态一次性更新掉不要只改眼前可见的那部分。这个思路不只适用于购物车商品列表多选、订单批量操作、优惠券选择器本质都是同一个模型把这个习惯带过去一套逻辑到处能复用。
