企业官网建设流程全解析

做这类电商练手项目的人我见过太多了，基本都是同一个路子：找到一个商城系统模板，把数据库导进去，改个名就以为自己有了一个能上线的东西。结果别人一问"你项目里购物车是怎么设计的，库存扣减怎么保证不超卖"，当场卡壳。我这次复盘的这个基于 Node.js + Vue 的小零食超市购物商城销售系统，就是从零开始自己梳理清楚的一个完整项目，前后端加起来不到三千行业务代码，但该有的东西一样没少：商品分类、SKU 规格、购物车、订单、会员登录、库存扣减。这篇文章我会把当时的技术选型、环境配置、前后端核心模块的落地思路和踩坑记录完整讲一遍，希望能帮正在做同类系统的朋友少走点弯路。

这套系统适合谁参考？第一类是拿它当毕业设计或者课程项目的学生，你需要的是一个能让老师追问下去的完整闭环，而不是一个花架子。第二类是刚工作一两年、想用全栈项目证明自己能力的初级工程师，你正好缺一个能用 Node.js 打通前后端所有环节的实战案例。我下面讲的都基于 Node.js 18 LTS + Express + Vue 3 + Vite + MySQL，如果你用的是其他版本，核心逻辑不变，细节上自己微调就行。

1. 为什么偏偏是 Node.js + Vue，而不是其他组合

先说清楚一个事：商城系统并不是电商公司专用的大型分布式项目。小零食超市这种业态有它的特点——SKU 数量大、单品价格低、用户决策路径短、复购率极高。这意味着你不需要去考虑秒杀、分布式事务、消息队列这些东西，真正需要下功夫的是"如何让用户快速选品、快速下单、结算不卡顿"。在这个量级下，Node.js + Vue 的组合有天然优势。

1.1 这类商城项目真正考验人的地方

很多人做商城第一反应是先画库存表、商品表、订单表，然后写 CRUD。但这类项目真正难的不是 CRUD，是下面这几个点：

一是商品规格模型。零食超市的商品往往有多个维度：口味（原味、番茄味、烧烤味）、净含量（50g、100g、200g）、包装形式（袋装、盒装）。一个"乐事薯片"在页面上是一张卡片，在数据库里却是好几个 SKU 的聚合。这个模型做不好，后面的购物车、订单、库存全都会跟着乱。

二是购物车与会话的关系。用户是登录了才能加购物车，还是不登录也可以加？登录后购物车要不要和本地购物车合并？这些都是真实业务中每天都要处理的问题。你这个项目只做浏览器本地版本，购物车就能用 localStorage；如果需要支持多设备同步，购物车就必须放到后端。

三是库存扣减的准确性。两个用户同时下单最后一个库存怎么办？在前端管库存是肯定不行的，必须在后端下单接口里保证原子性。

我见过很多"毕设级"商城，商品表字段琳琅满目，但上述三个问题一个都没说清楚。理解了这个前提，我们再来谈技术选型，你才能明白我不是随便选了个热门组合，而是这套组合真的能让这些问题以更低成本被解决掉。

1.2 技术栈选型的底层逻辑

Node.js 后端在解决上述问题时，最大的好处是前后端语言同构。前端写 Vue 用的是 JavaScript，后端的路由、控制器、数据校验也全用 JavaScript，代码里类型结构是天然互通的。比如后端定义一个商品 SKU 的对象结构，前端拿到 JSON 后不需要做二次转换，直接把字段映射到页面组件里就行。对单人开发或者小团队开发来说，这省掉的不只是切换上下文的时间，出问题时的定位链路也短得多。

有人会问，那 Spring Boot + Vue 不是更"正规"吗？这个热搜词我看到了，确实有不少项目这么用。但如果你的目标是快速把一个商城系统做出来并且讲清楚每一步，Spring Boot 的重型框架反而会带来大量无意义的模板代码：实体类、Mapper、Service 层、Controller 层，代码量轻松翻倍。Node.js 这边用 Express 或者 Koa，路由直接写在 controller 文件里，一个中间件搞定鉴权，几十行代码就能把接口全部串起来。

