前后端分离的商城项目一直是很多开发者的练手首选。最近总有人问我Node.js和Vue到底能不能撑起一个包含积分兑换的超市在线购物商城答案当然是能。我利用周末时间把一个带商品、购物车、订单、模拟支付和积分兑换的完整系统从头到尾撸了一遍把开发里真正会踩的坑都记了下来。这篇内容适合准备做毕设、想学前后端分离、或者想接一个小外包单的人看。你会弄明白这套系统的功能边界、为什么选这套技术栈、积分兑换要怎么做才不容易出bug以及在Windows环境上配置Node.js和Vue项目时那些最常见的翻车现场怎么处理。1. 项目拆解先搞清楚这套系统到底要做什么1.1 从“销售系统”到“积分兑换”功能清单怎么定任何一个项目动手写代码前我都会先把需求掰开揉碎。标题里“超市在线购物商城销售系统积分兑换”这串字其实包含了三类核心业务缺一个这项目都不完整。第一类是商品域。超市商品有分类、品牌、规格、单位、库存线上商城要展示商品列表、详情、价格、库存状态。后台还要能上架、下架、改价、调整库存。第二类是交易域购物车、下单、订单列表、订单详情、支付以及订单状态流转比如待支付、已支付、待发货、已完成、已取消。第三类就是会员与积分用户注册、登录、积分获取例如注册送积分、消费1元送多少积分积分抵扣现金积分单独兑换商品。如果这是一个真实超市项目可能还要对接线下会员卡、收银系统、营销活动甚至要考虑超市的区域配送、生鲜冷链。但作为一个以Node.jsVue为核心的技术项目我们先把范围控制在线上购物和积分闭环上。把这三个域跑通了再往“多商户”“配送”“促销活动”方向扩展也不迟。1.2 为什么选Node.jsVue而不是Java全家桶很多人在选型时会先闪过Spring Boot但就这个项目而言Node.js和Vue的组合优势非常明显。第一语言统一。前端用JavaScript后端也用JavaScript不会出现“前端写Vue、后端写Java两边对接口还要互相理解对方语言”的割裂感。像日期格式化、金额计算、参数校验这类工具函数前后端可以共用一套思路。第二开发效率高。用Express或者NestJS搭接口非常快。配合Sequelize这个ORMMySQL里的十几张业务表两三天就能完成映射和基础CRUD。相比之下Spring Boot光初始化项目和配置依赖就要花不少时间。第三系统压力匹配。商城的读写模型是典型的I/O密集型浏览商品、查库存、刷积分明细这类操作占大头Node.js基于事件循环处理高并发读的能力并不差。即使未来要做秒杀这种高并发场景也能通过Redis、消息队列和后端缓存扛住。真正需要大量CPU计算的场景比如报表统计、数字签名在中小型超市系统里其实很少。当然如果团队里有Java背景的老手选Spring Boot也没问题。但对于个人开发者、学生或者小团队来说Node.jsVue的性价比最高联调成本也低。我在实际开发中还有一个私心Vue的组件化非常成熟商品卡片、订单步骤条、积分兑换弹窗都有现成的组件能改开发速度特别快。1.3 系统的整体架构与数据流向整体架构一句话总结前端用Vue负责展示和交互后端用Node.js提供REST API数据库使用MySQL保存业务数据Redis做缓存和临时状态存储。详细一点前端请求流程是这样用户打开商城首页Vue组件通过axios请求Node.js写的/api/product/list接口后端从MySQL查出商品分类和商品列表返回JSON前端渲染。用户点击立即购买进入购物车或结算页提交订单时后端在数据库事务里同时完成“创建订单、扣减库存、生成积分明细”等一系列操作。支付环节我用了模拟支付也可以对接沙箱支付成功回调后触发积分赠送。这里面有一个关键点前后端严格分离。前端只依赖后端接口不关心数据库表结构后端不关心页面长什么样只管业务逻辑和返回数据。这种模式的好处是以后前端要换小程序、App后端接口完全不需要改只要加一层适配就行。1.4 哪些需求最容易在开发中被忽略项目开发过程中很多看起来简单、实则很坑的需求经常被漏掉。第一个就是积分有效期。如果你不设计“过期”概念用户账户里的积分会越积越多财务对不上账运营也没法做清零活动。第二个是积分流水。只要用户的积分有变动就必须有一条流水记录不能只改用户表里的points字段否则用户投诉积分丢失时你根本不知道从哪里查。第三个是订单超时自动取消。下单后未支付库存得释放不然购物车里的商品永远显示“有库存”实际却买不到。第四个是并发超卖。尤其在积分兑换这种限时、限量场景里两个用户同时兑换最后一件商品系统不能两个都成功。这些问题如果前期想清楚后面能少加无数次班。2. 核心功能落地积分兑换模块的设计与实现2.1 积分数据模型积分不能只存在一个数字里我见过很多半成品项目积分就放在用户表的一个points字段里前端显示用户积分就是p.points。这种做法在demo里没问题但一上线就是灾难。用户会问“我昨天还有积分今天怎么少了”没有流水、没有过期时间、没有备注你根本没法回答。我建议至少拆三张表。用户表保留当前可用积分和累计获得积分两个冗余字段方便展示。积分明细表points_log记录每笔变动的来源、时间、关联订单。积分商品表负责兑换类商品的基础配置比如需要多少积分、是否支持积分现金混合支付、每人限购几件。积分明细表要重点关注。change_value正数表示获得积分负数表示消耗积分。source_type要区分注册赠送、购物赠送、签到赠送、兑换消耗、抵扣消耗、后台调整、过期扣除。ref_order_id与订单号关联方便溯源。create_time是业务发生时间expire_time是积分过期时间。这套设计虽然刚开始多写了一些CRUD但后面做得越多你会越感谢当时的设计。商品表设计时积分兑换商品可以复用商品主表也可以单独拆一张积分商品表。我倾向于复用商品主表增加exchangeable和requiredPoints字段这样可以沿用商品图片、描述、分类这些已有能力。但兑换库存不要和普通库存混在一起我建议单独设一个字段或者单独建兑换库存表因为运营通常会对兑换商品限量和现金销售的库存逻辑不一样。2.2 积分抵扣与独立兑换两条业务线分开处理积分在超市商城里有两种典型玩法实现起来要分别设计。第一种是下单抵扣。用户在结算页可以勾选“使用积分抵扣”系统按规则把积分换算成金额比如100积分抵1元最多抵扣订单总金额的10%。订单创建时除了记录商品金额、运费、实付金额还要记录积分抵扣金额和消耗的积分数量。整个操作必须在同一个事务里完成订单提交成功积分立即扣减明细表同时插入支出记录订单取消积分原路退回再补一条收入记录。第二种是积分商城里的独立兑换。商品不花钱直接用积分换比如某个保温杯需要2000积分。这种商品在商品表里加一个exchangeable字段设置为true即可。兑换库存要单独列出来因为兑换商品往往不参与现金销售库存的统一管理数量是运营单独设置的。兑换接口要做三件事查用户积分是否足够、查兑换库存是否足够、然后在事务中同时扣减积分和兑换库存。只要其中一个条件不满足整个请求就返回失败不允许部分成功。下面是一段兑换接口的示意代码事务和锁都在里面async function exchangeProduct(userId, productId) { const product await Product.findOne({ where: { id: productId, exchangeable: true } }); if (!product || product.requiredPoints 0) { throw new BusinessError(兑换商品不存在); } const user await User.findByPk(userId); if (user.points product.requiredPoints) { throw new BusinessError(积分不足); } await ExchangeStock.lockRow(product.id); // 锁兑换库存行 const remainStock await ExchangeStock.getStock(product.id); if (remainStock 1) { throw new BusinessError(兑换库存不足); } await sequelize.transaction(async (t) { await User.decrement(points, { by: product.requiredPoints, transaction: t }); await PointsLog.create({ user_id: userId, change_value: -product.requiredPoints, source_type: EXCHANGE, ref_order_id: orderId, transaction: t }); await ExchangeOrder.create({ userId, productId, points: product.requiredPoints, status: PROCESSING, transaction: t }); await ExchangeStock.decrementStock(product.id, 1, t); }); }这里提醒一句使用Sequelize时事务里的查询与写入一定要传入transaction: t否则可能会出现查询不加锁、写操作在事务外提交的诡异问题。我自己就踩过这个坑排查了很久才发现某个update语句漏了transaction参数。2.3 积分有效期和定时清理任务积分不是永久有效的一般运营会设置“当年积分次年年底作废”或“积分自获取起12个月有效”。在points_log表里增加expire_time字段后就需要一个定时任务扫描。我用的是node-cron在服务启动时注册一个每天凌晨2点执行的任务。逻辑分为两步第一步查出所有已过期但未处理的积分流水第二步为每个积分的用户生成一条“过期扣除”的流水并把用户可用积分减少。如果某用户有多个过期流水可以先汇总再一次性调整用户积分减少数据库写压力。cron.schedule(0 2 * * *, async () { const expiredLogs await PointsLog.findAll({ where: { expire_time: { [Op.lt]: new Date() }, status: VALID } }); // 按用户汇总生成扣减流水并更新用户积分 await sequelize.transaction(async (t) { for (const log of expiredLogs) { await User.decrement(points, { by: log.change_value, transaction: t }); await PointsLog.create({ user_id: log.user_id, change_value: -log.change_value, source_type: EXPIRE, ref_order_id: null, transaction: t }); await log.update({ status: EXPIRED }, { transaction: t }); } }); });这里还有一个小优化不要一个过期流水就创建一条扣减流水可以先按user_id和过期日期分组汇总后再批量处理。否则每天凌晨数据库会有大量插入影响性能。如果积分体量很大建议加一个“已处理”标记避免任务重复执行导致重复扣减。2.4 并发场景下防止积分“超扣”积分系统的并发问题一般出现在热门兑换商品上比如积分商城凌晨12点上新很多人同时抢兑。只靠“先查询用户积分、再判定、再扣减”的流程一定会出现超扣因为两个请求可能同时查到积分足够然后同时执行扣减。解决办法最直接的是在事务里对用户行加悲观锁。先SELECT用户记录使用数据库的FOR UPDATE锁住该行然后再判断积分并扣减。MySQL InnoDB支持行锁这样第二个请求会等第一个请求完成事务后才继续从而避免超扣。await sequelize.transaction(async (t) { const user await User.findOne({ where: { id: userId }, lock: t.LOCK.UPDATE, transaction: t }); if (user.points product.requiredPoints) { throw new BusinessError(积分不足); } await user.update({ points: user.points - product.requiredPoints }, { transaction: t }); // 插入流水、创建兑换订单... });如果量再大一些可以引入Redis缓存积分在应用层做一个原子扣减脚本类似库存扣减的处理。但对中小型商城来说数据库行锁已经完全够用没必要一开始就把系统搞复杂。3. 动手实操从Node.js环境到Vue前端联调3.1 Node.js安装与环境变量配置我看到热词里一半人都在搜“nodejs安装及环境配置”说明环境这关就把不少人挡在门外了。Windows上安装其实很简单去Node.js官网下载LTS版本比如现在的20.x安装包一路Next记得勾选“Add to PATH”。装完打开一个新的命令行窗口输入node -v和npm -v能出版本号就说明核心环境OK。如果输入npm -v报错报“npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本”这多数是PowerShell执行策略限制。打开PowerShell管理员先执行Get-ExecutionPolicy看看当前策略如果是Restricted就改成RemoteSignedSet-ExecutionPolicy RemoteSigned改完再试一次。注意这只影响PowerShellCMD里一般不会遇到这个问题。如果改完还是不行检查系统环境变量Path确认有nodejs安装目录。安装目录没有出现在Path里npm肯定找不到不要急着重装。另外安装Node.js时如果你不小心装了非LTS版本版本太新可能出现某些依赖不兼容。遇到这种情况建议去官网下载LTS版本重新安装或者用nvm-windows管理多个版本。我自己开发时习惯用LTS稳定第一。3.2 npm安装依赖失败怎么办安装依赖失败我遇到最多的原因是网络问题。清理npm缓存是一个基础操作npm cache clean --force然后可以设置镜像源比如国内常用的npmmirrornpm config set registry https://registry.npmmirror.com设置后可以用npm config get registry验证。有一点建议不要动不动就改全局配置我更喜欢在项目根目录创建一个.npmrc内容只写registryhttps://registry.npmmirror.com这样只对这个项目生效不会影响其他项目。如果node_modules已经乱了直接删掉重复npm install比在npm里反复找灵异问题效率高rm -rf node_modules package-lock.json npm installnpm有时候会出现elifecycle错误多数是依赖包版本冲突或node-gyp编译失败。可以先看错误日志如果是node-gyp需要安装Windows Build Tools或者把对应的依赖包换成纯JS实现。别总想着硬扛很多原生模块的安装问题其实是环境缺编译器。3.3 Vue项目初始化与开发工具现在创建Vue项目推荐Vite。你可以在终端执行npm create vitelatest vue-supermarket -- --template vue生成后npm install再npm run dev就能启动。项目里我习惯立刻安装vue-router、pinia、axios、element-plus。element-plus是UI库做商城后台和前台页面都很方便。前端路由采用懒加载const Home () import(/views/Home.vue);积分兑换页、购物车、订单详情等页面都走懒加载。首屏不需要一次性加载全部页面体验会好很多。如果要做权限登录后再用router.addRoute动态添加路由。热词里有人在搜“vue动态路由”这里简单说下思路登录成功后后端返回当前用户可访问的菜单列表前端根据菜单列表匹配对应的组件然后逐一addRoute。这样可以避免把后台管理路由直接写在静态路由表里普通用户即使知道路径也打不开。我个人还建议把axios封装一下统一处理请求头、错误提示、401跳转。比如在拦截器里把token加到Authorization头响应里统一解包业务码。这样业务页面里不用每个地方都写错误处理代码。3.4 前后端跨域问题和Vite代理本地开发时Vite默认跑到5173端口后端Node.js在3000端口前端页面直接请求/api接口必然跨域。最简单的做法是在vite.config.js里配置代理server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } }这样前端请求“/api/user/login”Vite开发服务器会自动转发到“http://localhost:3000/api/user/login”。注意changeOrigin要设为true后端才能拿到正确的Host头。生产环境则用Nginx做反向代理后面部署部分再说。如果你在后端用Express也可以安装cors中间件解决本地跨域npm install corsconst cors require(cors); app.use(cors());但我更推荐前端代理方案因为生产环境始终会有Nginx统一在代理层处理更干净。3.5 Vue Devtools和调试工具调试Vue项目浏览器里装一个Vue Devtools能省很多事。装完没反应先看插件设置确保“允许访问文件网址”勾上了。如果项目用了PiniaDevtools可以直接查看store里的状态排查积分余额、购物车数量更新不及时的问题很方便。还有一个常见场景修改了组件里的数组或对象后页面不变极大概率是直接改了props或者对响应式数据使用了数组下标赋值。遇到这种问题先在Devtools里看看数据是否真的变了变但页面没变再从Vue的响应式原理上查。个人经验项目调试别只在console里打log把有可能出问题的接口响应、关键状态变更都集中到一个统一日志里开发阶段真的能省时间。比如积分扣减前后都把用户积分和请求体打出来一眼就能看出问题在哪。4. 商城关键业务的开发顺序与状态管理4.1 推荐的开发顺序我刚做这套系统的时候先把积分兑换放在最前面写结果调试麻烦因为连登录和商品都没有。经验教训是按业务流程推进不要跳。我的开发顺序是商品模块列表、详情、分类。用户模块注册、登录、JWT鉴权。购物车模块添加、修改数量、删除、结算计算。订单模块提交订单、订单列表、订单详情。支付模块余额支付或沙箱支付、回调处理。积分模块获取积分、消费积分、积分明细。积分兑换兑换商城、兑换下单、独立库存扣减。管理端商品管理、订单管理、积分规则配置。这个顺序的好处是每个阶段结束系统都能跑通一点尤其第四步完成之后你会发现“商品到订单”的核心链路已经打通后面加的积分、兑换都是在这个地基上扩展。如果一开始就写积分兑换你连订单状态机都没有兑换单放不进去白搭。4.2 订单状态机设计订单系统如果只用status字段存数字一旦业务变得复杂比如用户申请退款、后台发货、快递签收程序会乱成一团。提前把状态机画清楚后面写判断逻辑会快很多。我的订单状态用数字表示状态值名称操作0待支付用户支付或取消1已支付/待发货后台发货2已发货用户确认收货或后台确认3已完成无更多操作4已取消无更多操作5退款中后台处理退款6已退款结束除了状态字段我把状态变更过程记录到order_status_log表任何时候用户在前端看到的“订单轨迹”都能从这里取。从业务侧看这也是维权和客服排查的依据。状态变更时尽量用一个统一的方法比如updateOrderStatus(orderId, fromStatus, toStatus, remark)方便埋点和审计。4.3 下单时的库存处理超卖是怎么出现的库存扣减是商城项目的高危操作。新手最容易写这样的代码先select stock判断大于0再update stock减一。在高并发下两个请求可能同时读到stock1同时通过判断最后都执行update库存变-1超卖就这么出现了。正确做法是让“判断库存”和“扣减库存”在一个原子操作中完成。比如UPDATE product SET stock stock - 1 WHERE id ? AND stock 0这条语句只有当库存大于0时才会把库存减下去。如果affected rows等于0说明库存不足订单应该返回失败。在Sequelize里写原生SQL或使用increment配合where条件都行。这里要注意不要用读到的stock去赋值要直接在SQL里做自减才能避免竞态条件。订单超时未支付也会产生库存问题。下单时先把商品占住15分钟不支付要么用户主动取消要么定时任务自动取消。处理方式扫描订单表status0且create_time早于15分钟前的记录把订单更新为已取消同时恢复对应商品的库存。恢复库存时必须记录一笔“库存变更日志”方便与订单数据对账。4.4 模拟支付与支付回调真实项目里支付一定走第三方但个人项目用模拟支付最省事。我建议用“账户余额”方案用户在个人中心充值支付订单时调用后端接口扣减余额。这样能完整走通支付、回调、订单状态更新链路。如果你想看看真实支付流程可以对接支付宝沙箱或微信支付沙箱不过要特别注意回调验签。我在测试时试过直接信任回调参数结果订单状态被改了后来发现测试回调来源不可控必须用SDK验签后才能更新订单状态。这也是商城类系统的安全红线不能省。支付成功回调里除了更新订单状态还要触发后续动作给用户增加积分、扣减库存、生成发票记录这些。所以回调接口的处理逻辑要尽量幂等即同一个回调请求来多次不会导致积分重复发放、库存重复扣减。简单做法是在回调处理表里记录回调ID重复请求直接跳过。5. 安全、性能与部署上线5.1 JWT鉴权和token刷新前后端分离商城最常用JWT做登录态。用户登录成功后端签发一个accessToken和一个refreshToken前端存在localStorage或pinia里。axios请求拦截器在请求头带上accessToken后端中间件解析token解析失败返回401。refreshToken的用途是让长期在线的用户不用反复登录。前端axios响应拦截器捕获401携带refreshToken调/auth/refresh接口拿到新的accessToken后重新发起刚才失败的请求。这个流程在代码实现时要注意防止并发刷新多个请求同时401时最好用一个Promise队列统一处理否则会频繁刷新token。一个简单的实现思路是这样的axios.interceptors.response.use( res res, async err { if (err.response.status 401) { const refresh localStorage.getItem(refresh_token); if (refresh !refreshing) { refreshing true; try { const { data } await http.post(/auth/refresh, { refresh_token: refresh }); localStorage.setItem(access_token, data.access_token); refreshing false; err.config.headers.Authorization Bearer ${data.access_token}; return axios(err.config); } finally { refreshing false; } } } return Promise.reject(err); } );5.2 防止SQL注入和XSS攻击在Node.js里写SQL直接用mysql2或者Sequelize的参数化查询不要用字符串拼接用户输入。举个例子查询用户输入的用户名正确的是const [rows] await db.execute(SELECT * FROM user WHERE username ?, [username]);而不是const sql SELECT * FROM user WHERE username ${username};第二种写法如果username里输入or 11整个查询条件就会被绕过。前端Vue插值默认不会注入HTML但如果你用了v-html渲染用户提交的内容比如评论、公告就要做内容消毒。简单做法是配置一个富文本白名单或者用DOMPurify过滤后再渲染。后端接口还需要做参数校验。积分兑换尤其要校验数量、兑换商品状态、用户状态。不要在service里全量信任前端传上来的值。比如兑换接口要传商品ID前端可能篡改成另一个商品后端必须根据真实商品ID去查数据库而不是直接使用前端传来的兑换价格和积分。5.3 数据库索引与Redis缓存随着商品数量、订单数量增长数据库容易成为瓶颈。先把索引建对。商品表在category_id、status上建索引订单表在user_id、create_time上建联合索引积分明细表在user_id、create_time上建联合索引。用EXPLAIN看执行计划尽量让查询走索引避免全表扫描。再加一层Redis缓存。首页商品列表、热门商品详情、积分商品列表这些读取频繁但变化较少的数据可以缓存到Redis设置5-10分钟过期。用户购物车如果用数据库存储每次读购物车也有一定开销可以先用Redis hash存等提交订单时再持久化到数据库。我遇到过的问题是Redis存对象时没做JSON序列化取出来是字符串前端解析报错。所以封装一个工具函数set时JSON.stringifyget时JSON.parse最简单也最不容易出错。再一个问题是要给Redis key设置统一前缀比如online_shop:product:123方便清理缓存和排查。5.4 从开发到部署的完整步骤本地跑通之后部署到一个Linux服务器是很有成就感的。前端先打包npm run build生成dist静态文件。后端用PM2守护进程启动pm2 start app.js --name supermarket-api pm2 save pm2 startup然后配置Nginx把80端口转发到dist目录把/api请求转发到Node服务端口。这里有个关键点如果你的Vue路由使用history模式刷新任意子路由都会404必须在Nginx里加location / { try_files $uri $uri/ /index.html; }加上以后前端路由刷新就不会找后端要页面了。如果实在不想折腾配置history路由时也可以用hash模式url带一个#号刷新没问题但看起来不那么美观。后端服务还要注意环境变量管理。数据库密码、JWT密钥、支付回调地址这些不要硬编码在代码里用.env文件或者服务器环境变量配置。我第一次部署就是因为密钥硬编码后来要换密钥还得重新部署一套代码非常麻烦。6. 常见问题排查与个人经验6.1 高频问题速查表现象可能原因解决方案npm安装卡住或失败网络、镜像、缓存问题删除node_modules用.npmrc指定镜像源npm cache clean --forcenpm.ps1无法加载PowerShell执行策略限制以管理员运行Set-ExecutionPolicy RemoteSigned前端请求跨域代理未生效或后端未开CORSVite配置proxy生产环境用Nginx proxy_pass商品图片不显示图片路径或静态资源服务问题后端统一提供/static目录或使用OSS存储积分没有到账支付回调未触发积分逻辑检查支付成功事件后是否调用points模块订单超时未自动取消定时任务未启动确认node-cron已启动服务器时区和创建时间一致Vue刷新404history模式未配置Nginx添加try_files $uri $uri/ /index.html;6.2 项目扩展方向做完基础版之后你可以继续加一些很实用的东西。比如积分签到每天签到送积分用一张签到表记录日期和积分奖励。比如抽奖转盘前端转盘动画后端控制概率和积分扣减。再比如会员等级根据累计积分设置普通会员、银卡、金卡不同等级享受不同折扣和积分倍率。这些都是在现有积分体系上顺理成章扩展的。还有一个很实用的扩展是秒杀或限时抢购。超市经常有低价秒杀活动实现时可以把商品库存提前放到Redis再用Lua脚本做原子扣减。这个方向能进一步锻炼并发处理能力而且和积分兑换的锁库存逻辑一脉相承学会了以后面试也能聊。6.3 我的几点经验这套系统做完我的最大感受是Node.jsVue做商城真正难的不是框架本身而是业务状态的处理。订单状态、积分流水、库存变更每一笔操作都得可追溯、能回滚。把这些想清楚代码写起来反而快。另一个经验是数据库事务别怕用。很多新手觉得事务复杂总想着用“先查后改”代替结果条件一多就出并发问题。实际上MySQL默认InnoDB引擎支持事务Node.js的ORM封装得也很顺手该开事务就开别犹豫。最后一个小建议每次开发到阶段节点把项目推送到Git仓库写清楚commit message。因为你很可能改着改着把某一块逻辑改坏了没有版本控制会想死。这个项目从商品到积分兑换每一步都值得你慢慢打磨。