★ FEATURED ARTICLE 最近把一个基于 Vue3 的网上商城会员积分购物系统从前到后完整捋了一遍。这个项目不算大但麻雀虽小五脏俱全商品展示、积分赚取、积分抵扣、订单结算、会员等级、后台管理全占了。做完之后最大的感受是Vue3 这套组合拳Vite Pinia Composition API确实比 Vue2 时代顺手太多但前提是得先把业务模型想清楚不然代码写得再花哨也是白搭。这篇文章就把整个项目的设计思路、关键实现和踩坑记录完整分享出来给想做商城类项目、或者正在从 Vue2 迁移到 Vue3 的朋友一个参考。1. 项目定位与整体设计思路1.1 会员积分商城到底在做一件什么事会员积分商城本质上是一个“激励闭环”用户通过注册、签到、消费、参加活动获得积分积分可以在商城内兑换商品、抵扣现金、换取优惠券用户为了更多收益持续活跃、持续消费。从产品运营的角度看积分不只是一个数字字段而是整个用户成长体系的载体。落到技术实现上这套系统拆开就是两大块用户侧C端商城首页、商品列表、商品详情、购物车、订单结算、订单列表、个人中心积分明细、会员等级、收货地址。管理侧B端后台商品管理、订单管理、会员管理、积分规则配置、Banner与公告内容管理。很多人容易把积分当成普通字段存着、展示一下就行但真正把它做成一个交易系统时要考虑积分是否有有效期、积分抵扣上限、积分与现金的比例关系、退单时积分怎么退、积分获取是否实时到账等一堆边界问题。这个项目从一开始就把这些规则和数据模型定清楚前端开发反而顺畅没有出现“页面做完了又推翻重做”的情况。1.2 技术选型为什么最终落到了 Vue3 上选型时我对比过 Vue2、Vue3 和 React 三条路线。用 Vue3 有几个非常实际的考量Composition API 在复杂页面上比 Option API 有条理。散落在多个页面间的积分逻辑可以抽成独立的组合式函数比如usePoints()、useCart()每个人只看自己那部分代码不会像 Vue2 的 mixin 一样变量来源不明。Pinia 的状态管理比 Vuex 轻量很多。Vuex 的 mutations 在写购物车、用户信息这类场景时显得累赘。Pinia 直接改 state天然支持 TypeScript 类型推导。商城的心跳业务就是状态——购物车数量、积分余额、登录态用 Pinia 管理起来非常顺手。Vite 的开发体验全面优于 Vue CLI。商城项目页面多尤其是管理后台几十个路由页面时热更新速度直接决定开发效率。Vite 冷启动秒开、HMR 快这套体验用了就回不去。当然 Vue3 也不是没有代价。生态迁移时一些老的组件库版本、PDF 预览、地图打点类第三方库在初期会碰到兼容问题后面我会专门聊迁移和踩坑。1.3 功能模块与前端工程目录以终为始先看最终定下来的目录结构。src/ ├── api/ # 接口请求模块 │ ├── product.js │ ├── cart.js │ ├── points.js │ └── order.js ├── assets/ ├── components/ │ ├── common/ # 通用组件 │ └── business/ # 业务组件 ├── composables/ # 组合式函数 │ ├── usePoints.js │ └── useCart.js ├── router/ ├── stores/ # Pinia │ ├── user.js │ ├── cart.js │ └── points.js ├── views/ │ ├── home/ │ ├── product/ │ ├── cart/ │ ├── order/ │ └── user/ └── utils/这个结构最大的好处是按业务领域组织不是按文件类型堆叠。商城页面跳转链路是首页 → 商品 → 购物车 → 订单 → 个人中心对应 views 下的五个业务目录composables 专门放跨页面的逻辑复用stores 放全局状态。刚开始做商城最容易犯的错是把所有逻辑全塞进组件等到订单页要同时读购物车、积分、用户三块状态时就开始头晕。所以目录规范这种事越早定越好。2. 积分体系与数据模型设计2.1 积分赚取规则的参数设计积分系统的第一个坑就是规则没定清楚前端做得再好都是空中楼阁。开发前必须把积分来源和消耗口径跟运营对齐。以本项目为例积分来源分四类来源规则结算时机状态每日签到每日 5 积分签到完成立即入账实时到账下单消费每消费 1 元 1 积分订单确认收货后延迟到账邀请注册邀请 1 人 50 积分新用户完成首单后审核入账活动奖励按活动配置运营手动发放手动入账消费类积分为什么延迟到账因为这涉及到退款。如果用户下单就送积分退款时积分的追回会非常麻烦体验也差。延迟到确认收货就会好很多退款单不产生积分。这是个很小的产品决策但对整个积分流水的一致性影响巨大。计算过程举个例子一件商品单价 299 元用户使用了一张 20 元优惠券订单实付金额为 279 元。按“积分 实付金额向下取整”的规则这笔订单的积分为 279 积分。如果订单里有运费 10 元还要看运营规则——积分计算基数到底按“商品金额”“实付金额”还是“实付金额减运费”必须一开始就定死否则财务对账要爆炸。我采用的是“实付金额减运费后向下取整”理由是运费属于服务成本不该进入积分刺激范围。2.2 会员等级与积分抵扣的边界规则会员等级我这边用成长值来衡量不是直接用积分余额。成长值通过每年累计获得的积分总额累积等级区间如下Lv1 普通会员0 成长值积分兑换费率为 100%Lv2 银卡会员1000 成长值积分兑换费率为 95%Lv3 金卡会员3000 成长值积分兑换费率为 90%Lv4 钻石会员8000 成长值积分兑换费率为 85%积分抵扣规则兑换比例100 积分 1 元单笔订单最多抵扣实付金额的 20%运费不可抵扣抵扣后的实付金额不得低于 0.01 元前端需要这些数字吗需要。虽然规则在后端也会校验但用户在下单页必须实时算出“本单可用积分上限”和“抵扣后的应付金额”这部分逻辑放在usePoints.js里不然每次点击输入框都要等接口返回体验极差。用数字走一遍金卡用户下单商品金额 500 元运费 10 元用户当前有 42000 积分。可抵扣金额 min(42000 × 0.9 / 100, 500 × 20%) min(378, 100) 100 元实际消耗积分 10000。前端秒算这个结果跟后端接口校验保持一致。2.3 前端状态管理与接口约定商城前端的状态非常集中token、用户信息、购物车数量、积分余额、全局弹窗。用 Pinia 拆成三个 store各管一摊。// stores/points.js import { defineStore } from pinia export const usePointsStore defineStore(points, { state: () ({ balance: 0, todayEarned: 0, records: [], loading: false, }), getters: { // 根据积分余额计算当前等级可用的抵扣费率 exchangeRate: (state) { if (state.balance 3000) return 0.85 if (state.balance 1000) return 0.9 if (state.balance 500) return 0.95 return 1 }, }, actions: { async fetchBalance() { const res await getPointsBalance() this.balance res.data.balance }, async refreshRecords() { this.loading true try { const res await getPointsRecords({ page: 1, pageSize: 20 }) this.records res.data.list } finally { this.loading false } }, }, })这里有个经验getters 里可以放业务判断但只适合“前端展示逻辑”。真正的金额计算还是要在组合式函数里做因为订单结算牵扯多个 store跨 store 的逻辑不塞进单个 store 内部更合适。接口约定方面统一用 RESTful 固定返回结构{ code: 0, message: success, data: {} }code 为 0 表示成功非 0 按业务错误处理。前端 axios 拦截器统一处理 code ! 0 的情况弹出错误提示并记录日志。后端接口按资源划分/api/products、/api/cart、/api/points、/api/orders每个资源有一套 get/list/update 的约定。前后端字段名统一用驼峰前端不用再做一层字段映射省掉大量无效沟通。3. 核心功能实现与实操细节3.1 商品列表与购物车的状态同步商品列表页最常见的操作是“加入购物车”但这个行为在 H5、App 和小程序里往往不一样H5 用户经常加入后直接跳去购物车结算App 里可能加入后停留在当前页继续逛。我这里采用的是“浮层提示 购物车图标角标更新”的方式核心逻辑就是购物车 store 的 addToCart 动作。// stores/cart.js import { defineStore } from pinia export const useCartStore defineStore(cart, { state: () ({ items: [], totalCount: 0, }), actions: { async addToCart(product, quantity 1) { // 乐观更新先把本地数量加上接口失败再回滚 const existed this.items.find(item item.skuId product.skuId) if (existed) { existed.quantity quantity } else { this.items.push({ ...product, quantity }) } this.totalCount this.items.reduce((sum, item) sum item.quantity, 0) try { await addItemToCart({ skuId: product.skuId, quantity }) } catch (e) { if (existed) { existed.quantity - quantity } else { this.items this.items.filter(item item.skuId ! product.skuId) } throw new Error(加入购物车失败) } }, }, })乐观更新的好处是快用户点击几乎立刻看到响应不用等 loading。坏处是接口失败时要做回滚。这个模式适合“加入购物车”这种低风险操作不适合“提交订单”这种强一致场景。提交订单时要严格遵守先调接口、成功后跳转、失败就留在当前页并展示原因。购物车数据只存在 Pinia 里刷新页面就丢了这不合理。我做了统一持久化在 store 初始化后把 cart store 的 items 同步写入 localStorage刷新页面时先用本地数据渲染再调接口拿到服务端数据覆盖。这样既保证首屏快又保证数据最终一致。3.2 结算流程中的积分抵扣逻辑结算页是这个系统的重头戏。场景是用户从购物车进入结算页左侧是收货地址中间是商品清单右侧是价格明细和积分抵扣入口。页面需要实时显示多个金额商品总额、运费、优惠券抵扣、积分抵扣、应付总额。前端实现思路从路由参数读取要结算的商品 SKU 列表并行请求地址列表接口 积分余额接口用户勾选“使用积分”复选框后调用封装好的usePoints.js里的calcSettlement方法。// composables/usePoints.js export function usePoints() { const userStore useUserStore() function calcSettlement({ goodsAmount, shippingFee, couponAmount, usePointsFlag }) { // 基础应付 商品金额 - 优惠券 const baseAmount Math.max(goodsAmount - couponAmount, 0) // 最高可抵扣金额 min(积分按比例折算的金额, 基础应付的20%) const maxDiscountAmount Math.min( Math.floor(userStore.points / 100), Math.floor(baseAmount * 0.2) ) const pointsDiscount usePointsFlag ? maxDiscountAmount : 0 const finalAmount baseAmount shippingFee - pointsDiscount return { baseAmount, maxDiscountAmount, pointsDiscount, finalAmount: Math.max(finalAmount, 0.01), } } return { calcSettlement } }注意几个细节积分折算时要分两步向下取整先换算成金额除以 100 再取整再跟 20% 的比例取 min。不能先算比例再折算否则会出现抵扣金额带一串小数的问题。运费不参与抵扣所以最终金额 商品基础应付 运费 - 积分抵扣。最后用Math.max(finalAmount, 0.01)兜底防止出现 0 元订单。这个规则在很多电商平台是硬性要求。后端在提交订单时同样会校验这套规则。两边逻辑保持一致是开发规范最好把共享的计算逻辑写成一份文档前端实现和后端实现都对照这份描述来写避免出现“前端能抵扣、后端报错”的尴尬。3.3 动态表单收货地址与订单备注用户中心里有“新增收货地址”功能这个页面在 Vue3 里用动态表单做很顺。地址表单里“省份、城市、区县”三个下拉框是级联关系这里踩过一个坑如果用三个独立的 select每选一个都要手动清空下级选项逻辑冗余还容易出错。后来改成 Element Plus 的 Cascader 组件一次绑定数组值代码量直接砍掉一半。动态表单最常见的坑是校验规则不生效。Element Plus 的 Form 组件里动态 row 的 prop 要带上索引例如propremarks.${index}.content。如果表单数据是用 Vue3 的ref管理数组更新时要用splice、push这类能触发响应式依赖收集的方法。最稳的写法是用reactive包裹整个 form 对象然后直接通过form.remarks[index].content去更新视图响应完全不用担心。再提一个校验问题预约配送时间的日期选择。我直接用el-date-picker的disabledDate禁止过去日期再加 rules 里的 validator 做二次判断。日期校验别自己写正则去解析字符串用 dayjs 比较比正则靠谱一万倍尤其涉及到时区、跨月和闰年时。3.4 登录态、路由守卫与 Token 失效处理商城做登录态管理核心就三件事未登录用户访问需要登录的页面时跳登录页登录成功后带着 redirect 参数回到原页面token 失效后不能只弹登录框要保留用户当前填写的表单数据。路由守卫统一写在全局 beforeEach 里。购物车、订单列表、积分明细要求登录首页、商品列表、商品详情对外开放。// router/index.js const whiteList [/login, /register, /home, /product, /productDetail] router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (token) { if (to.path /login) { next(/home) } else { next() } } else { if (whiteList.includes(to.path)) { next() } else { next(/login?redirect${encodeURIComponent(to.fullPath)}) } } })token 失效的处理方式我踩过一个大坑axios 响应拦截器里发现 401直接跳转登录页并清空 localStorage。乍一看没问题可用户如果在结算页填了一半信息跳去登录再回来信息全没了非常恼火。后面的方案改成拦截到 401 后如果本地有登录记录先把当前页面路由和表单数据存到 sessionStorage再跳登录页登录成功后从 sessionStorage 取出继续渲染。这个逻辑不复杂但对用户体验影响巨大不少商城项目恰恰忽略了这一步。4. 性能优化与工程化实践4.1 首屏加载优化路由懒加载与按需引入商城的首页图片多、商品接口慢首屏加载不好用户流失率很高。Vue3 Vite 项目做了几件事之后首屏加载时间从原来的 6.8 秒降到了 2.5 秒左右用 Chrome 的 Lighthouse 或 Network 面板的耗时数据能看到明显变化。第一件事是路由懒加载。views 下每个页面单独打包访问时才加载对应 chunk。第二件事是组件库按需引入。Element Plus 全量引入的编译产物大得吓人。用unplugin-vue-components和unplugin-auto-import这两个插件配合 Element Plus 的 resolver可以做到组件和 API 按需引入还能自动导入 ElMessage 这类命令式组件。按需引入之后打包产物从原来的 1.3MB 降到 600KB 左右光 CSS 就少了将近一半。具体做法是在 vite.config.js 里引入这两个插件传入ElementPlusResolver()再把 auto import 的 imports 数组选上 vue 和 pinia 的常用 API这样开发时不需要手动 import ref、computed代码也清爽不少。第三件事是图片懒加载。商品列表图片特别多首页如果一次性渲染几十张 700KB 的图片页面性能立刻崩。有两种做法用组件库的懒加载指令或者自己写一个 IntersectionObserver 指令。// directives/lazyLoad.js const lazyLoad { mounted(el, binding) { const observer new IntersectionObserver((entries) { if (entries[0].isIntersecting) { el.src binding.value observer.unobserve(el) } }) observer.observe(el) }, }只监听进入视口的图片节点进入视口后再赋真正的 src。这个方案在移动端商品列表上尤其明显滚动时卡顿感会大幅减轻。4.2 接口层面的防抖与缓存商城里商品详情接口可能被反复请求用户进详情页、从购物车再进详情、切换不同 SKU。每次都请求太浪费了。我做了两层优化内存缓存用 Map 存商品 ID 到数据的映射缓存时间 10 分钟。请求级缓存同一商品 5 秒内的重复请求直接复用上一次的 Promise避免并发触发两个相同的请求。不展开太多代码但这个思路对所有详情类接口都通用。商城首页滚动加载列表时用户在列表和详情间来回切换加了这层缓存之后线上接口压力明显下降。4.3 Vue2 迁移 Vue3 的注意点现在不少成熟项目还躺在 Vue2 上但新项目直接上 Vue3 会更省心。这里总结几个最容易踩的点v-model 行为变了。Vue2 的 v-model 默认使用 value input 事件Vue3 改成了 modelValue update:modelValue。写自定义组件时如果沿用 Vue2 的命名父组件的 v-model 会完全不生效。filters 被移除了。Vue2 的过滤器在 Vue3 里不能继续用建议用 computed 或组合式函数替换。响应式代理方式不同。Vue3 用 Proxy 实现响应式数组下标赋值、新增属性这些 Vue2 的响应式坑都不存在了。但要注意如果用 reactive 包裹对象解构对象出去后会丢失响应式必须用 toRefs 或统一通过 store 访问。TypeScript 严格模式下的类型报错。后台管理系统如果用 TS 重构最常遇到的就是事件类型、props 类型、接口返回类型不匹配。建议在项目初期就把 tsconfig 的 strict 打开越早处理越省事否则中期再改报错能淹没整个控制台。5. 常见问题排查实录5.1 高频 Bug 排查表格现象大概率原因处理办法页面刷新后购物车数量清零购物车数据没有持久化监听 store 变化同步写入 localStorageElement Plus 弹窗打开两次组件被全量引入 按需引入重复注册检查 main.js 是否有重复 installVue3 项目在 Edge 浏览器下某些弹层无法正常关闭浏览器版本较老对组件库事件绑定存在兼容问题升级浏览器版本或改用手动控制 visible 状态表单 on-success 事件没有触发自定义表单组件没有正确传递 validate 结果检查组件内是否调用了 form 的 validate 并派发事件首屏打包 chunk 过大路由懒加载没配置第三方库全打在同一个包里在 vite.config 里配置 manualChunks 手动拆分5.2 关键经验与避坑清单做完这个项目我最大的几个体会按价值排序第一数据模型永远优先于页面设计。积分商城最复杂的不是 Vue3 代码而是积分规则。我在动工前先花了整整一天和运营确认积分的细节问题比如退货是否退积分、过期积分要不要提醒、优惠券和积分能不能共用。这些问题没想清楚前端做完必然要大改。第二前后端约定要落到文档。项目里我维护了一份 api.md把每个接口的入参、返参、错误码列得明明白白前后端联调几乎零返工。别轻视这一步它能减少大半无谓的沟通成本尤其当后端和前端不是同一个人开发时。第三先做核心链路再做花哨功能。积分商城只要把商品列表、购物车、结算、积分明细这四个页面做扎实基础就稳了。搜索推荐、个性化皮肤这些都往后放。一开始就把精力耗在非核心功能上结果真正要上线时发现订单闭环都没跑通那才是灾难。我个人在实际操作中的体会是Vue3 给我的最大自由是组合式函数把积分计算、购物车同步这些逻辑从组件里抽了出去代码变得可测试、可维护。如果你也在做类似的商城项目我的建议很简单动手前把积分规则写在纸上动手时坚持组件写薄、逻辑写给 composables 和 stores动手后认真过几遍接口返回的边界情况。做到这三点这套 Vue3 商城跑起来会很顺后面加新功能也不用提心吊胆。
阅读完成 · 觉得有帮助？