当然不是无脑站队。如果你的项目未来要面对千人以上团队协作、重度并发事务、长期权益系统这些复杂场景，Java 家族肯定更稳。但一个"小零食超市购物商城销售系统"——注意标题里的"小"字——用它来描述的场景，Node.js 是足够且更高效的。

1.3 商城分层架构拆解

整个系统我分成三层：

• 前端展示层：Vue 3 SPA，负责商品列表、商品详情、购物车、下单结算、个人中心这些页面交互。
• 后端 API 层：Express 服务，负责暴露 REST 接口，包括用户注册登录、商品查询、购物车增删改查、创建订单、订单详情，以及后台管理端的商品上下架和库存修改。
• 数据存储层：MySQL，保存用户、商品、SKU、购物车、订单、订单明细这六类核心数据。

开发时前端跑 5173 端口，后端跑 3000 端口，通过 Vite 的 proxy 代理把接口请求转发到后端，这样就不存在跨域问题。生产环境我直接把前端 build 出来的 dist 目录挂到 Express 的静态目录下，用同一个进程对外服务，省一层 Nginx 的配置成本。对小项目来说，这种部署方式最省心。

2. 环境搭建阶段最容易让人劝退的三个坑

我本来想直接从业务代码开始讲，但看到热搜词里"npm : 无法加载文件 d:\program files (x86)\nodejs\npm.ps1，因为在此系统上禁止运行脚本"出现了好几次，就知道环境这关卡住了太多人。这里单独拿出来详细说，因为这确实是最容易让人以为"自己电脑有问题"、其实几分钟就能解决的坎。

2.1 npm.ps1 无法加载：PowerShell 执行策略问题

这个问题的症状很典型：你在 VS Code 的终端里敲npm -v，结果报了一长串红字，大致意思是 npm.ps1 不是有效命令或者被禁止运行。为什么会有这个报错？

原因在于 Node.js 安装后，npm 命令实际上被封装成了一个npm.ps1文件（PowerShell 脚本版本），而 Windows 默认的 PowerShell 执行策略是 Restricted，啥脚本都不让跑。你明明把 Node.js 装对了，环境变量也配了，就因为这个策略挡着，所有 npm 命令全部失灵。

解决办法有三个，按推荐程度排：

方法一，管理员权限打开 PowerShell，运行：

Set-ExecutionPolicy RemoteSigned

这个命令会把执行策略改成"本地脚本可运行，远程脚本需要签名"。npm.ps1是本地文件，所以会被放行。执行完敲node -v和npm -v验证一下。这是最推荐的办法，能一次性根治，不用每次开终端都折腾。

方法二，如果不想动全局策略，就避开 PowerShell 终端。在 VS Code 里把终端切换成 Command Prompt 或者 Git Bash，这两个终端不需要走 PowerShell 执行策略。npm命令一样能跑。这个方法治标不治本，但应急很有效。

方法三，还有一类情况是你电脑上装的 npm 路径带空格的文件夹，比如d:\program files (x86)\nodejs\。如果前面两个方法都试了还报错，排除一下路径问题。但以我见过的大量反馈来看，90% 以上都是执行策略引起的，路径只是背锅。

2.2 Node.js 装了却找不到命令：环境变量问题

另一个热门搜索是nodejs环境变量配置。很多人下载了 Node.js 安装包，双击安装一切顺利，但关掉安装向导后打开命令行，输入node -v提示"不是内部或外部命令"。

这是因为他安装时没有把 Node.js 自动加入系统 PATH。新版 Node.js 安装器，一路默认安装其实会自动配好 PATH，出现找不到命令的情况多半是没走默认路径，或者手动指定了目录却没有勾选 "Add to PATH" 选项。我的建议是安装的时候不要改路径，直接 C 盘默认装；实在要改，务必在步骤里把 "Add to PATH" 勾上，装完再重启一次终端。

如果你已经装好了但就是找不到命令，那就自己去配环境变量：

1. 右键"此电脑"→ 属性 → 高级系统设置 → 环境变量。
2. 在系统变量里找到 Path，把 Node.js 的安装目录（比如C:\Program Files\nodejs\）加进去。
3. 确定保存后，新开一个终端再试。

