简介一套基于Node.js与Vue.js前后端分离架构的购物商城系统源码包内置完整数据库设计适合具备Web基础、正在学习全栈开发或准备课程设计的开发者参考。压缩包共156个文件约11.18MB包含36个JavaScript服务端脚本、22个Vue组件、1个SQL数据库文件另有大量商品图片、界面截图、样式表、JSON配置及Markdown说明文档完整覆盖前端页面、后端接口、数据模型与工程配置等层次。目前已有529人学习下载。源码中可以清晰看到Express.js与MongoDB搭配的典型用法Vuex状态管理、Vue Router路由配置、Mongoose操作数据库、NPM依赖管理、Webpack打包等实践细节目录按src、models、routes、controllers等模块划分方便对照学习用户、商品、订单、购物车、支付记录等核心功能的实现思路。对希望将Node.js与Vue.js投入实际项目、快速了解完整电商系统开发流程的开发者而言是一份很有价值的实战参考资料。1. 基于node.jsvue的购物商城选这个组合的底气在哪「商城」这个词在技术论坛里几乎被 Java 系方案占满了但把问题换成「中小规模商城哪个组合迭代最快」node.js vue 的答案要扎实得多。前后端同用 JavaScript接口返回的数据结构不用在两边各维护一套类型vue 的响应式更新让商品卡片、购物车角标这类高频交互不碰 DOMnode.js 的异步 I/O 在商品浏览、用户登录这类读多写少的场景下吞吐很能打。这个组合适合个人开发者和十人以内小团队快速上线商城也适合当成源码研读项目。弱点是强一致性的复杂事务不如传统服务端好写后文会专门处理。2. node.jsvue商城的架构拆分与数据库设计先把图纸画对动手跑源代码之前先花半小时把它的架构和表结构读明白后面所有调试都会顺畅很多。这一章解决「拿到代码先看哪、数据库脚本为什么要这么写」的问题。2.1 node.js 管接口vue 管状态商城的分层边界绝大多数能下载到手的商城源代码长的是同一个骨架vue 单页应用跑在浏览器里node.js 只向外暴露 REST 接口MySQL 存业务数据Redis 存购物车和登录态。这个分层的价值在商城场景里尤其明显PC 端、H5 端、小程序端可以共用同一套 node.js 接口商品详情、下单、支付回调这些逻辑只需要写一次。很多初学者拿到源代码后习惯先翻「哪个文件是商城首页」这个动作恰恰容易让人迷路正确的顺序是先看 node.js 侧的 router 目录接口路径和数据格式全在那里。vue 这一层的核心不是页面长什么样而是状态怎么流动。登录状态、购物车角标数量、当前选中的收货地址这些跨页面共享的数据放在 pinia 里页面组件只负责渲染和派发动作。vue-router 管路由跳转路由参数里带商品 id 和 sku id 是商城详情页最常见的传参方式。node.js 侧的职责要更重一些除了把商品表的数据查出来还要做鉴权中间件校验 token、把商品基础信息和库存信息合并返回、在支付回调里更新订单状态。两层之间通过 axios 通信前端发请求时带Authorization头后端统一在中间件里解析。团队协作时数据库同步问题往往比代码合并更早爆发。没有独立的测试库多个人共用一个本地 MySQL 实例经常出现「我改的表结构你那边没同步」的情况。常见做法是用 Navicat 的结构同步功能或者直接mysqldump -d mall mall_schema.sql把 dev 库结构导出来再灌到自己的本地库。这不是多高深的功能但不处理就会浪费一上午联调时间。2.2 商品、用户、订单三张核心表字段设计决定源代码难不难读拿到数据库脚本后不需要把每张表都看完抓住商品、用户、订单三条主线就够了。表结构设计有两个容易踩的坑一是把订单金额直接做成浮点类型精度问题在下单结算时追着打二是商品表把价格、库存、图片全部堆在一张表里换季促销时连加一个「秒杀价」字段都胆战心惊。下面的商品基础表是中小商城常见的折中方案既没过度拆分到 SPU/SKU 两层又保留了扩展空间。字段类型说明idbigint unsigned自增主键namevarchar(128)商品名称pricedecimal(10,2)销售价decimal 不用 floatmarket_pricedecimal(10,2)划线价促销展示用stockint unsigned库存余量salesint unsigned销量下单成功后累加statustinyint1 上架0 下架cover_urlvarchar(255)主图地址created_atdatetime创建时间价格用decimal(10,2)而不是 float是这里最重要的一条经验。float 是近似存储1.1 加 2.2 会算出 3.3000000000000003一旦把这种值写进订单表后续对账就是一场灾难。decimal 以定点方式存储十进制数加减乘除结果精确代价只是多占一点存储空间对商城完全可接受。看到源代码里价格字段用 double 的第一反应就应该是改成 decimal连数据库迁移脚本一起改。订单表的字段则围绕「状态机」设计order_no 唯一订单号、user_id 用户、total_amount 总金额、status 当前状态、address_snapshot 收货地址快照。address_snapshot 这个字段容易被忽略用户的收货地址是可以改的订单生成后如果去关联最新的地址表可能第二天打印发货单就发现地址变了。把下单那一刻的地址完整冗余进订单表是电商场景里公认的做法这也是「读表结构就能判断源代码作者有没有真实运营经验」的观察点。2.3 建库脚本怎么写utf8mb4、自增主键和初始数据的细节数据库脚本不是简单把创建表的 SQL 串在一起初始化和默认值处理不好源代码在别人机器上一定跑不起来。先看一个最小可用的建库语句CREATE DATABASE IF NOT EXISTS mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;字符集必须用 utf8mb4 而不是 utf8。utf8 在 MySQL 里实际最多存 3 字节商品名里出现 emoji 或者生僻字就直接写入失败utf8mb4 是完整的 4 字节编码现在新项目都应该默认它。_unicode_ci排序规则比_general_ci对各国语言的处理更规范并且大小写不敏感查询WHERE name iphone也能命中iPhone。这段建库脚本建议直接放进源码仓库的 init.sql而不是只存在于某个人本机。建表脚本里另一条容易踩坑的规则金额类字段用 decimal数量类字段用 unsigned 整型时间字段统一 datetime。下面是订单明细表的建表片段注意外键的取舍CREATE TABLE order_items ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_id BIGINT UNSIGNED NOT NULL, product_name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, quantity INT UNSIGNED NOT NULL, PRIMARY KEY (id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;无业务意义的自增 id 做主键order_no 只建普通索引而不是让 order_no 当主键。原因有两个层面第一订单号带业务前缀还可能掺入日期字符型主键在 InnoDB 聚簇索引里的随机插入性能远不如自增整数第二order_no 在支付回调场景里只是一个业务标识它需要的是查询速度快和唯一约束唯一索引完全够用。如果商品是多规格产品名和单价还要冗余进 order_items防止商品改价或改名后历史订单无从对证。数据库增删改查的顺序在商城源代码里也有讲究商品列表走查询、用户注册走插入、购物车更新走更新这些场景都直接真正需要警惕的是删除。商城里几乎没有物理删除商品下架用 status 字段、订单取消用状态流转连购物车条目都是软删除。这不是过度设计而是因为商城数据天然有对账和审计需求物理删掉一条订单明细月底结算时就少一个凭证。初始化数据脚本同样重要init.sql 里至少要有一个管理员账号、几个分类和若干商品样例否则前端页面打开后全屏空白第一印象就是项目没跑通。3. vue3 node.js 从零跑通商城最小闭环架构图纸画完这一章把「后端出接口、前端出页面、联调跑通」的最小闭环走一遍。不需要完整复刻商城的全部功能一条商品接口、一个商品详情页、一组正确的环境配置足以验证整套源代码能不能在你的机器上活过来。3.1 node.js 安装后的第一件事确认版本和 npm 镜像拿到源代码后最先踩的坑通常不在代码里而在 node.js 环境本身。很多商城项目对 node 版本有隐性要求用系统自带的老版本去跑新依赖经常出现the requested module node:util does not provide an export named这类模块导出报错本质是 Node 18 以下的环境混用了 ESM 语法。建议用 nvm 管理版本不要直接用官网安装包覆盖系统环境因为不同项目锁的 node 版本可能差着两个大版本。nvm install 18 nvm use 18 node -v npm -v npm config get registrynode -v是检验标准如果显示的版本号和项目要求对不上后面所有步骤都会在装依赖或运行时报莫名其妙的问题。npm config get registry检查镜像地址国内机器如果从没设置过大概率返回官方源装依赖时部分包会慢到像卡死。常见做法是执行npm config set registry https://registry.npmmirror.com再执行一次 get 确认。这里改的是 npm 全局配置只影响安装行为不会改代码执行逻辑所以项目 README 里也应该写清楚镜像设置否则新同事在装依赖阶段就会卡半小时。3.2 后端 3000 端口先出商品接口后端这块从一个最小可用的商品列表接口开始。许多商城源代码会把路由、控制器、模型拆成三层但第一次跑通流程时不用关注那么细先确认 express 能启动、MySQL 能连上、接口能返回数据再往分层上靠。下面是server/app.js的核心片段// server/app.js const express require(express); const mysql require(mysql2/promise); const app express(); app.use(express.json()); const pool mysql.createPool({ host: localhost, user: root, password: 123456, database: mall, waitForConnections: true, connectionLimit: 10, }); // 商品列表接口只返回上架商品limit 由查询参数控制 app.get(/api/products, async (req, res) { try { const limit Number(req.query.limit) || 20; const [rows] await pool.query( SELECT id, name, price, cover_url FROM products WHERE status 1 ORDER BY id DESC LIMIT ?, [limit] ); res.json({ code: 0, data: rows }); } catch (err) { res.status(500).json({ code: 1, message: err.message }); } }); app.listen(3000, () { console.log(mall api running at http://localhost:3000); });这段代码里有三个细节值得留意。第一mysql2/promise返回的是 promise 封装过的连接池await pool.query直接拿查询结果不再嵌套回调第二LIMIT ?的占位符必须由传入的变量解析直接用req.query.limit拼进 SQL 会触发注入或类型报错第三status 1写在 SQL 里而不是查出全部商品再在 JS 里过滤这是数据库职责和接口职责的正确分界。连接池写在文件顶部多个路由共享同一组连接避免每个请求都新建连接。连接参数里waitForConnections为 true 表示连接池满了以后请求排队等待而不是立刻报错connectionLimit本地开发设 10 够用线上根据机器并发量调大。调试阶段最常见的报错是ER_ACCESS_DENIED_ERROR不要急着翻代码先用本机 MySQL 客户端验证 root 账号和密码能不能连上再回来看连接配置。数据库名、用户名、密码这些建议放在.env文件里用dotenv加载而不是写死在源码中这样换环境不用改代码。3.3 vue 项目初始化与路由参数打通前端这边不用老的 webpack 脚手架现在从零建 vue 项目最省事的是 Vite。顺带把 vue 安装及环境配置里最容易出问题的一步说清楚初始化命令和依赖安装是两个独立过程后者依赖前者生成的项目结构。npm create vitelatest mall-client -- --template vue cd mall-client npm install npm install axios vue-router4 pinia npm run devnpm create vitelatest生成的模板默认不带路由和状态管理所以npm install axios vue-router4 pinia要手动加。跑完npm run dev后终端会打印一个本地地址浏览器能打开默认页说明 vue 环境本身没问题后面的工作是替换成商城页面。很多人卡在 npm install 装包慢或者报 peerDependencies 冲突先回头检查 3.1 节的 registry 设置把镜像切到国内源大部分装包失败都能解决。拿到商城源代码时它的 src/router 目录通常已经定义好了路由表理解路由参数是读懂这套前端的关键。看这段最小路由配置// src/router/index.js import { createRouter, createWebHistory } from vue-router import Home from ../views/Home.vue import ProductDetail from ../views/ProductDetail.vue const routes [ { path: /, name: home, component: Home }, { path: /product/:id, name: product-detail, component: ProductDetail } ] export default createRouter({ history: createWebHistory(), routes })/product/:id里的:id是动态路由参数在 ProductDetail.vue 中通过useRoute().params.id获取。这个值通常是商品 id 或 sku id拿到以后调用/api/product/:id获取详细数据。商城里的商品详情页、订单详情页、用户主页全部是这一模式路由参数的命名规范和取值方式一旦读懂整套前端的跳转逻辑就通了。Vite 开发模式下路由默认走 history 模式地址栏里没有#比老式 hash 路由干净但部署上线时对服务器重写配置有额外要求第 5 章会专门讲。3.4 vite 代理联调处理断点失效的常见根因前端 dev server 默认跑在 5173 端口后端 API 在 3000 端口直接让前端请求http://localhost:3000会触发跨域。商城项目最常见的做法不是在后端加 CORS 中间件而是用 Vite 的 proxy 把/api前缀的请求转发到后端// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { proxy: { /api: http://localhost:3000 } } })配置完成后前端 axios 请求地址统一写成/api/products浏览器发出的请求只到这个相对路径Vite 在开发服务内部完成转发。这么做有两个好处一是不用处理 CORS 预检请求联调阶段少一类报错二是前端代码里接口地址保持相对路径将来部署时用 nginx 做类似转发前端代码一行都不用改。修改 vite.config.js 后必须重启 dev server 才生效这一点经常被忽略。联调时如果 Chrome DevTools 提示「当前不会命中断点」先按三个方向排查。第一访问的是不是打包产物 dist 目录而不是 dev server 源码生产构建后断点源映射和开发模式完全不同第二Source 面板里找不到对应文件说明 source map 没生成或路径映射错误第三Vue 单文件组件里的断点要打在script setup内部模板表达式对应的是编译后的 render 函数源码行号和实际执行行号对不上。每次改完代码 vite 会热更新热更新后的模块如果断点没重新命中刷新一次页面基本都能恢复。4. 购物车与订单的并发一致性源代码里最容易写崩的两处商城代码跑起来容易但购物车合并和订单超卖是两处天然的雷区。这一章把并发场景下的数据一致性问题讲透顺带给出可以直接抄的事务写法。4.1 购物车数据放 Redis 还是 MySQL登录态怎么合并购物车的特征是高读写频率、强临时性、单用户数据量小这决定了它不适合直接堆在 MySQL 业务表里。每个用户进商城都会读写购物车如果每次操作都落库订单高峰时购物车表的行锁和 IO 会成为瓶颈。常见做法是登录用户的购物车放 Redis 的 hash 结构字段是 skuId值是数量过期时间设七天。看下面的加入购物车代码// server/redis.js 片段 const redis require(redis); const client redis.createClient({ url: redis://localhost:6379 }); async function addToCart(userId, skuId, quantity) { const key cart:${userId}; // hIncrBy 按 skuId 累加数量同一商品重复加入自动合并 await client.hIncrBy(key, String(skuId), quantity); // 七天不活跃自动清理避免僵尸数据占内存 await client.expire(key, 60 * 60 * 24 * 7); }hIncrBy的原子性在并发场景下很有价值用户连续快速点两次「加入购物车」这个命令返回的数量一定是对的不会因为两次请求同时读到旧值而丢数据。expire必须和写入放在同一个 key 上否则用户加购一次后就永远不清零。Redis 的 key 命名用cart:1这种冒号分隔格式Redis 官方称这种风格为 key 分层它让同类型 key 在 RedisInsight 这类工具里能以目录形式展示。未登录用户不能用 Redis因为不知道 userId。前端做法是把购物车存 localStorage以localStorage.setItem(cart_temp, JSON.stringify(cart))持久化登录成功后再发起合并请求前端把临时购物车数组发给 node.js后端逐条执行hIncrBy完成后清空 localStorage。这里要注意一点合并请求必须是「前端主动发起」而不是登录后自动触发因为用户在登录页可能只是单纯登录并不想立刻合并上次遗留的数据。4.2 库存扣减的事务边界一条 UPDATE 就能防超卖下单场景的并发问题集中在库存扣减上。最容易写崩的版本是三段式先 SELECT 查库存、判断是否够用、再 UPDATE 扣减。这个流程在并发不高时没问题一旦两个请求同时读到库存还剩 1 件都会认为可以下单最终超卖。防超卖的核心是让「检查库存」和「扣减库存」变成原子操作最常见做法是条件更新// 扣减库存stock quantity 条件不满足时 affectedRows 为 0 const [result] await pool.query( UPDATE products SET stock stock - ? WHERE id ? AND stock ?, [quantity, skuId, quantity] ); if (result.affectedRows 0) { // 库存不足直接返回避免继续写订单 return res.status(400).json({ code: 1, message: 库存不足 }); }这条 SQL 的巧妙之处在于把判断条件放进了 UPDATE 的 WHERE 里MySQL 对单条 UPDATE 语句是行级原子执行的两个并发请求同时执行时只有一个的affectedRows为 1另一个得到 0。这是解决超卖成本最低的方案不需要事务、不需要锁、不需要 Redis 预减库存。代价是它假设库存只要够就扣不校验「是谁」在扣所以只适用于普通商品下单秒杀场景要在这个基础上再加限流。但扣库存通常不是单条语句就能结束的业务扣完库存还要生成订单、写订单明细、清空购物车对应项这些操作必须包在同一个事务里。事务边界要覆盖从扣库存到订单落库的全部写操作const conn await pool.getConnection(); try { await conn.beginTransaction(); const [result] await conn.query( UPDATE products SET stock stock - ? WHERE id ? AND stock ?, [quantity, skuId, quantity] ); if (result.affectedRows 0) { await conn.rollback(); return res.status(400).json({ code: 1, message: 库存不足 }); } await conn.query( INSERT INTO orders (order_no, user_id, total_amount, status) VALUES (?, ?, ?, 0), [orderNo, userId, totalAmount] ); await conn.commit(); } catch (err) { await conn.rollback(); throw err; } finally { conn.release(); }事务的关键是连接复用beginTransaction到commit之间的所有语句必须使用同一个conn而不是连接池里的新连接。如果中途某一步失败rollback会把扣掉的库存和写了一半的订单全部撤销。conn.release()在 finally 里执行保证连接一定归还池子否则事务异常时连接被占用很快就打满连接池。真实项目里订单号要在进入事务之前生成好不能把生成逻辑放进事务因为订单号生成往往依赖时间戳加随机数即使事务回滚它也应该被废弃。4.3 订单状态机与支付回调幂等订单表最核心的字段就是 status它的流转必须在源代码里形成明确约束。随手在每个业务方法里直接改 status 的做法会让代码越改越乱规范做法是定义一个状态机所有状态变更走同一套检查逻辑status含义允许跳转0待支付1、41已支付22已发货33已完成无4已关闭无支付回调是最容易出状态错乱的入口。第三方支付平台为了保证回调送达会多次推送同一条支付结果如果代码没有幂等处理同一订单会被重复从 0 改成 1 两次甚至把已发货的订单再改回待支付。常见做法是条件更新// 只有 status 0 时才能从待支付改为已支付 const [result] await conn.query( UPDATE orders SET status 1, pay_time NOW() WHERE order_no ? AND status 0, [orderNo] ); if (result.affectedRows 0) { // 说明订单不是待支付状态直接当作已处理返回成功 return res.json({ code: 0, message: duplicate callback }); }支付回调的幂等不用分布式锁一条条件 UPDATE 就解决了第二次回调时订单已经不是 status 0affectedRows 为 0代码直接返回成功告诉支付平台「已经处理过了」。这个方法同样适用于订单关单、发货、确认收货所有状态流转都带上「当前状态必须是 xxx」的条件等于把状态机的约束下沉到了数据库层。超时关单是另一个隐藏的线上事故源。很多开发用 Redis 的过期监听来关单但 Redis key 过期事件并不保证立即触发数据量大时事件延迟可能超过十分钟而且 Redis 重启会丢失过期事件。稳的做法是定时任务扫描每两分钟执行一次条件更新把创建超过 15 分钟且仍为待支付的订单批量关闭同时回补库存UPDATE orders SET status 4 WHERE status 0 AND created_at NOW() - INTERVAL 15 MINUTE;这条 SQL 把关单和状态检查放在同一个语句里不会重复关掉同一个订单。回补库存时要关联 order_items 表把对应商品的库存加回去。定时任务的频率和超时时间要根据业务调15 分钟无支付就关单适合标品商城虚拟商品可以缩短到 5 分钟预售商品可能要延长到 30 分钟。关单之后用户又想支付的情况要在支付回调里额外判断 status 4 已关闭这时需要走「重新打开订单」的流程而不是直接改状态。5. 商城源代码的部署验证与几个值得保留的细节本地跑通只是开始真正暴露问题的是部署环节。vue 打包后布局异常这个关键词经常出现在论坛里九成原因是base配置和 history 路由 fallback 没配对。开发时路由走的是浏览器 history 模式打包后如果 nginx 没有把未知路径重写到 index.html用户访问/product/123刷新一下就 404。这里的 nginx 配置是整个部署环节的骨架server { listen 80; server_name mall.example.com; root /srv/mall-client/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:3000; } location / { try_files $uri $uri/ /index.html; } }proxy_pass http://127.0.0.1:3000;这里不加结尾的/转发时保留完整的/api/前缀与本地 vite 代理行为保持一致。try_files $uri $uri/ /index.html;是 history 路由存活的命根子先找真实文件找不到就回退到入口页。vue 打包后布局异常先看 index.html 里的静态资源路径是不是绝对路径/assets/xxx如果部署在子目录就要在 vite.config.js 里设置base: /mall/另外一个常见根因是 CSS 里用了vh和vw单位某些 Android WebView 下布局会撑破改成100%配合overflow: auto更稳。后端部署用 pm2 管理 node 进程这是 node.js 生态里最通用也最省心的守护方案pm2 start server/app.js --name mall-api pm2 save pm2 startuppm2 startup会生成一条系统开机自启命令服务器重启后 node 服务自动拉起不用手动登录服务器再敲一遍启动命令。启动完成后用 curl 验证接口是否真的可用curl -s http://localhost:3000/api/products?limit5 | head -c 500head -c 500只截取返回前 500 个字符避免订单接口返回大量数据刷屏。如果返回的是 JSON 数组而不是错误页说明 node.js、MySQL、Redis 三条链路都是通的。最后把前端构建产物放到 nginx 的 root 目录用自己的域名打开商城首页从商品列表点到详情页再从详情页加入购物车走一遍完整流程这才是源代码落地到服务器后的最终验收标准。本文还有配套的精品资源点击获取