1. 商城交易平台的骨架设计技术选型与数据模型1.1 为什么选 Node.js Vue 这对组合来扛电商业务做电子数码类的手机商城交易平台我最初其实纠结过要不要上 Spring Boot。毕竟电商系统的订单、库存、支付链路Java 生态的成熟度确实摆在那里。但真正动手的时候我发现自己需要的不是一个企业级框架而是一个能让我快速把前后端串起来的组合。Node.js 的优势在于前端同学不需要切换语言心智JavaScript 全栈能省掉大量的上下文切换成本。尤其是做秒杀这种偏实时的业务场景Node 的事件驱动模型天然适合承载高并发的 I/O 请求——当然这里的高并发指的是中小型电商的量级别指望它去扛 618 那种峰值。Vue 这边就更不用说了它响应式数据和组件化开发的体验在处理商品列表、购物车这种状态频繁变化的页面时非常顺手。我前后用 Vue 2 和 Vue 3 都做过商城项目说实话如果你现在从零开始直接上 Vue 3 Composition API 会舒服很多组合式函数类似原来的 mixin 但更干净非常适合把购物车、登录状态这些跨组件共享的逻辑抽出来复用。1.2 商品表、订单表、秒杀活动表怎么设计才不会返工数据模型是所有电商项目的命根子。我第一次做商城时偷懒就建了一张商品表手机、耳机、充电宝全是同一套字段。结果做到后面发现手机要管内存版本、颜色、是否全网通耳机要管蓝牙版本和续航一张表根本塞不下。后来老老实实换成SPU标准产品单元 SKU库存量单位的经典模型商品表spu存商品基本信息、封面图、详情描述库存表sku每个 SKU 对应当一个具体规格组合比如 iPhone 15 Pro Max 256G 蓝色价格和库存都挂在 SKU 上秒杀活动表seckill_activity活动开始时间、结束时间、活动状态秒杀商品表seckill_sku活动 ID 关联 SKU ID记录秒杀价和秒杀库存这样设计的好处是普通商品和秒杀商品可以共用一套商品链路秒杀只是给部分 SKU 增加了一个活动价的维度不会污染正常的价格体系。CREATE TABLE sku ( id INT PRIMARY KEY AUTO_INCREMENT, spu_id INT NOT NULL, name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, specs JSON DEFAULT NULL, status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE seckill_sku ( id INT PRIMARY KEY AUTO_INCREMENT, activity_id INT NOT NULL, sku_id INT NOT NULL, seckill_price DECIMAL(10,2) NOT NULL, seckill_stock INT NOT NULL DEFAULT 0, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL );这里有个关键点秒杀库存和普通库存的关系。最稳妥的做法是创建秒杀活动时从 SKU 的总库存里划出一部分数量作为秒杀库存比如 iPhone 总库存 300 台划 50 台做 99 元秒杀当然实际不可能这么便宜。秒杀池和普通池分开扣减互不影响。如果混在一起秒杀用户把库存扣光了普通用户正常下单却显示无货那就是事故了。1.3 项目目录结构前后端分离后的职责划分前后端分离这个词这些年都被说烂了但真正在执行层面清晰的团队不多。我这个项目的目录是这么切的前端client/和后端server/完全独立各自有自己的 package.json。前端负责路由、组件、状态管理、请求封装后端只提供 JSON API不做任何页面渲染。这样做的好处是我后面单独加一个移动端 H5或者用 Electron 打包桌面版后端一行都不用改。后端这边我按业务模块来切而不是按技术分层来切server/ ├── app.js # Express 入口 ├── routes/ # 路由层只做参数校验和路由分发 │ ├── goods.js │ ├── cart.js │ ├── order.js │ └── seckill.js ├── controllers/ # 业务逻辑层核心业务都在这 ├── models/ # 数据库封装 └── utils/ # 鉴权、响应包装、订单号生成等工具很多新手喜欢按 controller / service / dao 三层去架其实在小团队里那是自找麻烦。按业务模块切改秒杀功能就是routes/seckill.js和controllers/seckill.js两个文件的事定位快、牵涉面小。这也是我从老项目里吸取的教训——按技术分层的确规范但是业务需求一变你要横切三层文件才能搞定一个改动效率太低。2. 秒杀不只是把商品卖出去并发控制与防超卖2.1 秒杀场景的并发压力到底在哪里秒杀这个场景很多新手的第一反应是把秒杀按钮置灰防止用户狂点但真正的压力根本不在前端而在后端那几个关键操作上。秒杀的核心链路其实就是两步校验并扣减库存和创建订单。这两步之间存在一个时间窗口如果不在数据库层加约束高并发下一定会出现超卖——库存只剩 10 台却有 20 个人同时下单成功。我用浴室放水来打比方数据库库存就是一个水箱每个秒杀请求就是一个来打水的人。如果没有人在水箱口守着大家一拥而上水早就溢出来了。防超卖的本质就是在这个水箱口装一个只放有定量水出去的阀门。2.2 基于数据库事务和乐观锁的防超卖方案我用的是事务 乐观锁条件更新的组合方案。核心 SQL 就一行UPDATE sku SET stock stock - 1 WHERE id ? AND stock 0;这行 SQL 的巧妙之处在于stock 0这个条件是原子性的。数据库在更新时会锁行两个并发请求同时到达时第二个请求会拿到更新后的stock值如果此时库存已经是 0它的条件就不满足更新影响行数为 0。我们再根据这个影响行数判断result.affectedRows 1说明扣减成功0说明库存已被抢光。我当时先开了事务执行扣减再插入订单最后 commit。如果插入订单失败就 rollback 把库存回滚回去。这个过程里有个大坑事务一定要短。不要在事务里做远程调用比如请求支付接口、发短信通知否则事务长时间持有数据库锁后续请求全部堆积系统直接雪崩。事务里只放库存扣减和订单记录插入这两个操作其他事情全部等事务提交之后再异步去做。给个 Express 伪代码示意const connection await dbPool.getConnection(); try { await connection.beginTransaction(); const [result] await connection.execute( UPDATE sku SET stock stock - 1 WHERE id ? AND stock 0, [skuId] ); if (result.affectedRows 0) { await connection.rollback(); return { code: 1, msg: 手速慢了商品已抢光 }; } await connection.execute( INSERT INTO orders (order_no, user_id, sku_id, amount, status, created_at) VALUES (?, ?, ?, ?, ?, ?), [orderNo, userId, skuId, seckillPrice, 0, new Date()] ); await connection.commit(); return { code: 0, msg: 秒杀成功, data: { orderNo } }; } catch (err) { await connection.rollback(); throw err; } finally { connection.release(); }这里要注意连接池的使用。每次请求都从连接池拿连接用完释放release()一定要放在finally里。我见过同事把release()写在使用成功的分支里结果一旦抛出异常连接永远不释放跑上半天数据库连接池被耗光整个后端直接挂掉。2.3 同一用户重复下单怎么防库存防超卖只是解决了总量不超的问题但还有一个隐蔽问题同一个人用两个设备、两个浏览器疯狂刷接口会导致同一用户抢到多单。虽然可以事后人工取消但体验很差也容易产生纠纷。方案是在订单表上加一个唯一索引字段是user_id activity_id sku_id。这样事务提交时如果同一个人在同一场活动里已经下过单数据库会直接报Duplicate entry唯一键冲突该用户在事务内插入订单失败库存自然回滚。有的项目会引入 Redis 做分布式锁比如用SET NX EX给每个用户每次活动设置一个抢购锁。但说实话对于单体 Node.js 应用 单库 MySQL 的架构乐观锁加唯一约束已经能挡掉 99% 的问题。Redis 方案更适合你已经有了 Redis 基础设施或者需要跨多个后端实例共享状态时再上。不要为了用某种技术而引入某种技术这是我一直提醒自己的。2.4 秒杀失败后的库存回滚与超时订单处理秒杀成功不代表订单最终成交。用户抢到后可能一直不付款把库存白白占着。所以需要两套机制第一前端倒计时 后端订单过期状态。生成订单时给一个expire_time比如 15 分钟。用户在这个时间内没付款后台定时任务把订单状态改为已取消同时把秒杀库存回滚回去。回滚的时候必须再走一次条件更新比如UPDATE sku SET stock stock 1 WHERE id ?否则会出现库存回滚期间又被其他订单改过数量对不上的问题。不用担心加库存会加超因为初始是扣减过的回滚只是还原。第二定时任务别用 setTimeout 硬扛。Node.js 做定时任务最稳的方案是上node-cron或者直接把任务放到外部调度比如云函数定时触发。如果只是单机测试setInterval也能跑但要注意进程重启后内存里的定时器就没了超时订单永远不会被处理。把任务设计成每次启动时先扫描所有未支付且已过期的订单这样即使进程重启也能自动补偿处理。3. 购物车、订单与支付流程交易主链路怎么串起来3.1 购物车的本地状态与登录后同步问题商城没有购物车就像吃饭没有碗。我用 Vue 做了购物车模块这里有个体验细节值得展开说。用户未登录的时候购物车数据存在哪我存在 localStorage 里。用户登录后购物车数据应该合并到服务端数据库。合并不是简单覆盖而是要做数量叠加 去重本地有 3 件 iPhone服务端已有 2 件合并后应该是 5 件而不是 3 件更不是 2 件。这个逻辑在controllers/cart.js里实现登录成功后前端把本地购物车数据发给后端后端逐条查询服务端购物车表存在同 SKU 则数量相加不存在则插入新记录合并完成后前端清空 localStorage 购物车重新拉取服务端购物车数据状态管理我用 PiniaVue 3拆了一个cartStore。购物车的任何变更加购、减量、删除、勾选都先改本地状态再异步同步到服务端。同步失败时做个状态标记提示用户网络异常稍后重试但不要把本地购物车清掉——否则用户一断网购物车就没了这体验太灾难了。3.2 订单状态机下单只是起点订单是整个交易链路的核心数据实体。我设计的订单状态不是简单的待支付 / 已支付 / 已收货三个状态而是完整的生命周期0 待支付 - 1 已支付 - 2 已发货 - 3 已收货 - 4 已完成 | - 5 已取消用户主动取消或超时未付状态流转我放在一个updateOrderStatus函数里统一处理前端根据状态码渲染不同的按钮组合。这个状态机看着简单但实现时有两个容易翻车的地方第一状态流转要有方向校验。不能允许已发货的订单跳回 待支付更不能允许已取消的订单变成已支付。我的做法是在更新语句里带上前置状态条件UPDATE orders SET status 1, pay_time NOW() WHERE order_no ? AND status 0如果影响行数为 0说明状态不是待支付更新失败从根源上堵住状态错乱。第二支付回调里也要做同款校验。支付平台回调到达后先查询订单当前状态只有待支付才允许改为已支付。否则支付平台重复回调时订单状态被重复流转虽然最终结果可能没错但各种边界情况会让你查 bug 查到怀疑人生。3.3 支付对接的简化实现与校验逻辑真实项目里接入微信支付、支付宝需要商户号和各种资质个人开发者往往没有条件。我做的方案是模拟支付网关下单后跳到收银台页面用户点击确认支付前端请求后端一个/api/pay/mock接口后端模拟支付成功更新订单状态并返回支付结果。这个方案适合学习和演示但如果你要接真实支付一定要理解回调校验支付平台会往你的回调地址 POST 数据你要用平台公钥验证签名验签通过后才能改订单状态。而且回调处理要做幂等——支付平台可能回调好几次每次回调都去更新订单状态没问题但不能重复增加用户余额、不能重复发通知。我在模拟支付里也保留了幂等设计用订单号做参数重复请求时如果订单已是已支付状态直接返回成功不再执行状态更新之外的副作用操作。3.4 前端路由守卫与提交防抖Vue Router 这块有个很实用的设计路由守卫控制页面访问权限。商城通常有/login、/goods、/cart、/checkout、/order/detail/:id这些页面。下单、结算、订单详情这些页面必须登录才能访问我在router.beforeEach里统一判断router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }); } else { next(); } });从热搜词里看到很多人搜vue路由参数和vue动态路由这里补充一个经验订单详情页路由用path: /order/:id动态参数传递订单号组件内通过route.params.id获取。不要用query传长订单号因为用户分享链接时订单号会出现在 URL 里既难看又不安全。提交防抖也是必做的。用户在结算页狂点提交订单按钮前端如果不做处理会向后端发出多个相同请求导致重复下单或重复秒杀。我的做法是两层防护按钮点击后立即置为 loading 禁用状态同时在请求层做一次性标记——同一路由的提交请求未返回前不接收新的提交。4. 环境配置与联调排错高频翻车点实录看到标题热搜词里一大半都是nodejs安装、npm 无法加载文件、vue安装依赖这些环境问题我太有共鸣了。说实话这个项目 20% 的时间在写业务80% 的时间在处理环境。下面这几个坑几乎每个新手都会踩我按踩坑率排序写出来。4.1 Node.js 安装与环境变量PATH 没配好是一切问题的根源Windows 下安装 Node.js 其实直接去官网下 msi 包一路 Next 就行但很多人装完发现node -v能跑npm -v却提示不是内部或外部命令。这基本就是 PATH 环境变量没配全。Node 安装目录下其实有几个关键目录主目录node.exe 所在、node_modules和node_cache。npm 的全局安装包默认放在主目录下的node_modules它本身是个脚本文件npm.cmd需要主目录在 PATH 里才能被命令行找到。我通常建议把 npm 全局目录和缓存目录单独规划一下避免 C 盘越来越肥npm config set prefix D:\nodejs\node_global npm config set cache D:\nodejs\node_cache配置完记得把D:\nodejs\node_global加入 PATH否则全局安装的模块比如后面要用的pm2、cnpm总是提示找不到命令。Ubuntu 服务器上装 Node.js 就是另一套玩法了。别直接apt install nodejs版本太老。我一般用 nvm 装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 18.19.0 nvm use 18.19.0nvm 的好处是可以在多个 Node 版本间切换测试不同版本兼容性时特别有用。4.2 npm.ps1 无法加载文件PowerShell 执行策略的坑这个报错在标题热搜词里出现了两遍分别是c:\program files\nodejs\npm.ps1和d:\program files\nodejs\npm.ps1可见踩的人有多少。错误信息是无法加载文件 ...npm.ps1因为在此系统上禁止运行脚本。原因是 Windows PowerShell 默认执行策略是Restricted禁止运行任何.ps1脚本。而 npm 在 PowerShell 环境下走的正是npm.ps1这个脚本文件所以直接被拦了。解法很简单以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSigned输入Y确认即可。RemoteSigned的意思是本地创建的脚本可以运行从网上下载的脚本必须有可信签名。这是目前平衡安全性和便利性的最佳设置比直接设Unrestricted完全放开要稳妥得多。如果你不想改全局执行策略也有个折中方案直接用npm.cmd代替npm命令。在 cmd 或 PowerShell 里敲npm.cmd -v也是合法的。但这不是长久之计你自己倒是能跑团队里别人用 IDE 终端跑脚本还是会报错。4.3 Vue 项目的依赖安装与版本锁定Vue 项目踩得最多的就是依赖版本冲突。创建 Vue 3 项目我用 Vite 脚手架Vue CLI 虽然还在维护但已经过时了npm create vitelatest client -- --template vue cd client npm install这里有个细节npm install生成的package-lock.json一定要提交到 Git。它定义了每个依赖的精确版本。我见过同事跑npm install后因为依赖版本浮动导致编译突然报错最后追查发现是某个子依赖发了个 breaking change。提交 lock 文件后团队所有人装出来的依赖树完全一致这类问题直接消失。安装过程中如果遇到网络问题可以把 npm registry 切到国内镜像npm config set registry https://registry.npmmirror.com装完后记得npm install一次验证然后npm run dev启动看是否正常。Vue 3 的项目默认端口是 5173Vite如果被占用可以改vite.config.js里的server.port。4.4 前后端联调时的跨域配置devServer 代理到底怎么写前端跑在 5173后端跑在 3000前端直接 fetch 后端接口必然炸跨域。跨域的解决方案不是在前端代码里把请求地址写成后端地址而是在 Vite 的 dev server 里做代理。我在vite.config.js里这样配export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } } })配好之后前端请求/api/goods/listVite dev server 会把它转发到http://localhost:3000/api/goods/list。前端代码里写相对路径走/api前缀不用关心后端地址以后上线时把/api用 Nginx 反代到后端就行前端代码一行不用改。有个容易忽略的坑changeOrigin: true必须设置。它的作用是修改请求头里的Host字段否则后端如果做了域名校验判断Host是白名单请求会被拒掉。另外如果你的后端还做了 CORS 允许配置记得只保留代理一种方式两种同时用有时候会出奇怪的重复预检OPTIONS请求发多次。模拟联调时后端 CORS 配置也要开好规避非浏览器工具测试时的干扰。我用 Express 时一般在入口统一设置app.use((req, res, next) { res.header(Access-Control-Allow-Origin, *); res.header(Access-Control-Allow-Methods, GET,POST,PUT,DELETE,OPTIONS); res.header(Access-Control-Allow-Headers, Content-Type, Authorization); if (req.method OPTIONS) { return res.sendStatus(200); } next(); });OPTIONS预检直接返回 200 这个操作很重要很多联调半天调不通的问题最后发现是预检请求被卡住了。5. 从本地跑通到可交付构建、适配与部署心得5.1 Vue 项目打包与 Nginx 静态托管本地开发完最终是要让别人能访问的。前端项目跑npm run build产物输出到dist目录。这个目录是纯静态文件可以直接扔到 Nginx 的html目录下托管。我第一次部署时犯过一个错误把dist目录往 Nginx 里一放后端用 Node 直接node app.js裸跑然后前端通过 IP 加端口去请求后端。这种部署方式问题很多Node 进程一旦崩溃或服务器重启服务就没了还需要手动去服务器上敲命令。后来我改成用 PM2 守护后端进程用 Nginx 同时托管前端静态文件和转发 API 请求才算真正可交付。PM2 的用法极简npm install -g pm2 pm2 start app.js --name shop-api pm2 save pm2 startuppm2 startup会生成一条开机自启的命令按它的提示执行一遍服务器重启后 Node 服务会自动拉起。这招对个人项目或者小团队项目特别管用不用额外搞 Docker 编排那一套。5.2 Nginx 配置静态文件与 API 反代我的 Nginx 配置大概是这样server { listen 80; server_name your-domain.com; # 前端静态文件 root /var/www/client/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # Vue Router history 模式需要 location / { try_files $uri $uri/ /index.html; } }最后那个try_files指向index.html特别关键。Vue Router 用 history 模式时URL 里没有#用户直接访问/order/123这个路径时Nginx 找不到对应文件必须回退到index.html让前端路由接管。如果你漏了这一行用户刷新订单详情页就是 404。如果你不想折腾这个也可以退而求其次用 hash 模式URL 带#但体验和美观度都差一截。5.3 登录态持久化与 360 浏览器的兼容性适配登录态我用的是 JWT。用户登录成功后后端返回一个 token前端存 localStorage每次请求通过 axios 拦截器自动带上axios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });后端做一个全局鉴权中间件排除掉登录注册接口和商品列表这类公开接口其余接口全部校验 token。这个模式比 Session Cookie 更适合前后端分离因为移动端、小程序端也能复用同一套鉴权逻辑。热搜词里提到vue项目怎么适配360浏览器这个确实遇到过。360 浏览器有个兼容模式会用 IE 内核渲染Vue 3 根本不支持 IE页面白屏没商量。解决办法是在index.html里加一行meta namerenderer contentwebkit让 360 浏览器强制用极速模式Chromium 内核渲染别切到 IE 模式。实测加了这行后绝大多数 360 浏览器用户都能正常访问。另外如果目标用户群还在大量用 Windows 7那 Node 后端的 API 也要注意别用太新的语法特性或者用 Babel 转译一下。不过说实话现在还在用老 IE 内核访问商城购物的用户已经很少了权重不用放太高。5.4 后续还能往哪里扩展这个架构跑通后扩展方向其实挺多的。热搜词里有人搜electron 主渲染进程 ipc 通信和electron打包vue项目说明有人想把这个商城打包成桌面应用。Vue 项目用 Electron 打包确实可行基本思路是把打包后的 dist 静态文件作为 Electron 的渲染进程资源加载用ipcMain/ipcRenderer处理窗口控制、本地缓存这些原生能力。商城这种纯 Web 业务桌面端只是个壳核心交互还是走 HTTP API。还有人搜vue项目如何发布微信小程序这就涉及到 Taro 或者 uni-app 这类跨端方案了。说实话如果只是把现有 Vue 项目转成小程序几乎没有无损方案因为小程序的组件体系和 Vue 的 DOM 体系差异很大。更实际的做法是后端 API 完全复用前端单独用 Taro 写一个小程序版本。反向验证了一下我这个项目的后端接口设计从一开始就没绑定任何前端框架所以未来出小程序端只是前端工作量的问题。另一个值得做的方向是管理后台。商城一定会需要商品上下架、库存调整、订单发货、秒杀活动配置这些管理功能。我已经在项目里预留了 admin 端的路由和角色字段后续只要在权限中间件里加一层role判断就能区分买家端和管理员端。最后说点个人的项目体会。做这种全栈商城项目最大的收获其实不是某个技术用得多熟而是建立了一套从数据模型设计到并发控制再到部署运维的完整链路认知。秒杀功能的防超卖方案、订单状态机的幂等设计、Nginx 反代加 PM2 守护的部署方式这些东西单拎出来都不难但合在一起就是一个小而完整的电商系统。如果你也在做类似的项目我的建议是先别急着堆功能把商品、订单、秒杀这三张核心表的关系理清楚把乐观锁防超卖跑通把一个订单从下单到收货的完整流程走顺然后再考虑花哨的东西。基础链路稳了商城这个壳子怎么加功能都不会散。
Node.js+Vue全栈商城实战：从秒杀防超卖到Nginx部署
1. 商城交易平台的骨架设计技术选型与数据模型1.1 为什么选 Node.js Vue 这对组合来扛电商业务做电子数码类的手机商城交易平台我最初其实纠结过要不要上 Spring Boot。毕竟电商系统的订单、库存、支付链路Java 生态的成熟度确实摆在那里。但真正动手的时候我发现自己需要的不是一个企业级框架而是一个能让我快速把前后端串起来的组合。Node.js 的优势在于前端同学不需要切换语言心智JavaScript 全栈能省掉大量的上下文切换成本。尤其是做秒杀这种偏实时的业务场景Node 的事件驱动模型天然适合承载高并发的 I/O 请求——当然这里的高并发指的是中小型电商的量级别指望它去扛 618 那种峰值。Vue 这边就更不用说了它响应式数据和组件化开发的体验在处理商品列表、购物车这种状态频繁变化的页面时非常顺手。我前后用 Vue 2 和 Vue 3 都做过商城项目说实话如果你现在从零开始直接上 Vue 3 Composition API 会舒服很多组合式函数类似原来的 mixin 但更干净非常适合把购物车、登录状态这些跨组件共享的逻辑抽出来复用。1.2 商品表、订单表、秒杀活动表怎么设计才不会返工数据模型是所有电商项目的命根子。我第一次做商城时偷懒就建了一张商品表手机、耳机、充电宝全是同一套字段。结果做到后面发现手机要管内存版本、颜色、是否全网通耳机要管蓝牙版本和续航一张表根本塞不下。后来老老实实换成SPU标准产品单元 SKU库存量单位的经典模型商品表spu存商品基本信息、封面图、详情描述库存表sku每个 SKU 对应当一个具体规格组合比如 iPhone 15 Pro Max 256G 蓝色价格和库存都挂在 SKU 上秒杀活动表seckill_activity活动开始时间、结束时间、活动状态秒杀商品表seckill_sku活动 ID 关联 SKU ID记录秒杀价和秒杀库存这样设计的好处是普通商品和秒杀商品可以共用一套商品链路秒杀只是给部分 SKU 增加了一个活动价的维度不会污染正常的价格体系。CREATE TABLE sku ( id INT PRIMARY KEY AUTO_INCREMENT, spu_id INT NOT NULL, name VARCHAR(128) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, specs JSON DEFAULT NULL, status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE seckill_sku ( id INT PRIMARY KEY AUTO_INCREMENT, activity_id INT NOT NULL, sku_id INT NOT NULL, seckill_price DECIMAL(10,2) NOT NULL, seckill_stock INT NOT NULL DEFAULT 0, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL );这里有个关键点秒杀库存和普通库存的关系。最稳妥的做法是创建秒杀活动时从 SKU 的总库存里划出一部分数量作为秒杀库存比如 iPhone 总库存 300 台划 50 台做 99 元秒杀当然实际不可能这么便宜。秒杀池和普通池分开扣减互不影响。如果混在一起秒杀用户把库存扣光了普通用户正常下单却显示无货那就是事故了。1.3 项目目录结构前后端分离后的职责划分前后端分离这个词这些年都被说烂了但真正在执行层面清晰的团队不多。我这个项目的目录是这么切的前端client/和后端server/完全独立各自有自己的 package.json。前端负责路由、组件、状态管理、请求封装后端只提供 JSON API不做任何页面渲染。这样做的好处是我后面单独加一个移动端 H5或者用 Electron 打包桌面版后端一行都不用改。后端这边我按业务模块来切而不是按技术分层来切server/ ├── app.js # Express 入口 ├── routes/ # 路由层只做参数校验和路由分发 │ ├── goods.js │ ├── cart.js │ ├── order.js │ └── seckill.js ├── controllers/ # 业务逻辑层核心业务都在这 ├── models/ # 数据库封装 └── utils/ # 鉴权、响应包装、订单号生成等工具很多新手喜欢按 controller / service / dao 三层去架其实在小团队里那是自找麻烦。按业务模块切改秒杀功能就是routes/seckill.js和controllers/seckill.js两个文件的事定位快、牵涉面小。这也是我从老项目里吸取的教训——按技术分层的确规范但是业务需求一变你要横切三层文件才能搞定一个改动效率太低。2. 秒杀不只是把商品卖出去并发控制与防超卖2.1 秒杀场景的并发压力到底在哪里秒杀这个场景很多新手的第一反应是把秒杀按钮置灰防止用户狂点但真正的压力根本不在前端而在后端那几个关键操作上。秒杀的核心链路其实就是两步校验并扣减库存和创建订单。这两步之间存在一个时间窗口如果不在数据库层加约束高并发下一定会出现超卖——库存只剩 10 台却有 20 个人同时下单成功。我用浴室放水来打比方数据库库存就是一个水箱每个秒杀请求就是一个来打水的人。如果没有人在水箱口守着大家一拥而上水早就溢出来了。防超卖的本质就是在这个水箱口装一个只放有定量水出去的阀门。2.2 基于数据库事务和乐观锁的防超卖方案我用的是事务 乐观锁条件更新的组合方案。核心 SQL 就一行UPDATE sku SET stock stock - 1 WHERE id ? AND stock 0;这行 SQL 的巧妙之处在于stock 0这个条件是原子性的。数据库在更新时会锁行两个并发请求同时到达时第二个请求会拿到更新后的stock值如果此时库存已经是 0它的条件就不满足更新影响行数为 0。我们再根据这个影响行数判断result.affectedRows 1说明扣减成功0说明库存已被抢光。我当时先开了事务执行扣减再插入订单最后 commit。如果插入订单失败就 rollback 把库存回滚回去。这个过程里有个大坑事务一定要短。不要在事务里做远程调用比如请求支付接口、发短信通知否则事务长时间持有数据库锁后续请求全部堆积系统直接雪崩。事务里只放库存扣减和订单记录插入这两个操作其他事情全部等事务提交之后再异步去做。给个 Express 伪代码示意const connection await dbPool.getConnection(); try { await connection.beginTransaction(); const [result] await connection.execute( UPDATE sku SET stock stock - 1 WHERE id ? AND stock 0, [skuId] ); if (result.affectedRows 0) { await connection.rollback(); return { code: 1, msg: 手速慢了商品已抢光 }; } await connection.execute( INSERT INTO orders (order_no, user_id, sku_id, amount, status, created_at) VALUES (?, ?, ?, ?, ?, ?), [orderNo, userId, skuId, seckillPrice, 0, new Date()] ); await connection.commit(); return { code: 0, msg: 秒杀成功, data: { orderNo } }; } catch (err) { await connection.rollback(); throw err; } finally { connection.release(); }这里要注意连接池的使用。每次请求都从连接池拿连接用完释放release()一定要放在finally里。我见过同事把release()写在使用成功的分支里结果一旦抛出异常连接永远不释放跑上半天数据库连接池被耗光整个后端直接挂掉。2.3 同一用户重复下单怎么防库存防超卖只是解决了总量不超的问题但还有一个隐蔽问题同一个人用两个设备、两个浏览器疯狂刷接口会导致同一用户抢到多单。虽然可以事后人工取消但体验很差也容易产生纠纷。方案是在订单表上加一个唯一索引字段是user_id activity_id sku_id。这样事务提交时如果同一个人在同一场活动里已经下过单数据库会直接报Duplicate entry唯一键冲突该用户在事务内插入订单失败库存自然回滚。有的项目会引入 Redis 做分布式锁比如用SET NX EX给每个用户每次活动设置一个抢购锁。但说实话对于单体 Node.js 应用 单库 MySQL 的架构乐观锁加唯一约束已经能挡掉 99% 的问题。Redis 方案更适合你已经有了 Redis 基础设施或者需要跨多个后端实例共享状态时再上。不要为了用某种技术而引入某种技术这是我一直提醒自己的。2.4 秒杀失败后的库存回滚与超时订单处理秒杀成功不代表订单最终成交。用户抢到后可能一直不付款把库存白白占着。所以需要两套机制第一前端倒计时 后端订单过期状态。生成订单时给一个expire_time比如 15 分钟。用户在这个时间内没付款后台定时任务把订单状态改为已取消同时把秒杀库存回滚回去。回滚的时候必须再走一次条件更新比如UPDATE sku SET stock stock 1 WHERE id ?否则会出现库存回滚期间又被其他订单改过数量对不上的问题。不用担心加库存会加超因为初始是扣减过的回滚只是还原。第二定时任务别用 setTimeout 硬扛。Node.js 做定时任务最稳的方案是上node-cron或者直接把任务放到外部调度比如云函数定时触发。如果只是单机测试setInterval也能跑但要注意进程重启后内存里的定时器就没了超时订单永远不会被处理。把任务设计成每次启动时先扫描所有未支付且已过期的订单这样即使进程重启也能自动补偿处理。3. 购物车、订单与支付流程交易主链路怎么串起来3.1 购物车的本地状态与登录后同步问题商城没有购物车就像吃饭没有碗。我用 Vue 做了购物车模块这里有个体验细节值得展开说。用户未登录的时候购物车数据存在哪我存在 localStorage 里。用户登录后购物车数据应该合并到服务端数据库。合并不是简单覆盖而是要做数量叠加 去重本地有 3 件 iPhone服务端已有 2 件合并后应该是 5 件而不是 3 件更不是 2 件。这个逻辑在controllers/cart.js里实现登录成功后前端把本地购物车数据发给后端后端逐条查询服务端购物车表存在同 SKU 则数量相加不存在则插入新记录合并完成后前端清空 localStorage 购物车重新拉取服务端购物车数据状态管理我用 PiniaVue 3拆了一个cartStore。购物车的任何变更加购、减量、删除、勾选都先改本地状态再异步同步到服务端。同步失败时做个状态标记提示用户网络异常稍后重试但不要把本地购物车清掉——否则用户一断网购物车就没了这体验太灾难了。3.2 订单状态机下单只是起点订单是整个交易链路的核心数据实体。我设计的订单状态不是简单的待支付 / 已支付 / 已收货三个状态而是完整的生命周期0 待支付 - 1 已支付 - 2 已发货 - 3 已收货 - 4 已完成 | - 5 已取消用户主动取消或超时未付状态流转我放在一个updateOrderStatus函数里统一处理前端根据状态码渲染不同的按钮组合。这个状态机看着简单但实现时有两个容易翻车的地方第一状态流转要有方向校验。不能允许已发货的订单跳回 待支付更不能允许已取消的订单变成已支付。我的做法是在更新语句里带上前置状态条件UPDATE orders SET status 1, pay_time NOW() WHERE order_no ? AND status 0如果影响行数为 0说明状态不是待支付更新失败从根源上堵住状态错乱。第二支付回调里也要做同款校验。支付平台回调到达后先查询订单当前状态只有待支付才允许改为已支付。否则支付平台重复回调时订单状态被重复流转虽然最终结果可能没错但各种边界情况会让你查 bug 查到怀疑人生。3.3 支付对接的简化实现与校验逻辑真实项目里接入微信支付、支付宝需要商户号和各种资质个人开发者往往没有条件。我做的方案是模拟支付网关下单后跳到收银台页面用户点击确认支付前端请求后端一个/api/pay/mock接口后端模拟支付成功更新订单状态并返回支付结果。这个方案适合学习和演示但如果你要接真实支付一定要理解回调校验支付平台会往你的回调地址 POST 数据你要用平台公钥验证签名验签通过后才能改订单状态。而且回调处理要做幂等——支付平台可能回调好几次每次回调都去更新订单状态没问题但不能重复增加用户余额、不能重复发通知。我在模拟支付里也保留了幂等设计用订单号做参数重复请求时如果订单已是已支付状态直接返回成功不再执行状态更新之外的副作用操作。3.4 前端路由守卫与提交防抖Vue Router 这块有个很实用的设计路由守卫控制页面访问权限。商城通常有/login、/goods、/cart、/checkout、/order/detail/:id这些页面。下单、结算、订单详情这些页面必须登录才能访问我在router.beforeEach里统一判断router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }); } else { next(); } });从热搜词里看到很多人搜vue路由参数和vue动态路由这里补充一个经验订单详情页路由用path: /order/:id动态参数传递订单号组件内通过route.params.id获取。不要用query传长订单号因为用户分享链接时订单号会出现在 URL 里既难看又不安全。提交防抖也是必做的。用户在结算页狂点提交订单按钮前端如果不做处理会向后端发出多个相同请求导致重复下单或重复秒杀。我的做法是两层防护按钮点击后立即置为 loading 禁用状态同时在请求层做一次性标记——同一路由的提交请求未返回前不接收新的提交。4. 环境配置与联调排错高频翻车点实录看到标题热搜词里一大半都是nodejs安装、npm 无法加载文件、vue安装依赖这些环境问题我太有共鸣了。说实话这个项目 20% 的时间在写业务80% 的时间在处理环境。下面这几个坑几乎每个新手都会踩我按踩坑率排序写出来。4.1 Node.js 安装与环境变量PATH 没配好是一切问题的根源Windows 下安装 Node.js 其实直接去官网下 msi 包一路 Next 就行但很多人装完发现node -v能跑npm -v却提示不是内部或外部命令。这基本就是 PATH 环境变量没配全。Node 安装目录下其实有几个关键目录主目录node.exe 所在、node_modules和node_cache。npm 的全局安装包默认放在主目录下的node_modules它本身是个脚本文件npm.cmd需要主目录在 PATH 里才能被命令行找到。我通常建议把 npm 全局目录和缓存目录单独规划一下避免 C 盘越来越肥npm config set prefix D:\nodejs\node_global npm config set cache D:\nodejs\node_cache配置完记得把D:\nodejs\node_global加入 PATH否则全局安装的模块比如后面要用的pm2、cnpm总是提示找不到命令。Ubuntu 服务器上装 Node.js 就是另一套玩法了。别直接apt install nodejs版本太老。我一般用 nvm 装curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 18.19.0 nvm use 18.19.0nvm 的好处是可以在多个 Node 版本间切换测试不同版本兼容性时特别有用。4.2 npm.ps1 无法加载文件PowerShell 执行策略的坑这个报错在标题热搜词里出现了两遍分别是c:\program files\nodejs\npm.ps1和d:\program files\nodejs\npm.ps1可见踩的人有多少。错误信息是无法加载文件 ...npm.ps1因为在此系统上禁止运行脚本。原因是 Windows PowerShell 默认执行策略是Restricted禁止运行任何.ps1脚本。而 npm 在 PowerShell 环境下走的正是npm.ps1这个脚本文件所以直接被拦了。解法很简单以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSigned输入Y确认即可。RemoteSigned的意思是本地创建的脚本可以运行从网上下载的脚本必须有可信签名。这是目前平衡安全性和便利性的最佳设置比直接设Unrestricted完全放开要稳妥得多。如果你不想改全局执行策略也有个折中方案直接用npm.cmd代替npm命令。在 cmd 或 PowerShell 里敲npm.cmd -v也是合法的。但这不是长久之计你自己倒是能跑团队里别人用 IDE 终端跑脚本还是会报错。4.3 Vue 项目的依赖安装与版本锁定Vue 项目踩得最多的就是依赖版本冲突。创建 Vue 3 项目我用 Vite 脚手架Vue CLI 虽然还在维护但已经过时了npm create vitelatest client -- --template vue cd client npm install这里有个细节npm install生成的package-lock.json一定要提交到 Git。它定义了每个依赖的精确版本。我见过同事跑npm install后因为依赖版本浮动导致编译突然报错最后追查发现是某个子依赖发了个 breaking change。提交 lock 文件后团队所有人装出来的依赖树完全一致这类问题直接消失。安装过程中如果遇到网络问题可以把 npm registry 切到国内镜像npm config set registry https://registry.npmmirror.com装完后记得npm install一次验证然后npm run dev启动看是否正常。Vue 3 的项目默认端口是 5173Vite如果被占用可以改vite.config.js里的server.port。4.4 前后端联调时的跨域配置devServer 代理到底怎么写前端跑在 5173后端跑在 3000前端直接 fetch 后端接口必然炸跨域。跨域的解决方案不是在前端代码里把请求地址写成后端地址而是在 Vite 的 dev server 里做代理。我在vite.config.js里这样配export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:3000, changeOrigin: true } } } })配好之后前端请求/api/goods/listVite dev server 会把它转发到http://localhost:3000/api/goods/list。前端代码里写相对路径走/api前缀不用关心后端地址以后上线时把/api用 Nginx 反代到后端就行前端代码一行不用改。有个容易忽略的坑changeOrigin: true必须设置。它的作用是修改请求头里的Host字段否则后端如果做了域名校验判断Host是白名单请求会被拒掉。另外如果你的后端还做了 CORS 允许配置记得只保留代理一种方式两种同时用有时候会出奇怪的重复预检OPTIONS请求发多次。模拟联调时后端 CORS 配置也要开好规避非浏览器工具测试时的干扰。我用 Express 时一般在入口统一设置app.use((req, res, next) { res.header(Access-Control-Allow-Origin, *); res.header(Access-Control-Allow-Methods, GET,POST,PUT,DELETE,OPTIONS); res.header(Access-Control-Allow-Headers, Content-Type, Authorization); if (req.method OPTIONS) { return res.sendStatus(200); } next(); });OPTIONS预检直接返回 200 这个操作很重要很多联调半天调不通的问题最后发现是预检请求被卡住了。5. 从本地跑通到可交付构建、适配与部署心得5.1 Vue 项目打包与 Nginx 静态托管本地开发完最终是要让别人能访问的。前端项目跑npm run build产物输出到dist目录。这个目录是纯静态文件可以直接扔到 Nginx 的html目录下托管。我第一次部署时犯过一个错误把dist目录往 Nginx 里一放后端用 Node 直接node app.js裸跑然后前端通过 IP 加端口去请求后端。这种部署方式问题很多Node 进程一旦崩溃或服务器重启服务就没了还需要手动去服务器上敲命令。后来我改成用 PM2 守护后端进程用 Nginx 同时托管前端静态文件和转发 API 请求才算真正可交付。PM2 的用法极简npm install -g pm2 pm2 start app.js --name shop-api pm2 save pm2 startuppm2 startup会生成一条开机自启的命令按它的提示执行一遍服务器重启后 Node 服务会自动拉起。这招对个人项目或者小团队项目特别管用不用额外搞 Docker 编排那一套。5.2 Nginx 配置静态文件与 API 反代我的 Nginx 配置大概是这样server { listen 80; server_name your-domain.com; # 前端静态文件 root /var/www/client/dist; index index.html; location /api/ { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # Vue Router history 模式需要 location / { try_files $uri $uri/ /index.html; } }最后那个try_files指向index.html特别关键。Vue Router 用 history 模式时URL 里没有#用户直接访问/order/123这个路径时Nginx 找不到对应文件必须回退到index.html让前端路由接管。如果你漏了这一行用户刷新订单详情页就是 404。如果你不想折腾这个也可以退而求其次用 hash 模式URL 带#但体验和美观度都差一截。5.3 登录态持久化与 360 浏览器的兼容性适配登录态我用的是 JWT。用户登录成功后后端返回一个 token前端存 localStorage每次请求通过 axios 拦截器自动带上axios.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; });后端做一个全局鉴权中间件排除掉登录注册接口和商品列表这类公开接口其余接口全部校验 token。这个模式比 Session Cookie 更适合前后端分离因为移动端、小程序端也能复用同一套鉴权逻辑。热搜词里提到vue项目怎么适配360浏览器这个确实遇到过。360 浏览器有个兼容模式会用 IE 内核渲染Vue 3 根本不支持 IE页面白屏没商量。解决办法是在index.html里加一行meta namerenderer contentwebkit让 360 浏览器强制用极速模式Chromium 内核渲染别切到 IE 模式。实测加了这行后绝大多数 360 浏览器用户都能正常访问。另外如果目标用户群还在大量用 Windows 7那 Node 后端的 API 也要注意别用太新的语法特性或者用 Babel 转译一下。不过说实话现在还在用老 IE 内核访问商城购物的用户已经很少了权重不用放太高。5.4 后续还能往哪里扩展这个架构跑通后扩展方向其实挺多的。热搜词里有人搜electron 主渲染进程 ipc 通信和electron打包vue项目说明有人想把这个商城打包成桌面应用。Vue 项目用 Electron 打包确实可行基本思路是把打包后的 dist 静态文件作为 Electron 的渲染进程资源加载用ipcMain/ipcRenderer处理窗口控制、本地缓存这些原生能力。商城这种纯 Web 业务桌面端只是个壳核心交互还是走 HTTP API。还有人搜vue项目如何发布微信小程序这就涉及到 Taro 或者 uni-app 这类跨端方案了。说实话如果只是把现有 Vue 项目转成小程序几乎没有无损方案因为小程序的组件体系和 Vue 的 DOM 体系差异很大。更实际的做法是后端 API 完全复用前端单独用 Taro 写一个小程序版本。反向验证了一下我这个项目的后端接口设计从一开始就没绑定任何前端框架所以未来出小程序端只是前端工作量的问题。另一个值得做的方向是管理后台。商城一定会需要商品上下架、库存调整、订单发货、秒杀活动配置这些管理功能。我已经在项目里预留了 admin 端的路由和角色字段后续只要在权限中间件里加一层role判断就能区分买家端和管理员端。最后说点个人的项目体会。做这种全栈商城项目最大的收获其实不是某个技术用得多熟而是建立了一套从数据模型设计到并发控制再到部署运维的完整链路认知。秒杀功能的防超卖方案、订单状态机的幂等设计、Nginx 反代加 PM2 守护的部署方式这些东西单拎出来都不难但合在一起就是一个小而完整的电商系统。如果你也在做类似的项目我的建议是先别急着堆功能把商品、订单、秒杀这三张核心表的关系理清楚把乐观锁防超卖跑通把一个订单从下单到收货的完整流程走顺然后再考虑花哨的东西。基础链路稳了商城这个壳子怎么加功能都不会散。