顺便提一下，热搜词里还有windows如何升级nodejs版本。别再手动去官网下载新安装包覆盖了，直接装一个 nvm-windows，用nvm install 20、nvm use 20搞定版本切换，不仅是升级方便，遇到项目需要不同 Node 版本时也很实用。

2.3 依赖安装慢或报错：注册表源与版本匹配问题

环境变量解决了，第下一步就是安装依赖。国内直接跑npm install，那个下载速度谁试谁知道，而且经常因为网络问题导致依赖装了一半就红字报错。解决办法是换镜像源：

npm config set registry https://registry.npmmirror.com

换完可以验证一下：npm config get registry，看到淘宝镜像地址就说明生效了。

依赖装完过后，创建 Vue 3 项目这一步，我建议直接用官方脚手架：

npm create vue@latest

这里要注意：npm create vue创建出来的是 Vite + Vue 3 的项目，不是旧的 Vue CLI 项目。老教程里用vue create的教程基本是 Vue 2 时代的产物了，结构已经不再推荐。脚手架会问你要不要集成 Vue Router、Pinia、ESLint 等，统一回答 Yes 就好，省得后期手动加。创建完npm install再跑npm run dev，能打开页面，你的开发环境就算彻底通了。这一步做完，后面才是真正的业务开发。

3. 后端：订单和购物车才是这个系统的灵魂

商城系统的后端，说穿了是给前端提供数据接口，但哪些接口之间是有依赖关系的、哪些操作必须保证要么全成功要么全失败，这才是设计的关键。我按照数据模型、登录鉴权、购物车与下单三个环节来讲。

3.1 数据表设计：把 SKU 的概念单独拎出来

小零食超市的商品有两个层级概念，这里必须分清楚：商品（Product）和 SKU（Stock Keeping Unit，库存量单位）。商品是用户看到的"一件东西"，比如"三只松鼠每日坚果 30 袋装"；SKU 是具体能卖的规格，比如"30 袋装/原味/750g"对应一个价格和一堆库存。一张商品卡背后往往挂好几个 SKU。

我在 MySQL 里建了六张核心表：

• 用户表user：id、用户名、密码哈希、昵称、创建时间。
• 分类表category：id、分类名、父级分类 id、排序值。
• 商品表product：id、名称、主图、分类 id、描述、状态（上架/下架）、创建时间。
• 商品规格表sku：id、商品 id、规格名称（比如"原味+50g"）、价格、库存、销量。
• 购物车表cart_item：id、用户 id、SKU id、数量、选中状态、加入时间。
• 订单表order：id、订单号、用户 id、总金额、状态（待支付/已支付/已发货/已完成/已取消）、收货信息、创建时间。
• 订单明细表order_item：id、订单 id、SKU id、商品快照、单价、数量。

order_item里为什么要存"商品快照"？因为商品价格和名称是会变的，如果订单明细细表直接关联product表，半年后再看历史订单，商品名可能已经改了，价格也对不上账。把当时的名称、单价、图片 url 存进快照字段，才能保证历史订单的数据是凝固的。这个细节很基础，但很多项目都忽略了。

3.2 登录鉴权：JWT 的完整闭环

用户系统不用复杂，一个 JWT 就够了。注册接口接收用户名和密码，密码用 bcryptjs 加盐哈希再入库，绝不能明文存。登录接口校验密码通过后，签发一个 JWT，里面带上用户 id 和用户名，设置 7 天过期时间，返回给前端。

后面所有需要身份的接口，前端在请求头里带Authorization: Bearer <token>。后端写一个鉴权中间件：

const jwt = require('jsonwebtoken'); function authMiddleware(req, res, next) { const header = req.headers['authorization'] || ''; const token = header.startsWith('Bearer ') ? header.slice(7) : null; if (!token) { return res.status(401).json({ code: 401, msg: '未登录' }); } try { const decoded = jwt.verify(token, process.env.JWT_SECRET); req.user = decoded; next(); } catch { return res.status(401).json({ code: 401, msg: '登录已过期' }); } }

中间件挂在购物车、下单、订单列表这些接口前面。访问/api/user/info时从req.user里取用户 id，不用前端把用户 id 传过来。这个设计很关键，否则任何人都可以伪造请求拿到别人的购物车和订单。

3.3 购物车和下单逻辑：事务和并发缺一不可

先说购物车。登录用户的购物车我放在后端cart_item表里，每次加购都是直接调 API。未登录用户我也允许加购，这时前端把购物车数据放在 localStorage 里，等用户登录后再发起一次合并请求，把本地购物车的条目全部写入后端。为什么要这么设计？零食电商的用户决策很轻，如果强制登录才能加购，转化率会掉一大截。但这套系统的核心场景是"用户登录后操作购物车"，所以 localStorage 方案只是体验上的一个补充。

下单接口是整个后端逻辑最核心的部分，因为它涉及多表更新和并发问题。流程是：

1. 接收请求，带上收货人、电话、地址、购物车条目列表。
2. 后端根据 SKU id 列表查出当前库存。
3. 逐个判断请求数量是否超过库存，任何一个超了就返回错误。
4. 生成订单号、订单记录、订单明细记录。
5. 更新 SKU 的库存和销量。
6. 清空购物车中已下单的条目。

步骤 3 到 5 必须放在同一个数据库事务里。Express 本身不管事务，我需要用 mysql2 的connection.beginTransaction()，然后结合SELECT ... FOR UPDATE对 SKU 行加锁，才能避免超卖：

const conn = await db.getConnection(); try { await conn.beginTransaction(); const [rows] = await conn.query( 'SELECT id, stock FROM sku WHERE id IN (?) FOR UPDATE', [skuIds] ); // 检查库存，扣减库存，插入订单 await conn.commit(); } catch (error) { await conn.rollback(); throw error; } finally { conn.release(); }

FOR UPDATE在 InnoDB 引擎下会对命中的行加排他锁，同一时间第二个请求就得等第一个事务提交后才能读到最新库存。这个机制用对了，超卖至少在数据库层是被拦住的。很多人做商城把前端传数量后端直接UPDATE一下，最高并发一压就出问题，没人教过他们事务和行锁在这里是必须的。

4. 前端：把"逛零食"的感觉做出来

后端能把数据存起来、接口调通，项目的骨架就有了。但商城好不好用、展示顺不顺眼，全看前端。Vue 3 这个部分我用的是组合式 API 加<script setup>，项目结构上按views / components / router / stores / api来组织。

4.1 路由组织：页面划分和懒加载

一个零食商城的用户路径其实非常短：首页逛 → 点进商品详情 → 加购物车 → 结算。管理端则相对独立。所以路由我分成两块：client路由和管理端路由。

客户端路由：

{ path: '/', component: () => import('@/views/Home.vue') }, { path: '/category/:id', component: () => import('@/views/Category.vue') }, { path: '/product/:id', component: () => import('@/views/ProductDetail.vue') }, { path: '/cart', component: () => import('@/views/Cart.vue') }, { path: '/checkout', component: () => import('@/views/Checkout.vue'), meta: { requiresAuth: true } }, { path: '/orders', component: () => import('@/views/OrderList.vue'), meta: { requiresAuth: true } }

这里用了动态路由。/category/:id和/product/:id是典型的路由参数，组件内通过route.params.id读取当前分类或商品 id。meta.requiresAuth字段用来做路由守卫，在router.beforeEach里判断有没有登录 token，没登录就重定向到登录页。你们做商城系统，这个守卫应该是标配，千万不能只依赖按钮级判断。

所有页面组件都用() => import()懒加载。零食商城页面多、图片多，如果把所有页面都打进一个 chunk，首屏体积会很大，懒加载按路由拆分 chunk，首屏只加载首页资源，体验会好不少。

4.2 商品规格选中与 SKU 联动

商品详情页的核心组件是规格选择器。零食商品最常见的是两个维度，比如口味和重量，每个维度有几个选项，用户必须把所有维度选齐才能确定一个 SKU。

我在ProductDetail.vue里维护两个数据结构：

const specs = ref([]); // [{ name: '口味', values: ['原味', '辣味', '番茄'] }] const selectedSpecs = ref({}); // { '口味': '原味', '重量': '50g' }

当用户点击某个规格值时，先判断这个组合有没有对应 SKU。最简单的方式是前端拿到商品详情时，把后端返回的skuList转成一个 map，key 是各规格值的组合串，value 是 sku 对象：

const skuMap = {}; skuList.forEach(sku => { const key = sku.specText; // 后端拼接好的，比如 '原味|50g' skuMap[key] = sku; });

用户选完后，拼接当前selectedSpecs的 values，去skuMap里查，查到了就把价格、库存、skuId 展示出来，查不到就是"此组合暂时缺货"。这个做法的好处是复杂度很低，没有复杂的排列组合计算，适合多规格但规模有限的小零食商城。等你做服装类那种几十个规格属性的项目，再考虑专门的 SKU 矩阵算法。

4.3 购物车交互与状态管理

前端购物车我用 Pinia 管理，因为购物车数据要同时被导航栏角标、购物车页面、结算页这三个地方用到，如果再在各组件之间用 props 和事件传来传去，那真是自找麻烦。

store/cart.js的核心结构：

export const useCartStore = defineStore('cart', { state: () => ({ items: [] }), getters: { totalCount: (state) => state.items.reduce((sum, item) => sum + item.count, 0), selectedItems: (state) => state.items.filter(item => item.checked), totalPrice: (state) => state.items .filter(item => item.checked) .reduce((sum, item) => sum + item.price * item.count, 0) }, actions: { addItem(sku) { const exist = this.items.find(i => i.skuId === sku.id); if (exist) { exist.count++; } else { this.items.push({ skuId: sku.id, name: sku.name, price: sku.price, count: 1, checked: true }); } } } });

注意几个细节。数量加减要设下限 1，上限是 SKU 剩余库存，提交订单前再让后端做最终校验。零食按小件走，数量和一个一个加挺合理，但如果你以后卖的是整箱饮料，单品加购数量限制就要考虑"以箱为单位"之类的问题。这些都要根据商品类型定。

加购之后我除了 toast 提示，还会做一个小动画：商品卡片上的"加入购物车"按钮点击后，一个缩略的图标飞向导航栏购物车角标位置，同时导航栏角标数字做一次弹跳动画。这个不算难，一个绝对定位元素加 CSS 过渡就行，但对逛零食这种场景来说，这个小细节会让整个页面显得活泼很多。热搜词里有人搜"vue 组合式和选项式混合开发"，我自己的建议是购物车这种共享状态用组合式 + Pinia，组件内部如果逻辑简单就用选项式，混着用没有原则问题，关键是要让别人能看懂。

5. 前后端联调、打包部署与桌面端扩展

前后端都写完了，最后一步是把它变成一个真正能访问、能演示、能部署的东西。这个环节的技术含量不高，但是细节多，一步没配好就是一个红屏报错。而且我观察到electron打包vue项目、springboot vue前后端分离这些热词一直有人搜，说明大家做到这步多少都有卡壳。

5.1 跨域与开发代理：开发环境的连通方案

开发时前端在 5173 端口，后端在 3000 端口，如果前端直接 fetchhttp://localhost:3000/api/...，浏览器就会因为跨域拦截导致请求失败，即使后端开了 CORS 也有大量额外配置要做。最简单的方案是 Vite 的 dev server 代理。在vite.config.js里配：

export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true } } } });

配置完成后，前端请求/api/product/list就会在本地 dev server 层面转发到http://localhost:3000/api/product/list。前端代码里只写相对路径/api/xxx，不要写http://localhost:3000，这样就算是换到生产环境，代码也不用改第二遍。另外后端 Express 里别忘了挂cors中间件做兜底，因为你不知道会不会有别的调试工具直接请求后端接口。

5.2 打包与生产部署：一个进程搞定一切

生产部署我选择了最省事的一种：Express 直接托管前端静态资源。前端执行npm run build后生成dist目录，把它整个放进后端项目的根目录下，然后 Express 加三行代码：

const path = require('path'); app.use(express.static(path.join(__dirname, '../dist'))); app.get('*', (req, res) => { res.sendFile(path.join(__dirname, '../dist/index.html')); });

app.get('*')这一条很关键，它保证用户在浏览器里直接刷新/product/10这样的前端路由时，后端会把index.html返回给他，由前端路由接管页面渲染。如果不加这个 fallback，直接刷新详情页就是一个 404。这是前后端分离项目最容易忽略的坑。

后端进程管理我用 PM2。首先生态文件ecosystem.config.js：

module.exports = { apps: [{ name: 'snack-mall', script: './server/index.js', instances: 1, autorestart: true, env: { NODE_ENV: 'production', PORT: 3000 } }] };

然后pm2 start ecosystem.config.js就行了。instances为什么只开 1？因为小零食商城当前的并发量级，单实例远远够用，而 Node.js 的单线程模型处理这种 I/O 密集型 API 已经游刃有余。多开实例反而要处理数据同步问题，没必要。等哪天真有几千并发，再加小负载均衡也不晚。

数据库配置、JWT 密钥这些敏感信息，一定要放在.env文件里，用process.env.PORT这种形式读取，不要硬编码在源码里。我见过太多人把数据库密码直接写进 index.js 然后整个项目传 GitHub 的，这个习惯很危险。

5.3 用 Electron 把商城变成收银台：一个有意思的扩展

热搜词里electron打包vue项目出现率不低。我后来确实给这套商城套了一个 Electron 壳，做成一个桌面版收银端，在超市前台跑收银。这里简单说下落地思路，毕竟很多人卡在"Vue 打包后怎么和 Electron 整合"这个问题上。

我的做法是用 electron-builder，入口 HTML 文件直接指向 Vue 打包出来的dist/index.html。关键点是主进程和渲染进程的通信：

• 渲染进程（Vue 页面）负责界面交互，比如展示购物车、计算总价、扫码录入商品。
• 主进程负责和系统层打交道，比如读取 USB 扫码枪数据、调用本地小票打印机、保存对账单。
• 两者之间用ipcRenderer和ipcMain通信。

// preload.js 中暴露安全的桥接方法 const { contextBridge, ipcRenderer } = require('electron'); contextBridge.exposeInMainWorld('printer', { printReceipt: (orderData) => ipcRenderer.invoke('print-receipt', orderData) });

这里有个安全红线：不要直接在渲染进程里用 Node.js 原生的 require 和 Electron API，Electron 新版本默认contextIsolation是开启的，渲染进程拥有独立上下文，必须通过 preload 暴露白名单 API。这样即使前端页面被注入了恶意脚本，它也拿不到本地系统的文件操作权限。用 Electron 壳封装这套商城系统，能获得的最大价值是它不需要浏览器，双击就开，而且能直接操作本地硬件。缺点是打包体积大、内存占用偏高，所以它更适合收银台这种专用设备场景，不适合做 C 端在线商城的常规形态。

6. 联调阶段的高频报错与定位思路

最后这部分是我在实际做这个项目时反复遇到、也帮别人排查过的一批报错，列成清单。

定位问题有个最基本的顺序：先看浏览器 Network 面板里请求到底出去没有、响应到底是什么；再看后端 console 有没有输出；最后才考虑是不是代码逻辑问题。我见过很多朋友一报错就打开源文件反复看，其实 80% 的情况下，报错信息已经把你引到根因了，你只需要把日志看全。

上面这一步里有一个高频坑我多说一句：下载vue、vue安装依赖等热词背后还有一个隐藏问题，很多人在前端环境完全没搭好的情况下就去写业务代码，结果就是分不清自己的语法错误和环境错误。所以如果报错很怪，先npm run dev看能否正常起服务，起不来的话基本是依赖缺失，node_modules删了重装一遍就好了，这个方法听着粗暴，但真的能治好大部分玄学问题。

我个人在实际操作中还有一个体会：做这种全栈项目，一定要先定好数据库字段再动手写前端页面。我最早是边写前端边改后端字段，结果就是前端联调时一堆字段对不上，来回改接口。后来学乖了，先画出一张接口文档表，把每个接口的路径、入参、出参字段列清楚，前端照着写，后端照着实现，联调效率一下子翻倍。如果你也要上手这类系统，这个建议值得你花十分钟照做。